This page discuses possible data structures to store the 3D physics information. If you are not familiar with this subject you may like to look at the following pages first:
I can think of the following requirements for the way that we store 3D physics information.
- It must allow the physical properties of an object to be defined alongside its geometry and appearance.
- It must allow these objects to be added or removed to/from a model.
- It must allow fast execution of the simulation.
- It must store the models efficiently and not require a lot of conversion before the models are run.
- It must not put an upper limit on the complexity of a model and must scale up efficiently.
- It must use open and free standards.
Of course there is a difference between the data structure used for the long term storage and exchange of the models and the model used within the computer to hold the model while it is running, but these are not independent. For instance VRML has SFNode parameters which have a hierarchy based on the way that VRML is stored, so it is difficult to convert VRML to a flat structure when the simulation is run. Also VRML has SFRotation parameters to represent rotational quantities, this uses axis angle wheras physics is more efficient using quaternions or matricies.
I have proposed two structures to store 3D physics information on the following pages:
I think I am coming to the conclusion that the external format needs to be a heirachical format like the scenegraph, but the internal runtime model needs to be a flat relational database type structure. However the VRML/X3D standard does not seem to be very well suited for this as there seems to be a lot of overheads in translating it to a flat structure that can run physics simulations efficiently.
I've been coming to the conclusion that such as system could be coded as a scene graph (tree structure) cross linked with a table holding the state information.
The scene graph would hold for each object:
- Physical properties, mass, inertia matrix, coefficient of friction, elasticity, etc. in local coordinates.
- Shape (boundary) in local coordinates.
- Constrains, for instance a joint, would define limits to movement relative to other objects.
- Any info required for rendering (textures, bump maps, normals).
- cross link to state table.
The state table would hold things that change every frame:
- linear and angular position (in absolute coordinates).
- linear and angular velocity (in absolute coordinates).
- boundary sphere (in absolute coordinates).
- External forces
- cross link to scene graph.
Do you have any thoughts on the data structure requires for such a simulation?