Jump to content
  • Advertisement
Sign in to follow this  
rjackets

Terrain Collisions/Physics with ODE

This topic is 4859 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have looked through the articles and whatnot on this site and elsewhere regarding terrain collision detection, but I'm not quite satisfied with what I've found. I am using ODE physics and I would like to do collision detection with the terrain. First and foremost I simply need to know what the best/fastest way of doing collision detection WITH ARBITRARY terrain. Second, if possible I would appreciate it if someone could make some suggestion as to how I could use ODE to do it. I need my objects to be able to collide with arbitrary terrain and I don't think regular plane/box/sphere detection would work in this instance since I was decent physics with the collisions. Thank in advance for replies.

Share this post


Link to post
Share on other sites
Advertisement
I think what you want are tri-mesh collisions. You'd need to have your terrain in a triangle mesh format.

Tri-mesh collisions are not perfect in ODE but they do work. Most common cave-ats are discussed on their mailing list.

The installation documentation that comes with ODE talks about how you can enable the tri-mesh collision support.

A few possible starting points:
http://www.mindcontrol.org/~hplus/carworld.html
http://benny.kramekweb.com/carterrain/

Share this post


Link to post
Share on other sites
Hi-
Yes you'll want a trimesh at a quality possibly slightly lower than that of your rendered terrain, though not too much lower as then your objects will start to penetrate the ground slightly. If you're using LOD of some kind then this isn't all that difficult.

Also make sure you don't replicate any vertices in the point array as this comes with a slight performance penalty.

Other than that I recommend a high-res quadTree space as my primary "global" space. Then you can split your terrain into pieces, each in its own simple space under the primary space. Complex heirachical objects should also be in their own spaces - though these need only be simple ones.

I had a pretty fast system up and running at a reasonable framerate using these techniques - though if you're not careful then even a few objects can seriously impact performance!

Oh, one more thing: If you want to have tonnes of stuff moving around then you might consider increasing your timestep - though this can result in instability.

Hope that was of some use :)

Share this post


Link to post
Share on other sites
Thanks for the replies. I considered using the tri-mesh feature but I wasn't sure it that might be too resouce intensive or something, but it would seem this is the way to go. One other quick question, however: if I do this via a quad-tree/LOD system then would the terrain need to be generated dynamically so that only "nearby" verticies are included in the mesh or is there a way to subdivide the terrain more efficiently?
Thanks again.

Share this post


Link to post
Share on other sites
I'm sorry could you rephrase? I'm not getting the dynamic part, or the nearby vertices part - its late here :)

Share this post


Link to post
Share on other sites
Sorry. What I mean is, the terrian is going to be composed of a number of verticies and triangles and all that. But if I only want to render a certain portion of it wouldn't I need to generate a "new" mesh using only the verticies that I want to draw? And along the same lines, if I don't need to generate physics collisions with parts of the terrain that are not within viewing distance then how do I not include them in the calculations? I hope thats a bit clearer.

Share this post


Link to post
Share on other sites
Yup, I've got you now:

Terrain is usually generated from your map-editor in chunks of a certain number of tris. Each chunk also has one or more lower-resolution versions of itself composed in a heirachy.

These chunks are then put through first your view-frustrum-culling algorithms, and then an LOD level is selected usually based on distance from the camera. Then they are rendered.

These same chunks can be used for your trimesh-collisions. You already have all of your data in a nice format for creating tri-mesh segments, split into handy sections. ODE's quadtree collision spaces will automatically disregard chunks of trimesh which are not going to collide with objects that are far away, as long as you choose the chunks and place them in spaces under the primary quadtree.

You will have to collide with things that you cannot see though, as otherwise your level will fall apart as soon as you turn your back or move far enough away.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!