[ODE] Methods of handling terrain
ed.jones at oracle.com
Wed Feb 23 12:21:38 MST 2005
There's another example, using ODE and OGRE here;
More Shots: http://www.ogre3d.org/phpBB2/viewtopic.php?t=7846
A Bit More Info: http://www.ogre3d.org/phpBB2/viewtopic.php?t=8011
Although it's fine to use Trimeshes for terrains it's a bit inefficient,
IMHO. And even the terrain collider contributions require you to
duplicate the vertices that you're using to generate you terrain, and
hold them in memory all the time.
What I did was modified the terrain Y collider so that it calls back to
my graphics engine when it thinks something could be intersecting with
the terrain and it asks the graphics engine for the height of the
terrain at a certain point. This means that arbitrarily large terrains
can be supported with no memory overhead from the collider. It does mean
that your graphics engine needs to support an implementation of ray
intersections with your terrain, fortunately OGRE does out of the box,
but it's pretty easy to add, especially as you can simplify it to just
Assuming you're going to want to spend the majority of your time above
ground, personally I'd always use a specialised terrain collider for the
terrain. Then I'd "dig" bits out of the terrain heightmap and put in the
occasional trimesh for the caves, tunnels, etc.
Hope that makes sense.
Jon Watte wrote:
> ODE will work fine for this, assuming you're OK with spherical wheels.
> You might want to use the "double" version of ODE for terrains larger
> than a few kilometers.
> Note that segmenting the terrain will not typically speed up collision
> detection, because the OPCODE mesh representation already contains a
> highly efficient AABB tree. You probably want to segment it for
> rendering, though :-)
> For mesh simplification, google just that, or move on over to Hoppe's
> groups page on the Microsoft Research site. Mesh simplification often
> comes up together with progressive LOD techniques, so that's another
> thing you can google.
> There's a car-on-terrain sample with source using ODE and OpenGL at:
> / h+
> -----Original Message-----
> *From:* ode-bounces at q12.org [mailto:ode-bounces at q12.org]*On Behalf
> Of *Paul Vint
> *Sent:* Friday, February 18, 2005 7:26 AM
> *To:* ode at q12.org
> *Subject:* [ODE] Methods of handling terrain
> I'm working on a driving game/simulation, and am looking for
> people's thoughts and experiences on making terrain.
> My (desired) requirements are:
> 1. Must be able to handle multiple vehicles a long way from each
> other (fairly large world, say 5 km)
> 2. Must be able to convert a *modelled* terrain to ode (I want the
> ability to make caverns/caves, so I believe that the terrainZ
> functions won't fit my needs). (I have already written the code to
> import my models, and have some code for converting to trimesh)
> 3. The "terrain" would include immobile features like buildings etc.
> I'm quite certain I'll be using a trimesh, and that it'll have to
> be "segmented" into x*y chunks to speed up the collision detection
> process. I had previously tried to implement the terrain model
> using a trimesh, but had trouble with objects falling through it,
> but I have never really looked into it again (I dropped that at
> the time and instead spent my time getting networking, sound, etc
> working while I put more thought into how to handle terrain.)
> One specific question I have is: Anyone have a good
> algorithm/concept for calculating LOD of a trimesh? ie: where the
> terrain is fairly flat, we want fewer triangles than where it is
> very hilly/bumpy.
> This weekend I'm planning on working on the terrain, and just
> looking for anyone's thoughts and experiences.
> Paul Vint
>ODE mailing list
>ODE at q12.org
More information about the ODE