Contact Information

Name: Matt Habel

E-mail: habelinc@…

IRC nick: Habel


Project Information

Title: Transition away from ODE to a derivative physics engine

Abstract: ODE is currently used in Pysoy to do physics calculations. However, ODE is too precise for our needs which slows down games and does not allow for us to implement physics over a server. I will remove ODE from the code base by creating a physics engine that is based off of ODE's model and current code, then speed up the engine by making it less precise. I will also implement fast forwarding for the physics engine to allow for network synchronization between game client and server.

Summary: I am going to replace the ODE physics engine with a derivative engine which uses ODE's code but simplifies it and exposes certain attributes to achieve faster physics calculations and easier network synchronization. The two issues with using ODE are that it is more precise than is necessary for a game engine, which causes speed issues, and that it does not allow for fast forwarding to a specific physics state. We can fix the speed issue by removing many of the extra calculations that ODE does to ensure accuracy. This accuracy may be useful in ODE's intended use domain, engineering simulations, but in a game, it is simply unnecessary and can be removed to allow pysoy to run on many more devices at higher frame rates. The second problem, the inability to synchronize physics on the game client and server, is caused by ODE not exposing the time delta between frames and also not allowing fast forwarding to a certain physics state in time. I plan to implement a way for Pysoy to jump to a specific time in the physics simulation so that network synchronization can be achieved.

More details I am going to replace the ODE physics engine with a derivative engine which uses ODE's code but simplifies it and exposes certain attributes to achieve faster physics calculations and easier network synchronization.

The two issues with using ODE are that it is more precise than is necessary for a game engine, which causes speed issues, and that it does not allow for fast forwarding to a specific physics state. We can fix the speed issue by removing many of the extra calculations that ODE does to ensure accuracy. This accuracy may be useful in ODE's intended use domain, engineering simulations, but in a game, it is simply unnecessary and can be removed to allow pysoy to run on many more devices at higher frame rates.

The second problem, the inability to synchronize physics on the game client and server, is caused by ODE not exposing the time delta between frames and also not allowing fast forwarding to a certain physics state in time. I plan to implement a way for Pysoy to jump to a specific time in the physics simulation so that network synchronization can be achieved.

Specific parts of my work includen transitioning each individual component currently managed by ODE into its own physics module. These components include the joints, bodies, fields, and most importantly, collisions between objects.

For each part of the process, I will write rudimentary unit tests ensuring that my code doesn't break any of the currently implemented features. However, with a loss of functionality from ODE collisions, there will be a time period where some amount of physics capabilities are lost until I can reprogram them.

By the end of the summer, I will have reimplemented the physics features that ODE provides. The physics will be faster and more optimized for the purpose of a game engine.

To accomplish this, I will first reimplement collisions by copying the code from ODE into our codebase and ensuring that the build process picks up C files into the binary. After I have moved the code from ODE into our library, I will work on replacing the ODE references throughout the codebase to the new location as well as cleaning up any unnecessary parts of the API.

After collisions, I will move onto the bodies, where the process will be much the same as it was for collisions. However, I will need to make sure that the bodies are referenced correctly in their Genie implementations.

Joints can be copied over similar to collisions and bodies, but I can also simplify the joint code by compartmentalizing the code away from the physics solver step.

Lastly, fields will be a more complete refactor because I can integrate more closely with my physics engine instead of having to work around the ODE api. This will involve a slight rewrite to the processing stage that the fields go through.

I plan to have all of the transition code done by the halfway point, and for the second half of the summer, I will be optimizing the physics engine I have rewritten. That will involve identifying unnecessary calculation steps that provide the arbitrary precision that ODE guarantees which game engines don't require. Most of the optimization will come by simplifying the physics solver.


Schedule

Prep work

  • understand how ODE does physics calculations
  • create a plan to untie ODE from Pysoy

Midterm

  • ODE removed from the codebase
  • time delta exposed

Final Evaluation

  • Physics engine works and simulation can be done