[ODE] ODE-GIMPACT performance and advices

[Francisco Leon]

Hi Flavien.
You've made some interesting question:

--- Flavien Brebion <f.brebion at vrcontext.com> wrote:
> After checking the API in more details, it looks
> pretty good, and i'm 
> noticing an improvement of x4 / x5 in performance in
> your gammaleon demo 
> compared to opcode ( Pentium D 830 3 Ghz ), while
> spawning a few 
> hundreds of various primitives ( a few cubes, a few
> spheres, and lots of 
> tri-meshes ). It slows down a bit when the objects
> are spawned quickly, 
> but it stabilizes and maintains a very good
> framerate ( 200-ish ) when 
> all the objects are at rest; in the same config,
> opcode gets no more 
> than 40-50 fps.
> 
> I'm still hesitant about GImpact though. It seems to
> handle pretty well 
> the case large amount of simple tri-meshes, but does
> not seem so 
> optimized for a low amount of very complex
> tri-meshes.
> 
> As i understand it, dynamic tri-meshes ( those who
> have a transformation 
> matrix ) requires to update the *whole* vertex array
> of the tri-mesh 
> each time the transformation matrix changes ? So,
> moving a single 
> tri-mesh of 10K vertices at 60 fps requires 600K
> vertex transforms per 
> second ? Also, the per-triangle AABBs have to be
> updated, is that 
> correct ? Note that i haven't measured this
> performance, maybe it's not 
> so bad, but those were my first thoughts when i
> digged into the API.

A: The main GIMPACT paradigm is to precalculate all
results as possible. It saves a cache of the
transformed vertices and the calculated planes from
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. 

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.

But transforming vertices with relative small
trimeshes (around 500 triangles) works good, and they
would be vehicles or characters. In the future we want
to have cloth simulation and deformable bodies; when
it happens, we have to implements a physics particle
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.

In conclusion, is recommended to keep large trimeshes
static, and the smaller can move without problems.

--- Flavien Brebion <f.brebion at vrcontext.com> wrote:
> What are the other limitations of the library ? Does
> it work with ODE 
> compiled in double-floating point mode ? Or in 64
> bits ?

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.

--- Flavien Brebion <f.brebion at vrcontext.com> wrote:
> I noticed some strange defines / settings in the
> API, one specifies the 
> maximum bounding box of the scene to be +-1638.0f,
> what happens if a 
> scene is larger ?

It would carry bugs, but with a little setting it
would be run safely. It would works as this: when
boxes are reaching positions more far than 1638.0f,
then the engine will clamp the coordinates for fix
them with the whole. It is nothing, but those loose
boxes will hit the performance a little.

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. 

So consider to divide your whole worlds in many
sectors; This is a reasonable approach, when you have
to simulate many bodies at same time. In the near 
future we will have paralele processing on many
simultaneous sectors, so we need to divide the world
in some spaces and then running the instances of the
ODE integrator as paralele. That is my vision, 
thinking about the future.


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.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com