Quote:Original post by hplus0603
Actually, the Novodex SDK supports trimesh-trimesh collision, if both have pre-calculated PMaps.

Then they aren’t trimesh of arbitrary complexity are they? They is a boxel space quantization of the mesh.

Quote:Original post by hplus0603
Also, most of them have a special convex trimesh type which works more robustly than concave trimeshes; ODE does not. (you can use plain SAT etc on convex meshes)

They are not arbitrary complexity trimesh either, it is just a special case of triangular meshes called convex hull. Novodex is not the only engine that support then, all the others do too. Havok, Meqon, CmLab, Tokamak, Newton, True Axis.

For arbitrary complexity trimesh-trimesh, there are not known algorithm capable of doing two things 1 determine the closest distance between solid of a arbitrary complexity, and 2 calculating the minimum translation distance that will separate then if they are intersecting. So No there are not physics engine out there capable of handling solid or arbitrary complexity as triangular mesh.

There are methods like the boxel spaces(pmaps or whatever is called), complex partitions, lattices of particles, convex strips, iso-surfaces representation (marching cube), and others, than can do a good job but they all has short comings. And they engine supporting them, has then as check list features.

Quote:Original post by hplus0603
I find ODE to be much better than writing your own. You should use a trimesh for the static world, and use proxies (spheres, ccylinders, boxes) for the actors. I've never found performance to be a problem -- if it is for you, you should profile it and see where the time is going.

The problem is that with ODE, you can make demos that can show even thousand of boxes bouncing in a flat plane. But when you want to make something useful with those bodies, for example keeping then steady in some kind of useful configuration, then you have to start playing with parameters (they called tweak the physics).
Essentially you jack up the solver iteration to make more stable, and you have to apply an abnormal amount of penalty and damping to the bodies. In the end to get the same level of quality offered by any other engine, ODE is the slowest.

In addition of the top speed of and engine, you should also test the speed/quality curve in a more realistic application environment.
More realistic tests are things like making a stack of say 20 or 30 boxes of equal mass and keeping it on without auto sleep and zero damping. The stack should state put without swaying at all for at least 1 minute or so.
Another good test is placing some 100 or 200 mass unit boxes on top of a stack of 10 of 15 boxes each one mass unit, and check that the stack state put for 1 minute or so with out notizable interpenetration of oscilations.
Other test are bilateral joint stability, and flexibility (are they prone to blow up or dismember)
If these basic test are not satisfactory, is does not mean you can not use the engine, you can use it if your primary goal is row speed, but be prepare to wrestle the engine all the way from the start of development until the end and beyond.

[Edited by - jovani on August 28, 2005 8:04:34 AM]

Basically its agreed that ODE is not the most complex, full-featured physics library out there.

But its completely free, its mature, and its very fast if used correctly.

I've successfully used the primitive/trimesh collision system many times and achieved system stability with no collision errors or explosions.

Most of the issues can be attributed to the fact that official development on ODE (at least by Russel Smith) seems to have stopped - at least for the time being - and of course newer free engines have been released since, possibly integrating more modern/more effective techniques.

That said it is still a very nice library for anyone trying to implement physics into a game - possibly for the first time - and remains a very valid alternative to a commercial (this includes Novodex) engine - when used well.

Quote:Original post by jovani

Quote:Original post by Source
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.

Actually this is not necessarily truth, despite ODE been and open source library, it is not flexible at all.
The collision system in particular is outdated.
The only collision primitive that is reliable is the plane collision with other primitive. Everything else fails to work properly from time to time.

Not flexible? Let me point a few things out in ODE's documentation:
- Section 10.8: User defined classes
The first line: 'ODE's geometry classes are implemented internally as C++ classes. If you want to define your own geometry classes you can do this in two ways:'
- Section 10.11.2: Using a Different Collision Library
The first line: 'Using ODE's collision detection is optional - an alternative collision library can be used as long as it can supply dContactGeom structures to initialize contact joints.'

Those two things alone mean not only can you completely rewrite the collision detection (to fix your 'outdated' collision system), but you can also create entirely new objects (like cones, pyramids, cylinders, etc.). Exactly how does this make it 'not flexible at all'?

Also, hplus0603, binding trimeshes to the world is all good and fun until you want to start moving the mesh around. For instance, to simulate an earthquake, it'd be more annoying to move every object, than it would be to move the mesh. Personally, I find it easier to bind it to a body, make that body ignore gravity, and have one-way collisions so it doesn't get moved by 'non-static' objects.

Finally, if your objects start falling through other objects, perhaps the semi-physical objects aren't dense enough (I found out the hard way). This wont help fast moving objects, but as I pointed out, you can fix that yourself.

Quote:Original post by jovani
Wow 500 million triangles, I never saw that either. How did you store the data? My impression was that the address space on a pc is 2 gbyte of memory. By my calculation 500 million triangles required over 10 gbyte of memory. And how did you render that? You must have an extremely optimized engine.

First of all - i was not speaking of trimesh vs trimesh collisions, but regular "simple primitives" (spheres, ccylinders, boxes) vs trimesh collisions.

It's quite obvious that such a high amount of data doesn't fit into system memory, which is why i mentionned a streaming system. Not all this data needs to be in memory at once. I calculate potential collisions using an octree and the bounding boxes of moving objects, and stream the tri-meshes that are potentially on their way. As for rendering.. it's a similar system (streamed from disk), but in addition it has a pretty complex visibility system based on precalculated occlusion sets. It's not a game though, it's a CAD software for the visualization industry.

I agree that ODE is far from being perfect. It has some issues with stability (or "tweaking parameters" as some like to say), mainly. But as far as flexibility and performance go, it's perfectly fine to me.. and it's free.

Y.

Quote:Original post by Ysaneya
It's quite obvious that such a high amount of data doesn't fit into system memory, which is why i mentionned a streaming system. Not all this data needs to be in memory at once. I calculate potential collisions using an octree and the bounding boxes of moving objects, and stream the tri-meshes that are potentially on their way.

Oh I see, essentially you implemented a special partioning data structure with some kind of special locality, in a massive storage device. That’s very good, but I think you could have done the same with any of the other engine as well, as almost all of them provide a method for interfacing application specific polygonal soup with the collision engine.

Quote:Original post by Ysaneya
But as far as flexibility and performance go, it's perfectly fine to me.. and it's free.
Y.

Some of the other engines are also free, the only thing they do not have is the open source license.