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

[Megan Fox]

Typo, that should just read "... never mind that I'll eventually have
8 more terrain grids," the 9 times size bit was a typo.

On 11/3/05, Megan Fox <shalinor at gmail.com> wrote:
> 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
>


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