Jump to content
  • Advertisement
Sign in to follow this  
Aph3x

Open Dynamics Engine: TriMesh experience anyone?

This topic is 4824 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

Hi all, Looking at integrating ODE again (I keep trying to write my own physics engine, then getting scared). Does anyone have any experience using TriMeshes in ODE? The manual says the stepsize will probably need reducing for tri/tri interactions - can anyone give a ballpark stepsize here? Does it depend on the trimesh geometry and convexity? In general, is it better to use primitives for collision proxies where possible, rather than a trimesh? Any extra complexities experienced? What about 'resting' contacts?

Share this post


Link to post
Share on other sites
Advertisement
ODE has an excellent, active mailing list that you should join (http://q12.org/mailman/listinfo/ode). I'm sure they'd answer your question very quickly there. You can also very easily search the mailing list archive, since it's hosted at q12.org. Just do a google for your search terms, and add the parameter site:q12.org (for example, search for "trimesh stepsize site:q12.org", without the quotes).

Hope this helps!

Share this post


Link to post
Share on other sites
Yes, probably the best idea. I've had trouble registering & posting on that list previously - probably worth another go though :) Forgot about the Google site search - the ODE entire archive download link fails for me...

Share this post


Link to post
Share on other sites
Well, just for the record, here's a quote I found in the ODE list archive:

[Jun 21, 2005] "mesh-mesh collision is a mess."

Ah well... next!

Share this post


Link to post
Share on other sites
I've had no problems colliding complex trimeshes with primitves - I usually use a step-size of about 1/100th of a second, synched to frame-rate.

Sorry can't help with tri/tri collision - but i've heard this is both slow, inaccurate and as was previously quoted "a mess" - though there aren't a great deal of circumstances where its absolutely neccasarily.

Share this post


Link to post
Share on other sites
essentially you should use primitives for all dyanmic objects, and only if you can't get away with the alternatives use triangle meshes for static geometry

[this way you don't have trimeshes colliding with trimeshes, but you also have box bounds for cars and other not excelent things... ODE needs a better collision detection system for triangle meshes and it seems most commerical projects which use ODE don't use Opcode for trimesh-trimesh collisions]

Share this post


Link to post
Share on other sites
Source: Erk 100 hertz update - I'll just up the minimum specs! Currently running at 50 hertz, and I want time compression too :-/

sit: I've thought about this, but just can't visualise an acceptable configuration of primitives to form an aircraft carrier hull! Hmmm maybe... ummm can the primitives overlap?

I'll need collision for my terrain, so that's the trimesh used up then...

Share this post


Link to post
Share on other sites
If you want to use ODE successfully in a complex application, you'll be adding alot of functionality to the system - so don't be scared of manipulating bodies in order to create the effects that you want.

The collision detection method is very open-ended in ODE, so you actually have a great deal more control over what happens "internally" when objects collide than with other more commercial dynamics/collision detection APIs such as Novodex.

With a bit of thought you can set up complex systems whereby objects will not collide when they have certain properties - allowing you to have complicated overlapping composite objects (like an aircraft carrier - most likely a collection of boxes).

Indeed you don't want things such as the wheels of a vehicle to collide with the chassis or springs when driving around - system explosions can easily happen with dynamic bodies being created in close proximity - plus its all alot of extra processing time you dont want to waste.

I also recommend adding a dynamics "preprocess" stage for every dynamic body in your scene to allow you to add things such as simulated linear and angular drag, and even forced terminal velocities - all things which increase stability and control over physics behaviour.

One more thing: a timestep of 100hz really won't severely affect your performance unless you have *alot* of physically controlled bodies collided per-frame. If this is the case you really want to look at some other ways of increasing performance and optimising the simulation - remember a timestep of 100hz doesn't neccasarily mean a graphics framerate of 100hz.

Share this post


Link to post
Share on other sites
Just to note, I tried using ODE, used trimeshes for statics, but droped it in the end cause I really couldn't sqeeze enough performance out of it and believe me I tried, it just wasn't fast enough for me, although my world is preety big it only has about 50 groups of 5 objects (cars with tires) most of the time. I expected it to be faster.

Share this post


Link to post
Share on other sites
Source: Good pointers, cheers.
I've decoupled the rendering from the physics updates, but have a lot going on in the background, with a lot of AI calcs too eventually.
One of the parts putting me off writing my own physics stuff was that contact manifold processing (determining the collision normal) seemed rather non-trivial. ODE manual says this is returned for collisions, which would be nice :)

CRO Guy: Oh dear :( I have a large world (~1000km square). I've assumed I'll have to create separate dynamic 'areas/worlds' wherever physical events are required. I estimate max 30 dynamic physics objects total, with one terrain + ~30 statics in each 'world'.

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!