[ODE] ODE-GIMPACT performance and advices

[Francisco Leon]

Wow!!, you're working at Novodex?? it is such as a
great honor for me.

--- Pierre Terdiman <pierre.terdiman at novodex.com>
wrote:

> > After some effort
> > it compiles on Mingw but it carries more bugs
> again,
> > giving an strange behavior at runtime. That causes
> me
> > a lot of headeaches.:P
> 
> Well, if you find "real" bugs in Opcode, please
> report them :)

A\:Just try to compile it on MingW!! and then we talk.


--- Pierre Terdiman <pierre.terdiman at novodex.com>  
> > Then when I was planning to develop some kind of
> Cloth
> > simulations I've figure out that OPCODE is not
> what
> > I'm looking for. So GIMPACT arises as the trimesh
> > collision system for full dynamic trimeshes.
> 
> You do realize that Opcode -does- support fully
> deformable meshes thanks to
> the "Refit" function, right... ?
> Both the old Solid 2.0 and Opcode support deformable
> AABB trees (i.e.
> deformable meshes like cloth), through the same
> "refit" operation. Opcode is
> usually faster for this because the "no leaf" trees
> have twice as less nodes
> as Solid, so the refit function is immediately twice
> as fast. And hybrid
> trees are even better since they usually have an
> order of magnitude less
> nodes :)

A\: You can't convince me that it is true. 

Updating a plain array of AABBs is faster a lot than
updating an entire AABB tree with such 'refit'
(refried) function.

 
>. It's kind of funny, because I
> also used Opcode's "box
> pruning" in the past, for deformable objects (this
> time it was called
> "Decode", for DEformable CD...). [I had an IOTD
> about this a while back...
> let me check..... Here, the cloth stuf:
>
http://www.flipcode.com/cgi-bin/fcarticles.cgi?show=63381].
> On the plus
> side, it doesn't use a BV-tree so it's really
> memory-friendly (and that's a
> BIG plus on next-gen consoles). On the minus side,
> what I got was usually
> slower than Opcode's refit trees, and so I
> eventually dropped the whole
> idea. But maybe your implementation is better!

A\: At first I've tried Opcode's "box pruning", and
let me say ... it is not correctly at all, specially
the bipartite box prunning (necessary for trimeshes).
It has redundant and innecessary code  that causes hit
performance on your app. Another issue is that the
Opcode's "Radix sort" is not the optimal
implementation.  On many experiments I've noted that
quicksort is often faster when we have less of 1000
boxes; on the other hand radixsort would better when
we have large sets. 

However, GIMPACT boxprunning code can be optimized
even more. Use your imagination.

> So, again, I'm really interested in speed/memory
> benchmarks between your
> approach and Opcode's

I have to admit that GIMPACT doen't save memory as
good as OPCODE. Also I've noted that it consumes more
memory than OPCODE because GIMPACT needs to keep a
cache of transformed vertices and planes. 

But about speed, GIMPACT remains as the King of the
Hill. No matter what do you say, It is faster. I don't
know why?  Sometimes Brute force astonish me!!
(??????)


However Pierre, I am so glad for taking your
attention. I wish for working shoulder to shoulder
with you.

GIMPACT needs to be tested against other libraries. So
I will publish my oldy ODE-OPCODE implementation, stay
tuned!!. I've already know that you love OPCODE so
much!!! :D

Cheers.




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