Matthieu LABAN
.NET, My Life, Flight Simulation and Real Flight...

 
About Me :
25 Years old developer and aviation
enthusiast living in Santa Clara, California.
View Matthieu Laban's profile on LinkedIn 
Contact me at :
mlaban at gmail dot com


Photo & Video Galleries:
- Gallery List
- Flight Videos
Resume :
e-mail me to get my latest résumé
PhysX in Infinite Runway 

Don't ask me why... but I got this urge last week to change Infinite Runway's physics engine... It's a pretty stupid move as the physics engine is the most important part of a flight simulator...
Anyhow, I made the necessary backups and started to play with the NVIDIA PhysX SDK.

I chose PhysX over Havok for obvious reasons ;-) But I did look into Havok... They have a pretty extensive support for vehicles, and their SDK is so much cleaner than PhysX's... However, the feature set I need in IR (Infinite Runway) is pretty limited, and PhysX's Api is much simpler to use for this.

The few required things for IR are:
 - A good vehicle model and behavior (for take off and landing roll, as well as general ground handling)
 - A good suspension/spring modelling (for the landing part)
 - The ability to directly place an object in 3D
 - The ability to apply forces at specific points on a rigid body.

ODE (the previous physics engine) featured all of these... but I wanted to move a bit further by defining shapes for the wings, breakable constraints...

One big advantage that PhysX and Havok have over ODE is that they have remote visualizers. PhysX's visualizer and code setup is very much easier than Havok's though.
These visualizers come in handy when trying to figure out exactly what the shapes look like inside the physics engine. Without them, you are pretty much guessing, what the shapes actually look like in the eyes of the physics engine.
I might sound dumb saying this, but when you have to deal with cross Up Axis stuff, not having a remote debugger can be pretty nightmare-ish...

I spent the entire week end (except for a little break to go spin an Aeronca ;-)) trying to adapt IR to PhysX.

If I count the numbers of hair I pulled over the course of the port, I'd say it went like this:
 - 80% trying to deal with Up Axis bullshit... Thanks ColladaMax for not doing the conversion yourself! and Max for being ZUP...
 - 10% was spent trying to make the suspensions look realistic...
 - 10% was spent tweaking the physics up to where it is right now.

I encountered a lot of fluttering during the last part where I tweaked the flight aerodynamics... It was simply due to a misunderstanding of the several layers of Actors/Body/Shapes each of which have their own mass or density... After reading the doc, things got clearer although I'm still missing some parts about how to set the inertia tensor based on the shapes of the airplane...

Here's an early video of status for tonight... The ratios and lift/drag scales definitely need more tweaking but it's getting there...



The funny thing is that the actual aerodynamics part didn't change by a single bit. Its only input is a transformation matrix, and a velocity at specific points on the airplane. And since this is still the same with PhysX, only the values will have to be tweaked :) Hopefully, this won't take long!

About the ZUP issues... The problem was that the assets I'm importing are all oriented as if the Z axis was pointing upwards. And unfortunately, IR is Y UP... And so is the physics engine, as it it setup...
The trick is to inject a simple node at the root level of the aircraft that contains a slightly modified identity matrix. The children all carry this conversion when they are recursively updated. The physics engine and the rest of the game only deal with the converter node, and are then shielded from the UP Axis madness...

Below is a gallery of the latest screenshots taken this past weeks. I made some progress on the scenery modelling...