It is still early yet in development, but the Collision code has reached a bit of a milestone. I have committed the code and a demo.
The collision code operates compeltely seperately from the core scenegraph and renderer. Links between models and the collision system are called ColliderNodes which are instantiated with a link to the scenegraph node. Each colllider node is marked as being static or dynamic for optimization purposes. If a node is marked as movable then the collision system is free to adjust the node’s transform group parent to move the model as necessary.
Two policies are set for each node. One policy controls the method to be used when collided against and one for when this node collides with another. The available policies are geometry, bounding sphere, ellipsoid and eventually bounding box. So you can moving objects set with a collider policy of ellipsoid and have their collidee policy as geometry. I don’t have geometry to geometry collision yet, but it will be forthcoming.
You can attach forces to each node which act on the node during runtime. For example the ForceGravity class will act as the pull of gravity on the node.
Collision nodes are registered with the collision system and then once a frame you call CollisionSystem.newFrame(long ellapsedTime) and it then handles everything else.
There is still a ton to due before this can be used in your projects. Currently the act of collision is hard coded to impart a portion of the energy to the colidee with almost 100 percent energy conservatiion. There is no friction and no mass yet on the nodes. These effects will all be exposed through an interface so you can setup the collision system with whatever physics you want.
The demo is of a scene with an encosing cube to bound the contents. There are 4 static collidees in the scene, one sphere and 3 cubes. There are 5 colliders in the scene which are spheres, each with the force of gravity applied. The demo starts out by dropping the 5 balls from about 10 meters up. They bounce around and collide with each other and the geometry. There is a lack of smoothness due partially to the lack of a high res timer, partially do to GC since I have not fully optimized for leaking objects (there is lots and lots of vector math which requires lots and lots of temp tuples). The demo seems to stablize after a few seconds and run very smoothly though.
The demo is called Xith3DCollisionDropTest
A bit of how it works. With each CollisionNode you must supply a Collider if you have a policy of GEOMETRY specified. A reference collider of BiTreeCollider has been written which can be used to manage the triangles in a spatial BiTree. Colliders use a ColliiderGeometry to store access to the raw geometry used. There is a method in ColliderGeometry which can take a model (root node in a scene) and pull out the triangles, calculate their bounding spheres and their planes and store them. The BiTree indexes these triangles into an axis aligned plane seperated binary tree. The BiTree can be save and loaded very fast because all its data is in a few arrays of floats and ints.
Each frame the CollisionSystem takes each movable ColliderNode and assembles a set of potential impacts. Each of these impacts is checked for actuall collisions and a set of collision surfaces are assembled. Each collision surface has the distance to the collision, the plane of collision and whether it is a EDGE, POINT, EMBEDDED or SURFACE. These catagories are very important for implementations that want to do something like slide against a surface versus bouncing.
Hope you find it interesting stuff… personally I have found this to be much more challenging technically than the renderer itself.
BTW with this addition of code we now have over 64,000 lines of code in Xith3D.
Dave
