[ODE] ODE-GIMPACT performance and advices

[Flavien Brebion]

Francisco Leon wrote:

>triangles for saving work on successive queries. It is
>specially good with static meshes that don't move very
>frequent. So that is my personal interpretation of
>temporal coherence. OPCODE claims to have it, but it
>isn't applicable when you have to find all contacts
>between two trimeshes, and OPCODE forces the app to
>calculate transformed vertices (and planes) on each
>query every time. 
>  
>
Static meshes that don't move very frequently. Is that really useful ? I 
mean, i can understand static meshes vs simple primitives, or dynamic 
trimesh vs static trimesh, or dynamic trimesh vs dynamic tri mesh ( in 
this context, a "dynamic" trimesh would be a trimesh whose 
transformation matrix is updated by ODE every step ). I can imagine a 
dynamic trimesh, like a vehicle, that moves continuously every step, 
then is parked and becomes static. But i can't imagine a dynamic trimesh 
that you'd only update every N steps.

>Transformating vertices A PRIORY isn't reasonable when
>you have large trimeshes moving, but I think that it
>is a quite rare: Do you imagine a Building moving
>every time? Do you imagine a Mountain moving every
>time? it sounds impossible.
>  
>
As i explained in my e-mail, i'm working on a sci-fi game that features 
spaceships of all forms and dimensions, some of them being definately 
building / mountain sized.

I understand that my game is more the exception than the rule, but i 
have to wonder if it's a good idea to replace opcode ( which is quite 
generic ) with GImpact, which from the sound of it, is more geared 
towards specific types of scenes.

Don't forget that ODE is not only used for games.

>system, and each particle corresponds to a vertex on
>the trimesh. In that case vertices are transformed
>every time without any worry about. GIMPACT has an
>advantage in this case.
>  
>
Certainly.

>Currently GIMPACT precision is for 32 bit only. But if
>we want 64 bits we'll have to change some #defines and
>constants, and compile it on a 64bit platform. We can
>leave that task for later.
>  
>
Just wanted to be sure.

>GIMPACT has to limit the scene bounding to
>[-1638.0f,+1638.0f] because it does spatial sorting in
>two dimentions : X and Z. It reaches more speed but
>limits the scene dimentions. 
>  
>
In my scene, i have a terrain that is planetary size ( spherical terrain 
). Your portal / section idea wouldn't work in my system. The size of 
the scene is absolutely gigantic, i have human-sized features ( 
vehicles, buildings ) on a perfect 10,000 Km planet. But again, i'm an 
exception.

>So Flavien, thanks a lot. Every critice is welcome.
>You have to understand that GIMPACT is a quite
>inmadure, and it is currently on Alpha stage. I'm
>working hard for complete the whole documentation, and
>your questions helps to complement information about
>the library. Documentation is often harder than
>programming, you know that.
>  
>
I know, and i'm not criticizing your work. I believe it's definately a 
step in the good direction, even though i'm starting to believe it's not 
the "magical solution" to replace opcode as i initially thought.

I just wanted to speak of those issues since i saw many people on this 
mailing list proposing to replace Opcode by GImpact. I'm not saying it's 
a bad idea, but i just want to make sure it's an educated decision and 
that everybody is well aware of the new "restrictions" that GImpact 
would add to ODE in comparison to Opcode.

F. Brebion