[ODE] Difference in efficiency between single trimesh geom
andmultiple trimesh geoms?
shalinor at gmail.com
Sun Feb 20 13:30:45 MST 2005
The thing is that OPCODE already contains a separate space
partitioning system, so it's a little unclear to me if it's a better
idea to let OPCODE handle everything unmolested, or to keep sorting
things my way with the chance that ODE's various optimizations will
start conflicting with OPCODE's, causing overall slowdown.
> I'd be amazed if consolidating separate geoms into one big representation
> actually improves performance. It's much better to keep objects separate
> and aggressively disable the ones that aren't candidates for collisions
> (potentially even removing them from the space).
> dSpaceAdd() and dSpaceRemove() are pretty fast in my experience. They are
> your first, best optimization.
> -- jm
> > -----Original Message-----
> > From: ode-bounces at q12.org [mailto:ode-bounces at q12.org]On Behalf Of Megan
> > Fox
> > Sent: Sunday, February 20, 2005 11:01 AM
> > To: ode at q12.org
> > Subject: [ODE] Difference in efficiency between single trimesh geom
> > andmultiple trimesh geoms?
> > Has anyone done any testing on this, where they started with a world
> > full of one trimesh geom per "world chunk entity" (a flight of stairs,
> > a door, a piece of wall, a table, etc), then later moved to a
> > representation where everything was merged into a single trimesh geom?
> > As it stands, each chunk in my world is defined via solid geoms, with
> > said geoms associated with the proper entity - "wall", "wall corner",
> > "floor", "stairs", etc. Moving to trimesh representation of
> > everything (in prep for terrain), I imagine I'll keep it the same,
> > with one trimesh geom per. I'm just curious how much of a speed
> > increase I'm likely to see in moving from this to a single-geom
> > representation of the world, said figure serving as a motivator for
> > changing things in that direction.
> > -Megan Fox
> ODE mailing list
> ODE at q12.org
More information about the ODE