[ODE] Slow performence in a given scene - optimizable, or "just how it is"?

[Megan Fox]

Alright, I'm coming up against a performence problem in a semi-dense
scene.  Semi-dense because, while there are a lot of objects in the
world, it really isn't all that "dense"... it's just a desert with
rocks and a single building.  I'm trying to determine if this is
expected/normal, or if I can bail myself out in some fashion.

My concern being that a dense city scene is going to have FAR more
going on than this test scene.  Never mind that I'd ideally like a
region 9 times this size simulated at a time, never mind that I'll
eventually have 8 more terrain grids to the sides of the one grid
currently simulated, all of which are going to need proper simulation
at least as far as the player can see past the load zone.


There are two collision spaces, both hash - one is used for static
geoms, the other is used for dynamic.  I run one collision between the
two spaces, and the one inner-collisions pass on the dynamic space.

In the scene is:

1.) A large heightmap mesh.  The vertex dimensions are 256x256, which
(feel free to check my only-just-had-my-coffee math) should be 130,050
triangles, assuming two triangles per quad, right?  The scale on this
is 8.0, meaning the grid is 2048x2048 units across, with player height
being roughly 15 units.

2.) One to two hundred rocks.  In the "better performence" version,
there is one trimesh per rock, in the "not so great" version, each
rock uses between 2 and 6 ODE geoms.

3.) 10 living entities - each has 13 geoms related to combat (damage
volumes and weapon/shield volumes), a single geom for rigid
collisions, and a large "vis" volume used to determine what they can
see (none of these generate impulses but the single rigid volume, they
just monitor for collisions).  The vis volumes are spheres of radius
50.

4.) One building, with a number of triangles insignificant compared to
the number of triangles in the terrain.  Without my artist available
to confirm, I'd say between 500 and 2000 triangles in it.


A couple of things that have no perceptable impact on speed:

1.) Removing the code that handles the trigger collisions, strangely
enough, does zip.  I thought maybe that was slowing it down, but
nope... everything the same, slow as can be, whether I'm processing on
all those collisions or not.  Which suggests the slowdown is in the
number of potential collisions being generated, rather than anything
related to the number of actual collisions.

A couple of things I can do that really speed things up:

1.) Ditch the vis volume off all the entities.  This speeds it up
assumedly because a sphere that large generates a LOT of potential
collisions, and with 10 of those big spheres spread across a level...
yeah, lots.

2.) Reducing the total number of geoms, either by removing the
physical representation of the rocks entirely or simply going from 2-6
geoms per to 1 trimesh per... that -really- speeds the world up.



The one thought I have to try and fix it is to see if, possibly,
collapsing all of the static geometry down into a single trimesh might
have any effect.  If the slowdown is "just" the ODE-side generating
too many potential collisions, maybe it'd help, but then I'm throwing
a ton more triangles to the other half of things - hard to say if that
wouldn't just kill it in a similar way.

Is anyone else running a phys world of this scale that can give me
some pointers?  Or am I not going to get much better performence than
what I'm already seeing?

Thanks,

--
-Megan Fox
Lead Developer, Elium Project
http://www.elium.tk