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?

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!

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...

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!

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.

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]

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...

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.

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'.