Tuesday, 17 May 2016
Last time I mentionned a new patch, but it turns out it might be delayed for a while until we can make an update to the launcher.
Meanwhile I started to work on the new netcode and an update to our physics systems.
Until now, we've been working with the Open Dynamics Engine physics lib ( ODE ) 0.13.1. Unfortunately ODE is an old library. Very old. And it shows signs of its age, design and architecture wise. It doesn't get updated anymore that often, but the worst part is that AFAIK it doesn't really support multithreading, or any "new" advanced physics features. Pure single-threaded rigid bodies. Last time I looked ( last year IIRC ) its source code was riddled with singletons and global variables, which means I don't have much hopes that it'll get a proper architecture fix any time soon in the future. Therefore, we are considering switching to another physics engine.. provided that we find one that satisfies our needs.
ODE, for all its flaws, has a double-precision mode which is critical for us to support large worlds ( aka a solar system ) seamlessly.
I investigated other physics engines, and here are my conclusions:
So far seems to be the best candidate for a replacement to ODE. It does support double-precision too and seems more optimized. Unfortunately it seems to be in a pretty messy state regarding multi-threading and/or GPU support via OpenCL. Bullet3 is by default single-threaded, which is pretty shocking in 2016. It does have a WIP branch for OpenCL, but unfortunately it seems to lack features, doesn't seem stable ( when I tested it some rigid bodies seemed quite unstable ) and worst, has an API that is quite different ( and needs much, much more work ) than its CPU counterpart.
The other candidate is the industry veteran: NVidia's PhysX. It seems really good performance wise, however it has a major show stopper: it doesn't support double precision. Doing some googling, I found out from one developer that due to SSE optimizations it couldn't support fp64, despite the fact that they have a type that can be changed in the source code. Seems like they're actively working on "large world support" though, but who knows when that will be ready..
In the coming days, I'm going to be working on updating our physics interface as a generic, neutral API that can support any of these physics engines. It's already partially the case ( the way the I-Novae engine is designed is through modules and interfaces; therefore we have a physics interface and a module/DLL that implements it in ODE or any other physics lib ) but there are a lot of concepts/objects that are still ODE-specific, and that I need to make more generic. I'll probably end up implementing a partial Bullet module and a partial PhysX module, just to validate that our new physics interface is compatible with all of those in the future.
I've already started to work on these 2 new physics modules ( Bullet & PhysX ) while maintening the old one ( ODE ). I must say, oh boy... where to start... compiling all these solutions is a nightmare. Bullet uses cmake which means it cannot generate a single solution for both win32 and x64, which means integration into our own I-Novae solution ( which does have a win32 and x64 configs ) isn't straightforward. Worse, I've been running into CRT conflicts, as we use Multithreaded DLL ( /MD) while Bullet uses Multithreaded /MT by default. There's an option to use /MD in cmake, but guess what... it breaks Bullet's demos/sample browser. A fix is available but requires updating the make files manually
PhysX integration so far has been going smoother, although I had to solve CRT conflicts too. I went as far as being able to initialize the physics world. PhysX is multithreaded which has some consequences on the design of the module, which is the main reason I'm interested in updating our physics interface to be future-proof.