Physics Modeling

In previous incarnations of the simulation model, I have written the physics code related to movement and rotation. Linear movement is pretty straight forward but rotation is often complicated. There are a number of different ways to represent rotation in terms of the computations, but on the display a pilot would typically want the standard Roll, Pitch, and Yaw (also known as heading, bank, and attitude). These calculations require matrix math and or use of Quaternions to prevent difficulties when using combined rotations on multiple axes. I had had about 90% success but conversion between these and the individual angles never quite worked out.

Recently I found the [http://www.ode.org/ ODE Physics library]. There is a Delphi port, (which works very well with the Delphi OpenGL graphics library as well). I now have a simple model with just the ship as the only body in the simulation. I created a Motion Simulator object to wrap the ODE details. This also allowed me to add the event system interfaces to the Motion Simulator as well. This made it easy to receive events from the clock object to drive the simulator in time with my model as well as receive events from control outputs such as Thrust. So with a few event connections I was instantly able to adjust the thrust applied in the physics model through the remote screens.

The ODE system also has convenient functions for getting the information about the objects as well, so I was able to get position, velocity, and orientation and create outgoing events which are delivered to the console through the same mechanism as my ship modeling. The only challenge in the Console is that currently the functions to update display items assume a one to one mapping with the name of a component and its value. However in the case of the three new values they are actually arrays of data.

Orientation = (Roll, Pitch, Yaw), Position = (x,y,z), Velocity=(x,y,z)

In this case I create an invisible text control on the appropriate console tab that has an onChange event. When the text value is updated I extract each of the individual values and send them to the appropriate controls. It breaks the basic pattern of one message per control, and begin able to have the code automatically set the values, however I would otherwise have to generate individual messages for each value which in this case would triple the number of messages. I would rather let the code do more work than burden the network. So far I have not noticed any performance hits.

Next I am going to work on setting up RCS (Reaction Control System) controls to adjust the orientation of the ship. One thing that is a pain with rotation is that it is very difficult to actually stop the rotation without having a system that calculates what is needed to stop the rotation on any particular axis and automatically applying a counter-rotation. I think I would prefer a system that works in increments of rotation (ideally a specific number of degrees). You would be able to hit a button to turn only the amount requested, before the system would apply a reverse rotational force and case the rotation to stop. It is not quite so simple because the force accelerates to a velocity then rotation occurs and the the force decelerates. You have to calculate the “burn” times plus the inertial rotation time all to get the appropriate distance.

I think there is help in the library through the dWorldImpulseToForce function which is designed to convert a linear impulse to an appropriate force for the requisite number of simulation steps.

Another nice feature which I will eventually get around to exploring is the Geometry definitions that can be attached to a body in the sim. The second main feature of the library is collision detection. The geometry specifications allow the system to notify the program when collisions occur. What is interesting is that you can define multiple geometries. They do not have to necessarily be in line with the actual physical design of the object. In the Spaceroom scenario this could be used with a large spherical geometry as a proximity detector for other objects. That was another very challenging thing to model in previous versions of that I had worked on. Not all collisions have to result in a bounce, however the system can handle that behavior with the appropriate motion adjustments.

Considering that I was able to get this working in just a few hours, whereas my previous attempts took much longer, I am very optimistic that this system will work very well.