[ODE] RE: Cone and Terrain

Eric Buchanan buchanan at email.arc.nasa.gov
Tue Mar 9 11:13:40 MST 2004


Yes exactly, and the terrains repeat themselves. They extend out to infinity 
in every direction, the same patch tiled down all over. 

This would make transitions between terrains very sloppy. Imagine a patch of 
terrain that is a slope going down at a sharp gradient.  At the edge where 
you place the new terrain your going to have have both the high side of the 
slope(the repeat) and something that is continous with your terrain (the new 
patch).

To help facilitate this i would like to see the option to make terrain objects 
not repeat to infinity.





On Tuesday 09 March 2004 11:08, you wrote:
> Doh!  You guys are right; I see what you're saying.  The terrain geom's
> input data set is a height map with only Y/Z values.
>
> I would address this by adding X/Y (or X/Z) origin parameters to the
> dCreateTerrain functions, rather than supporting transform geoms.
>
> -- jm
>
> > -----Original Message-----
> > From: John Miles [mailto:jmiles at pop.net]
> > Sent: Tuesday, March 09, 2004 11:02 AM
> > To: Eric Buchanan; ode at q12.org
> > Subject: RE: [ODE] RE: Cone and Terrain
> >
> >
> > As I pointed out in an offline reply just now, I already use a
> > banking system with my existing TriMesh terrain, and rather than
> > use transform geoms (which I don't care for much), I just
> > construct the patches on the fly with the necessary world
> > coordinates, and destroy them when they're out of the PVS cache.
> > If you're loading the patches dynamically, why not just apply any
> > necessary translation when you construct the terrain geom?
> >
> > I generally use the transform geoms only for objects that need to
> > be transformed after creation, like CCylinders.  Now that Benoit
> > has added a Y-up version, that won't be an issue for most people.
> >
> > -- jm
> >
> > > Benoit,
> > >
> > > I would agree with the previous poster about the need for Geom
> > > position and
> > > orientation support. I'm current working on a simulation and we
> > > plan in the
> > > future to start using very large terrains at high
> > > resolution(hopefully 1cm or
> > > better) for multiple km traverses and to do this feasible we have
> > > decided to
> > > load our terrain as patches dynamically as needed.
> > >
> > > The current terrain object is wonderfully easy to use, but
> >
> > would benefit
> >
> > > greatly from being able to be translated and rotated and what
> > > not. Otherwise
> > > I'm going to be forced to use triangle meshes, which just don't
> > > seem as quick
> > > and certainly aren't as memory efficient.
> > >
> > > And while this is certainly my problem, not yours. This is a good
> > > example of
> > > why using more than one terrain, and being able to move them is useful.
> > >
> > > Eric Buchanan



More information about the ODE mailing list