[ODE] PosR - a better way?
Geoff Carlton
gcarlton at iinet.net.au
Thu Nov 11 13:58:16 MST 2004
Actually, the whole PosR structure is one aspect I dislike about ode.
If geoms kept their PosR structure it would be easy to have geoms offset
from their bodies (rather than needing the extra GeomTransform), and it
would also save on allocs. In summary, these are my thoughts on it:
1.) Unnecessary allocs and memory fragmentation.
- In particular the terrain's ray test has a PosR alloc and free every
single time its called, which can be multiple times per frame.
- There is an alloc/free every time a geom is attached or detached to a
body.
- Its by and far the most common alloc I have in the game.
- For previous projects we actually had to write a custom PosR
alloc/free handler to pull these things off a static buffer to avoid
fragmentation.
2.) Keeping a local PosR per geom may take up more memory.
- This structure could be reduced to 3 floats for position and 4 floats
for a quat.
- By making it local, we'd eliminate the 4 byte pointer for both body
and geom, which would mitigate the size increase slightly.
- If there were lots of standalone geoms the size would actually
decrease slightly due to above.
- Lots of geoms attached to bodies would increase the size however.
3.) Efficiency
- Local data would save on cache misses.
- However if we used a quat it may take longer than the current 3x4 matrix.
- If we allowed every geom to have a transform from its body it may be
slower (an early out may avoid this).
4.) Ease of use
- Basically the current limitation sucks. GeomTransform is clunky.
- Its a drastic change so it may trip people up unless backward
compatibility was kept in mind.
5.) Ease of implementation
- I haven't looked through the entire codebase with respect to this
- I'd guess its not trivial but shouldn't be too complex either.
Does anybody else feel the same way about this?
Geoff
More information about the ODE
mailing list