[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