[ODE] trimesh partitioning

[Adam D. Moss]

I'm posting this for 'Bill' who says that he's having all his posts
silently flushed away by the mailing list.

----------------------------------------------------------

Hi Adam... sorry to bug you about this again.  For the life of me, i can't
seem to get on the list.  I re-registered again, but am awaiting
confirmation.  In the mean time, would you mind posting this for me?  I
appreciate it mucho.

Gracias,
Bill

----------------------------------------------------------------------------
------

Hi All,

I'm glad to say I'm liking ODE so far.  I recently switched
from Tokamak.  It was fast as hell, but extremely unstable in complex
systems and the friction model is quite weak.

I'm having a small issue in ODE, but I'm sure there's a way to optimize
it.  Basically, I need to be able to set up a large static trimesh, to
represent my terrain.  The entire mesh, for example, is 256x256 segments
~ 130K triangles.  As I increase the size of the terrain mesh I send to
ODE, my frames seem to drop linearly as the tris increase.  This suggests
there's little space partitioning being done internally to cull
collisions.  I tried dSimpleSpaceCreate, dHashSpaceCreate, and
dQuadTreeSpaceCreate.  In all three cases, my system consists of a single
space, a terrain mesh, and a dozen spheres falling on it.  Just out of
curiosity, is it possible to set up a callback in ODE so it will actually
request the triangles nearest the supplied body?  Tokamak had something
like this, which made it possible to use potentially infinite terrains,
without storing once for rendering, and again for CD.  This would also allow
people to use partitioning structures already in place, such as BSP or
octrees.
If it's not in ODE already... could it be?  Is there something else I can do
in the realm of partitioning the ODE spaces (possibly in a hierarchy), in
order to speed up processing w/ this big terrain mesh?