For the longest time, simulating the rudder in Infinite Runway has been a big problem.
I remember in the early days of the simulator how much I struggled with matrix transformations to compute the right forces...
During turns, the airplane would slip or do completely weird things because the forces were not applied with the right transformation.
What painful times, but in a way, it made me feel like an 21st century aviation pioneer ;-)

I had solved this problem by simply adding support for a vertical wing and hard coding a bunch of things in the wing section code to transform the vectors in the proper space...

Fast forward to the today... I wanted to get back to engine/propeller simulation and I noticed that my propeller blades were using the old airfoil system which was okay, but not as precise as the new system which supports plugin airfoils and better support for multiple profiles along a wing.

The idea was to use the new wing system and actually attach wings as the blades of the propeller... problem was, there was roughly any support for wings that were other than 0 or 90 degrees of rotation on the longitudinal axis let alone wings that were facing up or down :-/ (remember, the hard coded thing...)

I then went back to the code that handled the angle of attack/lift/drag vector computation and tried to figure out how to get those value correctly once and for all :)

After a bit of matrix transformation struggles, I finally got the vectors in order and my first test was to build an experimental model with a V-Tail style rudder. I gotta say, it works great :) It's not like a real V-Tail where it handles both the rudder and the elevator, but more like an Hybrid version of a regular elevator and a split rudder...
I uploaded a video below to demonstrate the handling of the flight model.

This is a pretty good step forward because it will allow all sorts of wing types to be added to the airplane... some that come to mind are STOL Kits, struts, winglets, and propeller blades.
The big advantage of using this new wing system is that in the example of a propeller, i'll be able to simulate the drag generated by a idling propeller, or the drag of the wing struts. This opens lots of doors, and is even better when you think that all these wings can use the custom plugin model to compute the forces, so if anyone is not happy with the drag computation of a particular foil, they can replace it with their own math :)

-

In other news, I'm getting close to welcoming my second partner in this sim effort (First partner being Brian K. who did the modelling of the 172 in the video).
Philippe, a friend of mine from school and colleague from my FXComposer days @ NVIDIA has expressed interest in working on the terrain. I really enjoyed working with him @ NVIDIA so I think it could work out great! At least I could get back to focusing mainly on simulation stuff :)

Happy Landings!
(Follow me on twitter @ twitter.com/mlaban)

I'm in the middle of a move to a new apartment, so I haven't had time to code much on the sim, however, some progress has been made since last update.

I've mostly been working on the database for the world data.
What I'm trying to achieve is to simplify the vector data I'm getting from the Open Street Map database as well as the coastlines file to make things usable in real time in Infinite Runway.
The complexity and size of the database make it impossible to use it directly without some sort of pre-processing.

The first step in building ground textures is to figure out if we are dealing with land or ocean.
I initially thought I could use the OSM coastline database, however it turns out it's way too precise and it's extremely complicated to retrieve in a format that is easy to process.
After reading about the subject and how the guys at OSM were building their coastline data, I crawled my way to a filed called processed_p.shp which contains the world coastlines at a precision that fits my needs.
I then wrote some code to upload all the shapes to a database and updated my scenery builder to output the combined (simplified) shapes in files for quads of 10 degrees of latitude and longitude.
I'm quite happy with the results, the data loads extremely quickly from the simplified files and I can show a map of the entire world in a few seconds.

My next step is to create the files for the landclass, roads and various other types of landscape features. I'm currently building a path simplifier to reduce the number of points on roads while preserving their overall shape.

I recently exchanged some emails with Curtis Olson of FlightGear (very nice guy btw!) and he told me that everything about building a flight sim is always 10 times more complicated than you think at first, but that you eventually learn 10 times more than you thought...

I can totally relate to this with what I'm doing now, I'm amazed by the fact that building a simulator can take me to places like writing stored procedures for faster database queries... :)

I've been thinking lately that I might have another person join me in this insane flight simulator project... I like building the terrain system but I have to admit that making planes fly is much more interesting to me than dealing with threaded loading of quad tree elements...
I have a friend who would be interested in working on just that... I still need to think about it though :)

I haven't written about Infinite Runway in a while, but development still has been progressing...

Here's a quick status update:

- Flight Dynamics
Lots of progress here, I finished the separation of the flight model with the flight simulator engine. The airfoils are now defined in plugins so that if an airplane requires a very specific airfoil, or if someone figures out a better way to simulate lift/drag vs velocity/AOA, they can code their own system and use it.
There is no default embedded airfoil model, the default airfoil is also a plugin.
The engines use the same plugin system, so anybody with a little knowledge in C# could rewrite an engine plugin.

- Terrain
I've made lots of progress on the terrain as well, eliminated lots of leaks and added better support for a floating origin. The floating origin is necessary for huge streamed worlds such as the one in IR. The current system is not the best, the terrain and objects are recomputed when the airplane flies too far from the origin. I've solved the last remaining issue I had with PhysX and global position updates of an actor today, so I'm close to being ready for the ultimate test flight I've bee wanting to fly for a while: an autopilot controlled flight from Palo Alto to Santa Monica :)
I've been leaving the game fly around for about 2 hours as I'm writing this blog post, it's been going  just fine. Started from Palo Alto, flew to Moffet, San Jose, Reid Hillview, Tracy and now the plane is steady on the autopilot on a straight light to Sacramento Executive :)

- Roads, Land class
One thing that is missing in IR is the default terrain. The current system supports satellite pictures but it doesn't have any support for generic terrain when flying outside of areas with satellite image coverage.
I started working on a scenery database using Open Street Map. It does some basic parsing and works in small areas. The plan is to build a huge file system database of the land class, roads, water ways and other features that IR will use to create its textures. I will probably use a system similar to the one described ACES Adam Szofran's paper.
I tried importing a subset of the road database around Palo Alto, just to make sure it worked, and sure enough, the roads and the satellite image match perfectly :) (see screenshots)

For the past couple of months, I've been working on a new flight model for Infinite Runway.

It's much more complex than the previous implementation. The old system was very basic, a wing was represented as a single point of lift/drag which was computed as an average for a certain wing profile.
The lift coefficient was manually created from a graph which was hand tweaked in the flight model editor.
With all the fuss around X-Plane's so-called superior flight model, I figured it was time for Infinite Runway to step it up and evolve towards a better and more precise flight model.

The new system allows more control over the wing and it supports two modes of wing creation.

The first mode has the potential to be the most realistic. It relies on the definition of a wing shape which is used to compute a lift coefficient. It is based on the Joukowsky Airfoil and takes as input the parameters in the form of the NACA numbers. (Based on Nasa Foilsim)
For example, if you know the wing profile of a wing, you can enter it as a wing definition in Infinite Runway, and the simulator will compute the proper Lift Coefficient automatically.
The new design also handles multiple wing sections with parameters like camber, thickness, twist, area, angle... Each of these sections can be tied to inputs like roll, yaw... This allows the creation of complex wing designs. Since each of these sections can be divided in subsections, the granularity of the airfoil simulation becomes much greater than before.

After doing this, I realized that the model I was using to compute the lift coefficient was not the best in high angle of attack situations... It was behaving incorrectly, stalling too early or too abruptly...

I came to this conclusion... which is that I had two options:
- Either take a smart-pill and go back to the equations for lift coefficient computation... :-/
- Or allow users to provide their own airfoil system as a plugin... to allow smarter people than me to compute a proper coefficient based on the wing inputs.

Option 2 sounded much easier... now, about that second mode...

To test the design, I created a second airfoil computation system. The task of these systems is easy:
The simulator engine provides them with the wing sub-section parameters (area of the sub-section, thickness, chord, angle of attack, local velocity...) and all they have to do it return the lift coefficient and lift force for that sub-section.

The second airfoil system is based on lift tables... I figured, instead of computing the parameters on the fly each frame for each configurations of wing shapes, why not allow the user to feed its own lift table per section? (to match an angle of attack to its lift coefficient).
I added an import feature to load output data of JavaFoil, an online tool that does analysis of airfoils and can export data as csv files. I also added a curve editor to fine-tune these lift curves.
The result is much better than I anticipated. The aircraft feels much more realistic, and, more tweakable.
I'll leave it to the fans of Infinite Runway (me and ...?) to tweak those parameters and make the flight model super realistic!

So in the end, if you think Infinite Runway's flight model sucks... you have three options:

Here's a slideshow of what the debug information looks like:

And some new videos of lame landings :)

It's been a while... I haven't posted about Infinite Runway for about a year...

After some side work on other things, I realized that I continually wanted to go back to the coding on Infinite Runway. It's not making any money... but it's what I like to do...

One thing that made me seriously thing of going back to flight sim development is the fall of Microsoft Flight Simulator. It surprised the entire community... and it's a real shame...
It follows the list of cancelled flight simulators like Prop Pilot, Flight Unlimited, Fly!... (RIP)

One person though seems pretty happy about MS FS being cancelled...Austin Meyer, the developer of X-Plane.
He put up a special page up on his website to help orphan FSX users transition to X-Plane...

I never really paid too much attention to X-Plane... I always remained with my first impression that this simulator was nowhere near the level that FSX had reached.

After listening to a podcast where he was interviewed and was bragging about his simulator I thought it was finally time to check it out a little more than the 10 minutes of demo.

The thing I was most interested in was the flight model, and it is indeed not bad :) However, some of the things didn't seem realistic... for instance, I was unable to make the C172 enter a proper spin... that same 172 seemed a bit too responsive on all axes at low speeds...
The ground handling is great better than FSX, X-Wind landings are much more realistic.
One thing I love is that flight model view where one can see the flow of air around the airplane, this is really cool!

After flying with it for a bit, I can say that with some more effort on Infinite Runway, I could reach a level where Infinite Runway could be a serious contender to X-Plane.

I think the keyword to achieve this is: iterations!

I'm planning on releasing more iterations of the game by developing a streamlined process to create the releases.

I can't say too much about the content yet as the feature set of a 1st release haven't been fully laid out yet.

One thing is for sure, I'll be making of lot of efforts to make the flight model as realistic as possible. For instance, I'm working in a new airfoil model to remove my dependency on lift coefficient tables. Instead, I'll be using wing shape data to compute the lift and figure out other parameters such as pressure, velocities around the airplane.
The first sandbox tests are very promising, and I'm just about ready to plug that new model in.

It will be hard, but fun to code :)

So to summarize, Austin, I'm coming for you! (just give me some time!) ;-)

I'm glad to say that aircrafts in Infinite Runway are finally being propelled by actual computation of lift coming from rotating airfoils :)
 
In my last post, I wrote that I needed the following to properly simulate the propeller:

• propeller pitch
• propeller blade velocity at a specific angle (relative to the propeller itself)
• airflow velocity (relative to the airplane)
• angle of attack at a specific rotation point (function of the propeller blade velocity above, and the airflow velocity)
• propeller RPM
• air density
• propeller diameter

It wasn't that difficult afterall. I managed to get all these info from a few vector computations. (except the air density, which is coming from elsewhere)
 
To get the lift generated by a blade, Infinite Runway does the following: 

1. Get the velocity in feet/min of the propeller at 3 O'clock (the descending one)
2. Create a vector pointing downward from the propeller blade
3. Get the aircraft velocity at that point on the blade (taking into account the wind)
4. Substract these two vectors to get a vector representing the velocity of the blade relative to the air flow
5. Compute blade pitch vector. (Point a vector down, and rotate it by 'Pitch' degrees)
6. Get angle of attack of the blade by computing the dot product between the normalized results of 4 and 5.
7. Run this angle of attack and blade velocity (length of non normalized result of 5) through the code used to compute lift/drag for wings (which takes into account the atmospheric pressure, amongst other parameters)
8. Get the lift force, and apply it on the PhysX model.
9. Repeat for 9 O'Clock (some small tweaks and vector inversions required obviously)

This gives pretty accurate results. With the previous model, where a simple force was applied, it was easy to reach over VNE during stable flight.
Now, it is much more difficult as the angle of attack of the propeller blades will decrease with the airspeed, decreasing the generated lift required to accelerate the aircraft further. A variable pitch would be required in this case.
 
Also, this takes care of the P-Factor as during climb and high power settings, the descending prop will have both a greater angle of attack and a higher forward speed than the ascending one. This combinaison of factors cause more lift to be generated from the descending blade (3 O'Clock position), inducing a yaw to the left, which is why we have to apply right rudder on take off on most airplanes.

Below is a video showing the result of the blades lift generation.
Graphs:

1. Difference between left/right angle of attack
2. Right Blade angle of attack
3. Left Blade angle of attack
4. Right blade speed
5. Left blade speed
6. Overall angle of attack of the airplane. (not wing specific)

The first graph is the most representative of the effect where we see that both blades don't have the same angle of attack for any given aircraft pitch attitude. Click on the link below the video to view it in High Def and see the graphs in crystal clear quality ;)

Vector colors:

• Blue is current aircraft velocity
• Red is aircraft Up
• Green is the pitch
• Yellow is the current blade velocity

P-Factor Tests in Infinite Runway from Matt on Vimeo.

The more I read about it, the more I feel like propulsion theory, although very similar to regular airfoil theory, is much more complicated...
There are lots of variables that come into play when trying to simulate this. I'm currently trying to gather some data, formulas, papers about blade theory...
The problem is that some of them go way beyond what I could implement easily in Infinite Runway.

The hard task is to find the right balance between a flight simulator, and a propeller simulator... Gosh! there are complete books about this topic!
If I were to implement a propeller as real as possible, it would take me years, and Infinite Runway could be renamed "Incredibly Precise Propulsion Simulator" but it would stink at everything else... (flight model, 3D graphics...)

The current approximation I'm targeting right now is how to accurately compute the thrust at 4 or more points on the propeller blade.

This requires a few variables:

• propeller pitch
• propeller blade velocity at a specific angle (relative to the propeller itself)
• airflow velocity (relative to the airplane)
• angle of attack at a specific rotation point (function of the propeller blade velocity above, and the airflow velocity)
• propeller RPM
• air density
• propeller diameter
• ???

That is a lot of inputs... So far, I've found only pieces of the solution, no magical all-in-one formula...

I was thinking that using my current system to calculate lift for the wings would work for the propeller as well though... since the blades are wings really, only small rotating wings... they can for instance, stall, just like real wings...

I'm mentioning this part, since propeller handling in Infinite Runway has always been very badly implemented... It's always been a force applied where the prop would be... Not really what happens in real life... but it follows the Infinite Runway principle...

"It's not optimal, but it'll do until I come back to it later on... in the mean time, I can work on something else that's much more fun" :)

Anyway, I'm focusing on this because I wanted to implement P-Factor in a more realistic way, and that effect cannot really be simulated with a 1 point thrust... or well, it could... I could just offset the thrust force to the right of the prop based on the angle between the aircraft's 'at' and its velocity...
The only issue is that this offset would probably have to be set by the airplane designer... It's a simple approximation but it doesn't completely solve the underlying problem, which is that prop pitch, lift and such are not handled in a correct way.

The 4 points approach I mentioned above might (should?) solve the P-Factor issue as well as the proper thrust/airspeed problem...

We'll see how it goes...

Lots of progress has been done on the PhysX front... My initial frustrations, although not completely gone have been mostly solved...

I now have OK ground behavior and am making progress on the flight front... I've updated two aircrafts so far, the Cessna 150 and the Citabria 7ECA.
Interestingly enough, the Citabria feels much more realistic than the Cessna 150.

Infinite Runway now can handle much more precise weight and balance configuration. I added a new system to configure shapes with weights that can be placed at different relative locations on the airplane. It's really nice to tweak the shapes that way to make the weight and balance as real as possible.

The next step from here will be to add new PhysX related things... I thought today that the Wind Sock could actually be simulated like a cloth! How cool would this be??

Now take a look at the following videos showing two wheel landing, a 3 point landing followed by a prop strike :)

Sorry about the poor quality of these videos... Vimeo had issues tonight and none of my uploads actually made it through. Youtube might have the HD version sometime tomorrow though...

Citabria Wheel Landing - Infinite Runway from Matt on Vimeo.

This last one shows a couple mishaps in the 150 :-)

Mishaps in Infinite Runway from Matt on Vimeo.

The citabria is almost done... The moving parts, cockpit, wheels, painting are all done and the flight model is close to the real thing now, thanks to a new feature of FSP called Remote Aircraft Flight Model Configuration System.
 
Tweaking a flight model in FSP involves two things:

• Flying the airplane and figure out what's wrong with the flight model
• Changing values to fix what's wrong

I mentioned here a few months ago that I had found a name for the simulator... I'm not quite ready to reveal it yet... but I'm working on the website...
I've got two versions... one fully in Silverlight 2.0 and one in boring old html+css... I'm not sure which one to use...
 
On the coding side, not much has changed... Lots of things have kept me away from VS2008 these past few weeks... but I'm glad to say they are sorting out... at least I hope...
I'm currently working on modeling a Citabria 7ECA in FSP. This will be the second tail dragger in the simulator, the first one being a Piper J3 with an extremely lousy flight model...
 
Having real flight experience in a 7ECA will certainly help... at least for the non aerobatic part... I'll leave the +60 degree of bank and +30 degree of pitch flight envelope for Bruno to tweak ;-)
 
The 3D model is not complete yet, but the basic shape + initial texturing is done and it looks pretty nice already. I haven't modeled the interior yet, but that'll come last as it's my least favorite part of aircraft modeling...
 
In other news, I now have a twitter account... for those who want to follow, here is where you need to go: http://www.twitter.com/mlaban
 
Time for a bit of GTA IV before going to bed...

Two quick videos before going to bed...

I worked on the Autopilot today... trying to get rid of the shimmering/stuttering effect in the yoke whenever the autopilot was in control. I solved this problem by fixing a long time bug which had the animations of the control surfaces and moving parts tied to the joystick rather than the actual physical damped values set by the flight model.

The way the controls are moved in a different manner for each airplane is done via a simple delayed response with non linear interpolation from the joystick inputs multiplied by a scalar on the input value. The delay is independant for each control surface, so the longer the delay, the slower the aircraft will respond to a user input from the joystick.
An aircraft with a fast response would be an aerobatic airplane, and an airplane with a slower response could be a Cessna, Piper, or even slower for an airliner...

But the jitteriness was not only due to that animation bug, there was another problem with the PID controllers... linked again to the chaining of two pid... the first pid had issues when calculating the derivative for small corrections, which made it output spikes, which in turn caused even more disturbance in the following PID...

I also made some changes to the wind/turbulence system, and the following video shows the Autopilot in action in severe turbulences. I could watch this video for hours... I love how the controls move on their own to counter the wind forces :-)
The second video shows the failure of the autopilot, I had set it to a low speed, with heavy turbulences... it shows how a turbulence that was a tiny bit too strong knocked the plane over and threw it in a spin... It's funny to see how the autopilot is still trying to recover hopelessly during the spin :-)

Just one note though, the airplane doesn't have an spin-out system, I just disconnected the autopilot and got out of it before it was too late!

Autopilot fighting... from Matt on Vimeo.

Severe Turbulences with Autopilot from Matt on Vimeo.

Ever since I started flying on the G1000, I've wanted to find a way to add G1000 support in FSP, or at least something that looked like it.
I had tried simulating the Cirrus Glass cockpit in the past, but the heavy graphics made the whole thing render super slow...
 
The gauges are setup super simply inside 3DS max by entering the gauge C# class name to use for each 3D object desired to be "gaugified".
For example, the G1000 gauge is just a 2D plane in front of to the panel that has his user properties specifying that this plane should be treated as a gauge, and that the gauge class to use is "G1000Gauge".
When reading the aircraft model, FSP will detect that this geometry is supposed to be a gauge and will automatically apply a new texture made of the output coming from the G1000 class. This texture will be updated by the gauge class...
This goes the same for all gauges in FSP.
 
Now, the issue is how do I update the texture?
There are two approaches I see to this problem:

• Render to System Memory using GDI+ and then copy the bitmap to the device texture.
  Pros: GDI+ makes it very easy to do awesome things, so no crazy framework to develop, built in support for text drawing, shapes, transformations, alpha...
  Cons: Can be extremely slow. The part that renders the GDI+ stuff is actually pretty fast and renders at several hundred frames per second depending on the level of optimization. The big downside is the copy from system memory to video memory... This is an extremely costly task and there are no ways around it, as far as I know...
  
• Render directly to a Render Target used as a texture later applied to the 3D object in the scene.
  Pros: This is all done on the GPU, except the part that builds the vertices. So no copy from system to video memory.
  Cons: Making things look cool takes a significant amount of work. There is limited support for string drawing, no built in support for painting shapes, this all has to be done by hand. (I'm lazy, remember?).

I started with the first one, as it was definitely the easiest... then moved on to the GPU approach... realizing that coding avionics like the Garmin G1000 for a Technologically Advanced Aircraft (TAA) would be extremely difficult. I have coded support for rendering rectangular shapes, ellipses, textured quads... but to get to the same l
 
In the end, I think I'll have a mix of both.
Standard steam gagues will be rendered using the GPU path as they don't need GDI+ stuff and the support for rendered quads is already there.
TAA Gauges will be rendered via GDI+ and copied to the video memory, but that work will be done in a different thread.
 
The GDI+ Rendering and memory copy a task that I originally tried to perform in the main thread. This was fine until I added the second G1000 screen. Copying these two 1024x768 textures literally killed performance. I already have some sort of basic scheduling to only render gauges at a user defined frequency, but this is all done in the main thread, which is fine for fast rendered gauges that only have one background and a needle, but for the G1000 gauge, that work simply cannot be done in the main loop.
To fix this problem, I moved the G1000 rendering to its own thread. The gauges double buffer the textures so that when the engine is rendering a texture, the thread is preparing the next one. I can achieve reasonable frame rate (60fps) when the drawing thread has a low priority.
 
I used a similar technique for my terrain tile rendering, only this time, the thread does the computation of the tiles and prepares packets that the main thread will render to textures tile by tile after the scene is rendered. That way, even if the work is heavy, it's spread across many frames, so the overall frame rate drop is not noticeable. Doing all the work at once every two seconds for example will introduce a lag every two seconds, but doing a little bit of work every frame will produce less of a slow down.
 

Now, let's move on to some pics and videos :)

Landing in FSP with Garmin G1000 Preview from Matt on Vimeo.
Take Off in FSP with Garmin G1000 Preview from Matt on Vimeo.

I finally found a website where I can upload HD content. Youtube is becoming older and older with their video quality making me think I could almost reach the same quality with our family's old MDA screen back in the 80's.
I tried a bunch of things to upload high quality content up there, but nothing worked.

Two weeks ago, while watching Diggnation, Kevin Rose mentionned this website called Vimeo that supported HD videos.
I subscribed to give it a try. The subscription process was the simplest I've ever seen! (email, nick name, done!)

Uploading videos is easy, and it IS real HD content! I uploaded stuff last year on Stage6, another HD video website... but I would put quotes around "HD"... the compression factor was way too high with stage6. Vimeo is just perfect. Just send them a 1280 pixel wide h264 encoded video and they will take it as HD and enable high quality playback.

Here is one of the videos I uploaded:

Untitled from Matt on Vimeo.

It turns out... landing an airplane automatically is way harder than it seems... I've made some progress and changed the algorithm to another one that sucks even more...

I've come to realize that neither the angle nor the distance from localizer path are good approaches to the problem... The reason being because setting a rate of turn based on an offset doesn't mean that the airplane will eventually reach the approach path... it just means that it will end up making circles if the autopilot is turned on too far away from the ideal path...

One good thing though... the glide slope part seems under control, the airplane can reach the glide path quickly and maintain a constant descent rate...

The only problem is the localizer tracking...

What happens is that the airplane never reaches a stable state... and keeps oscillating around the localizer...

This can come from two things. I mentionned in my last post that this localizer tracking is made of a chain of 2 controllers. One that will take the error as an input, and spit out the desired correction in the form of a angle to the bank angle controller...

The problem lies in one of those, or even both of them... and might also be caused by another external factor...

1: The bank angle controller might be too slow to correct and adapt to the value set by the localizer controller

2: The localizer controller might be setting incorrect values with too much magnitude to the bank angle controller... or it could even be constantly setting values which resets the bank angle controller, causing it to constantly trying to catch up...

3: The airspeed controller is enabled during the approach. It is set to 65kts, and the flaps are fully extended. It's a given that the slower the air speed, the slower the airplane will react to control inputs and might have a tendency to become unstable and over-do everything...

I couldn't rule out any of those 3... It seems indeed that the regular heading controller also has problems stabilizing to a heading at 65kts and full flaps... But it gets much closer than the localizer controller...

It's not easy to figure out what controller is the culprit... Just tonight, when I was verifying the heading controller capacity to maintain a heading at a given speed, I noticed that the altitude controller had a tremendous amount of pain reaching the set altitude... Thinking that the culprit was the altitude controller, I started tweaking its parameters but nothing really stopped the oscillation around the defined altitude... In fact, the problem was because of the climb rate controller that had its derivative constant set to 0. The derivative constant playing a major role in stopping oscillations, it being set to 0 was not going to stop anything from going up and down :)

Oh well, I'll try again tomorrow... although I think it's not really worth it... The current algorithm for approach tracking doesn't seem very useful anyway... I've got some other ideas... and perhaps I'll find the motivation to read that paper from NASA about the Microwave Landing System which seems to have quiet a bit of information on how to approach the localizer and glide slope and follow it to the runway :)

Here's a video of one of the automated crash landings... autopilot is automatically turned off upon touch down... the rest was manual :)

To be continued...

The focus lately has been on improving the flight model of the Cessna 150... But I also worked a bit on some refactoring in the flight model like setting individual autopilot settings for each aircraft, making the flight model editor a bit easier to use...

Tonight, I played a bit with the autopilot and I wondered if I could use this system to make a fully automated landing system... This would be kinda cool to watch the airplane land on its own... I have all the peices in place to maintain a constant speed, a rate of descent and a heading or bank angle, which are the 3 components needed for an automated landing...

I started with the basics. Figure out what the aircraft position is with regards to the glide slope and localizer. (vertical and horizontal planes on which the aircraft has to be aligned when on a proper path to landing).
I had to use a bit of simple math for that to get the console to output the correct values.

There were several steps involved:

First one was to calculate the vector that would be the ideal glide path to the runway. Having a complete internal database of the currently loaded airports, this was pretty easy. I just had to substract the positions of the runway ends to get a vector coming from the approach end of the runway and pointing away from the it at a slight angle (5 degrees).

Then, the autopilot needed the angle compared to localizer.
This was done by calculating the dot product of the glide slope vector and another vector that comes from a substraction of the aircraft position and the runway threshold.

Then, to figure out if the angle is negative or positive, the trick is to compute the cross product of the same two vectors and then the dot product the resulting vector and another reference vector (the Up vector in this case). The sign of this dot product tells us if the calculated angle is positive of negative.

Of course, the two first vectors needed to be flattened to the ground (y = 0) so that the initial dot product only returned the angle on the horizontal plane...

Once this angle was computed, the next step was to compute the same but for the altitude difference between the ideal glide path and the current glide path of the airplane...

This one was a little trickier... Like the first one, I needed to "flatten" the vectors so that the angle would be accurately calculated and only the vertical difference in the vectors would be calculated by the dot product. The tricky part is that for this one, since the glidepath vector can have any direction I couldn't just set one of the components to 0.

The solution was to project the aircraft position on a vertical plane formed by the glide slope. Once projected this point could be used to compute the dot product between the glide path and the vector from the runway threshold to the "flattened" aircraft position. Same trick of the additional cross/dot is used to figure out the sign of the angle.

So these vector maths gave me 2 values. The localizer angle difference and the glide slope angle difference...

The next step was to plug in a couple of those PID Controllers I mentionned in a previous blog post. The autopilot had the following PID Controllers available at the time:

• Bank Angle Controller
• Climb Rate Controller
• Heading Controller (using the bank angle controller)
• Altitude Controller (using the climb rate controller)
• Speed Controller

The two new ones I added are:

• Glide Slope Controller (keeps the aircraft on the right descent path)
• Localizer Controller (keeps the aircraft aligned on the runway)

The first controller takes care of the vertical control. Its job is to adjust the rate of descent by feeding the ClimbRateController the appropriate values.

The second controller is in charge of the horizontal alignement with the runway by controlling how much bank angle should be applied on the airplane. It does this by feeding resulting values to the BankAngleController. 

For this approach mode, I enabled an additional controller, the Speed Controller so I could leave the controls and let the aircraft fly on its own :)

Tweaking the controllers took a bit of flying to figure out the appropriate constants. I included the KML of the tweaking session so you can whitness the difference between the first sketchy approaches and the almost "perfect" ones:)

Two things I'm unsure about the current system:

• I'm not certain the current angle based difference is good for the localizer. Perhaps a distance based would be better. (distance from the aircraft's position to its projected position on the glide plane)
• I need to figure out a way to get closer to the runway with the autopilot on. In the video, I disconnected the AP just before reaching the pond on final as the airplane was starting to overcorrect violently. This is expected as when the aircraft gets closer to the runway, slight corrections of trajectory result in much bigger angle differences. This is why, at least for the localizer part as I mentionned above, a distance based technique might be better as oppposed to an angle based approach. When close to the runway threshold, the distance from the localizer path will vary much less than the angle...

I'll try that tomorrow...

Meanwhile, here are the videos/screenshots:

This one shows the Cessna 150 on the approach path. The autopilot is triggered just a few seconds after the video starts. Here is the KML file of this video with annotations. Controls are clearly visible in this video. They are a bit jittery... I'll try to fix this... But it shows that the controller actually controls the aircraft surfaces.

Here's another one with a practice landing as dusk... This video includes a great cockpit view with instruments and moving yoke/rudder pedals...

One last, completely unrelated... a Cessna 150 taking off :)

Notice in these following screenshots that I have added the possibility to load my GPS Tracker paths for playback in FSP.

I would like to thank all of you readers who commented on my last blog post, and wish all of you a happy new year!

I guess I'll just keep going and have fun with the simulator, cause it's really what it's all about :) About if and when I'll go commercial, we'll see how things goes...

Couple replies to the comments...

Tom:
"... sometimes i wonder where you keep getting the energy of doing this FSP stuff."

I honestly don't know... I guess it's similar to when some people spend countless hours on something they are really passionate about... (art, sports...).
One of the things I most enjoyed working on this past year was the autopilot. Having a completely autonomous system that can fly an aircraft with different altitude, speed, heading settings is something I'm really proud of. Check out this kml file, it contains an entire afternoon of the Cessna 162 flying around from airport to airport...
And coding this was kind of like being a real test pilot, taking off, switching on the autopilot and seeing what happens next... only in this case, I didn't risk my life doing it :)
The worst thing that could happened is a few hours of "but... WTF is the airplane doing this!! What am I doing wrong, GRRR!!!"
But when it works... that: "Yessssssssss!!! it finally works!!!, I can go to bed now..." keeps me smiling until I fall asleep :)

I'm not sure about that... hehe... Especially because being a marketing guy and a coder at the same time would be a big dilemma...
Marketing guys go around BS'ing about a product (ex: promising impossible crazy features...) to potential customers... Then, they come back to the dev team with the new features to be added, in the same time schedule...
I don't think I could do this to myself ;)

Also, it appears that, I don't write enough technical posts, I'll try to make an effort, I promise :)
Believe me, whenever I finish a cool feature, I always want to post a technical article about it...the major problem is that I code FSP mostly at night... which makes me finish things around 2am when I'm really tired, and all my energy is gone into the coding, and none is left for the blogging... :-)

The issue here, is that I always associate blogging with posting the actual thing on the blog whenever I'm done writing... And this takes time. So from now on, I'll try to use a deferred blogging technique like some people do, which consists of writing posts offline, and actually posting them online once they are ready. I thought google docs would be a nice tool for that purpose... we'll see how it goes...

---

I recently got a new aircraft, a Cessna 150K provided by a friend of mine with much better 3D modeling skills than me! (Brian Kumanchik who flies out of Columbia Airport in California. Thanks Brian!)

This is an important milestone for FSP as it is the first airplane that comes from a "third party" developer ;-)

The details on the airplane are amazing, you can even see the break pads and hydraulic fluid pipes... and the best part about this plane is that the interior is modeled. My previous aircrafts had interiors but since it has always been the hardest part of aircraft modeling to me, having a nice interior is great for once!

The flight model still needs to be tweaked, but since it's very similar to that of the SkyCatcher, there won't be much work to be done here...

In other news, I'm in the process of revamping the flight model editor. I hated its design and it was not very practical. For example, there was no way to edit both left and right wings at the same time. For example, in the case of wings and flaps, where the parameters are symmetrical, a change in one of the wings had to be propagated manually to the other one, and I always ended up forgetting to do it... which resulted in wrong flight model characteristics on one wing compared to the other...

I now have a grouping mechanism to simultaneously edit the flight characteristics of symmetrical wings.

You might wonder why I haven't grouped the parameters of symmetrical wings in the first place... the reason is because in case of failures, I want these to be independent. Say I have a broken flap, of a stuck aileron due to severe icing... I'd like the option to only have one of the sides impacted by the issue...

I tried uploading some vidz of the C150 but I struggled with the new very buggy youtube multi file uploader... so it didn't happen...

To conclude this blog post, here is a slideshow of the new Cessna 150K in FSP!

I found this link on Digg today about another one of those top lists. This one was about the Top 20 Entrepreneurial Quotes.

One that I like... "Some people dream of great accomplishments, while others stay awake and do them" - Anonymous

It got me thinking about FSP, and I where I was eventually going with it.

When people discover about this flight simulator, the first question that comes to their mind, depending on where they stand is:

• Are you going to go commercial?
• Are you going to release it for free and open source it?

I would say, I’m more leaning towards the commercial route… Mainly becaue the idea of flying an airplane for real on the earnings of a entirely personal endeavor would be something I would very much like to experience one day…

But the more I think about commercializing the project (through any form, shareware, donation-ware…) the more I get back to reality… which is:

It’s pretty damn hard to create a flight simulator on your own…

Obviously, difficulty is relative and its definition varies from people to people...

I see writing a simulator as the inverse of a cool Web 2.0 project…

For the Web project, the hardest part is the idea… the technological piece is just a mere formality…

On the opposite side, for the flight simulator, the idea is the easiest ingredient. It is already out there… All the rest is a long set of mathematical, technological, algorithmical challenges… and some of them look so hard to me, I have to digest them for months before I can even understand the topic or come up with a reasonable implementation…

For both, usability if going to be a key aspect… if the flight simulator physical model lacks realism, users are never going to stick around… same goes if the represented area is too small, if the scenery is not up to what it looks like in other simulators, if there is no content/add ons…

I suppose this is why I don’t get much feedback from users about the simulator. Pilots probably say: “well, that’s cool” click the close button and move on.

Reaching the level where users are going to stick around is tough… There are countless things to implement such as terrain that regenerates dynamically, a solid render engine, a model loader, a weather system, a sky rendering system… And each and every one of those tasks represent a multitude of micro-annoying challenges that sometime take days to solve…

I assume you got it… it’s a hard project…

Then why bother? Is it ever going to be something profitable enough to make a living out of it? If this happens, will it be before I die? Even though the donation page was only used by one user over the course of all those years, should I take this as an indicator of the interest of the Flight Simulator community? Should I abandon altogether and do something else?

My rational side tried to get me out of the useless simulator business… I attempted over the last couple of years to get interest in other projects… but after a certain amount of time, I feel bad for the Flight Simulator, and start working on it again… even though no one might ever have fun using it other than me… (have you?)

So right now, I think I’m just going to go ahead and continue developing the simulator, just for fun, and keep going from feature to feature according to what I feel like doing that day…

I’m just a bit sad that this simulator doesn’t get all the attention it might deserve…

I’d be happy to hear from you anonymous readers…

Would you be willing to contribute financially to support the project? To what extents?

Considering the previous well funded failures (FLY, Flight Unlimited, Pro Pilot…) and the linux-like simulators such as X-Plane and Flight Gear, do you think a one man Flight Simulator has its place?

I highly doubt it… but for some odd reason, that’s not going to stop me from going on with the project…

Why?

No idea… Foolishness? Delusion? ... Passion?

You tell me…

Lately, I've veen trying to figure out how I could add realistic water rendering in FSP... The problem I have is that I use satellite images which have absolutely no information about where water is...

Thankfully, seamless.usgs.gov has sets of data that contain useful information such as waterbodies, land cover... I tried the waterbodies one, but I couldn't really extract anything useful from it. It's a set of shapes in a file, and rasterizing this would take some effort I'm not willing to do right now...

I then took a look at the land cover dataset which proved to be much more useful. It's delivered in the form of a GeoTIFF file that contains a matrix of what type of land is at specific points. (Forest, water, city...)

Since it's a raster image with geographic bounds, I thought using my standard texture splitting code would work perfectly.

The way I generate tile textures in FSP is by compositing textures together for a min/max geographic coordinates. These small textures are rendered to an off-screen surface, and saved out.
The idea for the water bodies is to add a second texture to the surface renderer, which would be the land cover information and that a shader would use to set the alpha of the texture to a specific value.

Then when rendering the actual final texture on the terrain, the terrain shader would choose whether to render the actual terrain texture, or realistic water...
I've got the off screen rendering part done... but for some reason there is an offset in the land cover texture... I suspect this is because the texture mapping uses some sort of odd mapping... which is not the same as the one that's used for the satellite images...

I'll try to figure this out...

I made some progress over the week end on the Cessna 162 Skycatcher.

Bruno came over yesterday with his test-pilot hat to take a shot at tweaking the numerous flight model parameters.

I made some videos I uploaded on youtube of some tests with the airplane. Two crazy stalls and two landings.
The landings suck quite a bit... I know... :)

I should also get a Cessna 152 very soon (thanks Brian!) The good thing is that the flight model of those two birds is very close, so tweaking the 152 once the 162 is done shouldn't take long! :)

I also fixed up my common profile shader today... I noticed a bug with materials using both envmap and transparency at the same time. This type of setup is used a especially on canopies and windows of the airplane. So needless to say they look much better now! :)

Now, on to the media:

Here are some screenshots of the maiden flight of the upcoming Cessna 162 Skycatcher :-)
It took me two days to reach that state, but the biggest part of the work is done... Hopefully, it'll look better than that soon !

After some tweaking, I finally got all the components of the Autopilot working. To stress test the system, I coded a simple GPS DirectTo function that automatically switches to another airport within a 25NM radius once the airplane is within 1 mile of the destination waypoint, and keeps doing this forever...
It's real fun to watch the airplane fly around by itself :)

I recorded a two tracks of flights in the bay area. (Click to view in Google Earth)
-> PAO, SJC, E16, WVI, OAR, SNS
-> PAO SJC, SQL, SFO, OAK, LVK, SCK, MOD, PAO

Due to the lack of implementation of a speed controller in the first one, there has been some glitches during the flight... Climbing to a defined altitude without adjusting the throttle was causing it to stall and overcontrol...

It's interesting to watch how all the controllers are fighting with the ailerons to match the target heading and altitude...
Thankfully, I implemented an autopilot circuit breaker (a keyboard key ;)) to disconnect the GPS and Autopilot in case of trouble! :)

Latest screenshots:

Yesterday, I made an experiment on FSP... I let it run the entire day while I was away in San Francisco for Fleet Week (cool event!, loved the low pass of the Blue Angels!). When I came back, the app had eaten around a gig of memory... (for 8 hours). Not good... It's leaking memory somewhere... even though the airplane was standing still and not doing anything (no terrain tile loading/generation).
Then I occurred to me... I needed a way to make the airplane fly on autopilot to check that the simulator can run for long periods of time, especially with the terrain system in action.

It's been almost a year since I worked on the aircraft systems in FSP.
Last time was about implementing an autopilot. I took some time trying to implement it and I got side tracked somehow... But now that I need it, I decided to look into it a little more seriously. Went back to wikipedia on the PID Controller page, and during this year time, contributors made a lot of additions to the page, including graphs and pseudo code. 
I remember last year getting freaked by the formulas, and not remembering much of integrals and derivatives from school. Then after setting the problem down in terms of pseudo code, it all made sense... The pseudo code that is now on the page is similar to the one I did last year, which is pretty cool :)

Makes me think though... I remember at school being so lousy in math and wondering what the hell these derivatives and integrals could even be used for...
Perhaps:
 - 1: I really sucked to begin with
 - 2: It was not properly explained and lacked real world application...

If it was explained properly with real world applications, then I don't understand why I didn't get it...
There's probably a bit of both ;) BUT, I don't remember ONE single exercise that actually pointed to a REAL life example of where integrals and derivatives could be used... It was all "Exercise 1.1: calculate this. Exercise 1.2: calculate that..."
I even recall once where I asked a genuine question to my professor:
"So, what is this used for in real life? Do you have an example of something that actually uses this?".
I think thought I was being sarcastic and got all upset about it! Perhaps he didn't know any real application? Who knows...

Anyway, this is a message for everyone out there who is scared of integrals, derivatives and other signs in formulas... try to lay down the problem and remove the "I'm smart at math, check out at my formulas!" feel by typing the pseudo code and breaking the problem into smaller pieces.

Anyway, back to FSP... I integrated a small PID controller class. It works well now, but will need some tuning of Kp, Ki and Kd to function even better...
The first thing I wanted to test this with was an autopilot HDG (heading) mode to fly a certain heading and maintain it... I quickly realized that to do this, I need 2 PID's. One that will control the other one...

PID1 will be the controller that will monitor the heading and make corrections to it by controlling...
...PID2 which will be responsible for maintaining a bank angle.
It's the same for other axes:
Altitude mode, will maintain the altitude by setting another PID that will control a rate of climb.

That's going to be fun stuff! Last night, I implemented the bank angle system. Works pretty well, and useful when the plane gets out of control.
What it does is take the input values, angle, time, and calculates the output which is fed to the control axes system. So it acts like a real autopilot by moving the ailerons!
It's really fun to put the plane in unusual situations and watch the autopilot move the ailerons automatically to recover!

Tonight, I'll try to chain this to the heading controller, and my heading Autopilot will be done! :)

Quick comment about the latest version of FSP... Turns out there was sort of a memory leak due to a surface being allocated on my behalf by Managed DirectX... It took me quite some time to figure out who was creating that many surfaces. I realized something was wrong when the app started to take years to exit while being locked forever in a DeviceLost event... All the surfaces were being hooked up to that event, and one surface per frame was created... yeah... Nop wonder the game crashed randomly after some time...

This is fixed now, I'll release something soon... with probably a new name for the project ;)
Stay tuned!

Also, the min specs have changed for the latest release. The game now requires a Shader Model 2.0 video card that also supports Multiple Render Targets (at least 2). Check you video card specs for this feature.

Turns out, there was a small glitch in the version of FSP I released a couple days ago. It wouldn't launch unless you had debug version of the CRT. (Installed with Visual Studio 2005).

I released a patch that is available for download on the FSP Page.

Yes, it's true! 1 year a 3 months after last release, I finally decided to release a new version! It took me a day to clean all the code, fix obvious bugs and prepare the release package.

There are so many changes in this build... the list of what's new would be so long... I updated the readme with the most obvious ones. Here is an abstract from the ReadMe file.

• - Reworked the terrain engine. Theorically supports the entire earth. Just needs data.
• - New flight model: 
  •  - Takes into account wing specifications and all types of drag (lift-induced, parasitic...)
  •  - Added flaps (behavior is not tuned.)
  •  - Added a load and balance window (Aircraft->Edit Flight model->Add Weights...)
  •  - Better simulation of crosswind. Not only acts on the rudder but on the entire aircraft body.
• - Added support for models coming from the Google 3D Warehouse. Just drop the models kmz files in ./Airports/KPAO/
  Note about the kmz files. Due to the poor quality of the Google Sketchup Collada Exporter, extremely low performance can be observed when loading certain models. If this happens, try re-exporting the models with the latest version of Sketchup, or if you are the creator of the model, then try reducing the number of objects, materials and polygons in the models.
• - Added support of background loading of terrain. This is still work in progress. Lag can be observed during the loading of the tiles. Note that tiles, once generated, are cached so subsequent loading of the same tiles will be much faster.
• - Added new realistic atmospheric scattering rendering (sky colors)
• - Added time of day simulation. Use shift-A and Shift-Q to modify the time.
• - Added option to turn on/off anti aliasing

There are some regressions in this version:

• - Cockpit support is broken
• - No post processing effects can be used
• - Only 2 airplane models are available. Others will be back online soon.
• - Retractable gears are no longer working
• - Speed indicated at the top left of the screen is buggy
• - Some Z-Fighting occurs in some places
• - Numerous other bugs...

To download the latest version of FSP, click here!

Imported from Google 3D Warehouse. Looks sweet!

I brought the Cirrus back to life in FSP... Some pics before I go to bed :)

Enjoy!

Lots of progress on the atmospheric scattering front... I've got most of it working and I reworked the 3D texture to look more realistic during sunsets... I think the result looks good... at least good enough...

Notice that the higher the aircraft, the sharper the separation between the haze on the sky is...

I had some issues this week with MRT and multisample... but it's mostly sorted out, thanks to DX debug runtime and DBGView...

Looking at the website stats, I get a lot more visits than comments, so do not hesitate to drop me a line to let me know what you think about FSP, I would really appreciate it! Thanks! :)

I finally integrated the Atmospheric Scattering model in FSP and it looks sweet!

From Flight Simula...

One video below. I'm using the SoapBox version of it... I hate how youtube reduces my videos to a bunch of compressed pixels... I mean come on... what's up with the video quality YouTube??? It's 2007!

Video: Atmospheric Scattering in Flight Simulator Project 

The algorithm used is the same as the previous one, except that it now uses a 3D texture instead of multiple individual textures. It makes it much easier to interpolate between textures.

I also added real sun position and a notion of time to FSP...

Alright, 2am... off to bed :)

Some progress on the FSP front... The new Earth system is now fully integrated to the FSP Core. I ran into the usual floating point precition problems as the earth model is horribly huge... but it's all sorted out now.

I uploaded pictures on my picasa account.

And a Video on SoapBox

I finally integrated my new Earth system to the core of Flight Simulator Project.
To test the new system, I decided I would fly a bay tour from Palo Alto. It all worked like a charm! There are still some seams in the textures but overall it looks good. I flew almost 100% of the time over high detailed terrain refreshed as I was flying over it. Really cool!

The earth update system was designed to be updated with my fast moving first person camera, so the slow moving aircraft was just piece of cake for it :)
Memory stabilized around 350-400MB which is acceptable considering the amount of texture that I loaded. I could not really feel the loading of the tiles, no stutters at all!

Next steps:
- Figure out why frame rate is not at 60fps anymore... (dropped to around 25...)
- Integrate my FX Composer 2 atmospheric scattering effect (yay!)

Alright, I'm off picking up my parents at SFO!

Flight Simulator Project - July 2007 (2)

I've read on a forum that linked to here that FSP was dead since it appeared that I was not working on it anymore... well, that's far from true... I'm working on it, but just a tad slower than before... :)

Anyways, today I've been working on adding the relief to the new earth modelling system. It was quick to implement as my old system was pretty generic and easy to use. (GetElevationAtCoordinate())

I still had my old elevation dataset of the bay area to work with, but it was getting pretty limited in terms of coverage... so I went back to seamless.usgs.gov and downloaded a significantly bigger  chunk of Northern California. And I gotta say, it looks pretty sweet in the game now :)

I posted screenshots on Picasa.

Next step will be to plug this new earth system back into the flight simulation code and I predict that this is going to be a pain...
Oh well, we'll see...

The earth modeling in Flight Simulator has been through many stages over the three years of development of the game...
At first, it was a simple plane, then a plane with elevations, then another hardcoded bunch of super-imposed planes with different resolutions, then a pseudo flat part representation of a big chunk of South California, then another attempt at a more realistic model, handling real textures with real elevation data, and finally this new model I'm working on!

I decided to completely revamp the old system when I realized I couldn't go further without rewriting the whole thing from the ground up...
While trying to properly implement runway markings... I found some discrepancies between conversions from real world coordinates to game space and vice versa...
These errors were all due to the fact that our stupid planet is not flat... which would have made my life so much easier...!
Spheres are stupid, let alone spheres that are pretend spheres, like Earth with flattened poles... :)
Modeling it as a sphere sounds like a reasonable approximation, so the new system models earth as if it was a perfect sphere.

Most of the texturing code from the old model still works the same... but is now lacking on the performance side...
It's still using GDI+ for creating the ground textures from little patches, which is not really the fastest thing on earth as far as texture blitting is concerned... also, all my earth textures are stored in a one dimension table...
Okay well, the entire texturing system is wrong...
I have some new approaches to investigate like sorting the textures by areas so that I can perform some kind of quad tree search to look them up faster, and do the actual blitting on the GPU using render to texture... that should increase the rendering time by quite a bit hopefully...

Re-reading the introduction to this post, one questions might come up… why didn’t you think harder and design it as a sphere in the first place?
There are many answers to this question, but here are three:

• Because time makes you suck less at coding stuff…
• Coding something is like drawing a picture on a huge piece of paper… when can you say you are done? Same thing with this case… I want to design a simulator, not spend three years designing frameworks and concepts that are never put to practice…
• Because I am a lazy person… I always tend to go towards the easiest alternative… and it seems to shift with time :)

Click below to see a full set of screenshots I took during the first stages of the dev of the system.

For the past few days, I've been working on a Atmospheric Scattering shader to simulate the atmosphere in the Flight Simulator Project.

The previous model was based on a simple vertical interpolation between two colors, haze and atmosphere with a certain exponential component. This time, I wanted to try something new and actually simulate the difference in vertical space but also in the horizontal space, to see a difference between facing the sun and facing the penumbra at sunrise for example.

I won't go into too much details here, I'll probably write something about this algorithm later, but I think I can pretty much say that it's very simple and easy to understand. Almost everything happens at the pixel shader level using a couple of lerps and dot products here and there...

This model is capable of simulating different times of day, dense fog or light haze. The haze layer height can be adjusted, and setting the view point above the haze impacts how muchs blue sky is visible.

Right now, it only works in FX Composer 2, but the entry points and vertex format are exactly the same as the ones I use for my Common Shader, so it'll be easy to integrate it.

A reader requested yesterday that I upload a high resolution video of the spotlight in FSP. Youtube didn't really give it justice by ruining the image quality...  I just uploaded a high res version here.

Be sure to check out the video page in case you haven't already done so... These are the ones uploaded before I started using Youtube as my video storage area :)

I just found a link to a paper written by Michael Zyskowski on Phil Taylor's blog.

This article is entitled "Aircraft Simulation Techniques used in Low-Cost, Commercial Software" and deals with the way aircraft systems are simulated in Flight Simulator.

I gave it a read, especially at the flight simulation part, and I'm surprised to say that my model is not far from Michael's. The missing inputs in my system are ground effect, side slip drag, flaps drag/lift, and prop wash.

Given the current system, they won't be too hard to add. I'm particularly interested in prop wash (for power-on stalls) and side slip drag...

Going slow, but still going :)

I recently added support for what is called an 'ubber' shader. It's basically a shader that does most of the common things for the Flight sim, from simple rendering like lambert or blinn lighting, to more complex things like normal map, envmap...

This is implicitely leading me to DX10, since I totally got rid of everything that was using the fixed function pipeline.

I've also added support for a very cool per pixel spot light... It certainly slows the rendering down, but it looks so much better than the ugly landing lights of FSX... (How can they be so badly done...)

Next on the plate, follow up on the normal map tests and apply it on the runway and aircraft.

I've uploaded 4 videos showing the new shader at work at sunset and dawn...

Here's one...

Here's three new videos of some google earth 3d files, the Google HQ, San Francisco Airport, and a landing in Palo Alto.

All models are from Collada asset files. Load time is back to something reasonable now. It turns out the massive slowness I was experiencing was due to some error in my parsing of the polygon groups and an accidental linking with a debug build of FCollada... duh!

Happy Landings...

I wanted to this for a while now, getting rid of my current unknown file format used in FSP. It's XML based and exported from a modified IGameExport plugin for 3DSMax.

No one uses it... so it's definitely hard to import models in FSP... I wanted to change this. So this is why this rainy week end where all my tailwheel/night flights have been cancelled, I started implementing a Collada Importer for the Flight Simulator Project.

Collada is a new file format that's being adopted by numerous big DCC companies like Discreet/Autodesk, Softimage, Maya, Blender... The upcoming version of FX Composer, FX Composer 2.0 will have complete support for Collada, Google Earth can import collada data. (This means that I'll probably take advantage of all the Collada content made for Google Earth, sweet! :)

After two days of coding, it's starting to shape up real nice, I have the whole node system, geometries, parts of the effects/materials system with a custom common profile shader and animations already in place.

I used FCollada from a Canadian company called Feeling Software. I have to admit I'm really impressed by this library. It's really clean, nicely done, and super easy to use.

Importing a Collada file is not as easy as parsing a simple model file. There are lots of concepts in a Collada file like Effects, Materials, Material Instances, Common Profiles, Geometries, Geometry Instances, Nodes, Visual Scenes... Appart from some weird conceptions things, it's a really good file format and getting to the current state was way easier than what I thought it would be.

My biggest rant against this file format, is that they left the freedom to specify the Up axis of your scene... I don't really understand why this is in there... it's such a pain to implement a correct converter to Y_UP (Hello Autodesk, the axis that makes sense...!) that works for everything, that I don't understand why anybody would enable such an option for a format that is supposed to be made for exchange between applications...
Constraining everyone (Autodesk, or ColladaMax for instance) to export as Y_UP would make much more sense than to force everyone to support this stupid option...
(I used the Collada Refinery to get rid of this problem)

Anyways, so now, I need to link the materials to the objects and I'll be good to go! :-) My old file format will be gone forever, and I'll be able to import data from almost any DCC app that exists ;-)

I just uploaded a video of the latest shader for the plane. It has multiple point lights that turn on and off based on the state of the strobes.

Though it's a little exagerated, it looks real nice. The effect of these lights also disapear with the light of the day, so you can only see them at night, and barely during sunrise and sunset. FSX doesn't do that, you can see the effect of the beacon even in plain day light :-/

I'm still trying to figure out what could possibly be happening in my flight model to make the airplane vibrate that much after it reaches a certain speed...

This morning, I tried another random google search and found out that this phenomenon also happens in real life. It's called Wing Flutter.

Here are three Youtube videos that show what happens:

For the past week, I've been working on the flight model and the physics of the plane.

It's now possible to add weights in the airplane to change its center of gravity by simulating fuel tanks, pilots, passengers...
I also wanted to revamp the flight model, so I started looking around for some docs about the calculation of lift and drag on an airplane. I found out that my system was still far from the actual thing... I was missing a lot of input variables like the wing ratio, the wing span and I didn't have proper lift coeficient/angle of attack data.
I also added two different sources of drag, the lift-induced drag, and the parasitic drag. By using proper values, it should defintitely make things way more realistic!

To debug all this, I had my "vectors" drawn at the position of the wings, but that was not enough. For example, the plane starts jittering at some point and the vectors don't give me any sort of time indication of when this effect starts... So I implemented a little graphics system to display the lift and drag values in real time and see their evolution.

I'll start using it intensively this week end to find out where the jittering is coming from...

Screenshots of the debugging system

I know, news about FSP have been quite sparse in the past few months... but I've made some progress... ;-)

Lately, I've been working on shaders for FSP. Last week, I wanted to re-implement my aircraft cubemap lighting shiny bright effect. I thought it would be an easy task. Just a rework of the shader. But that endeavor was quickly blocked by a big underlying problem... All of the object normals were completely screwed up. (This had been around for a while!) I couldn't go any further. A proper lighting + cubemap effect requires perfect normals to look nice... The old shader was just plain wrong...

While trying to fix this problem, I discovered so many other problems, some design decisions I took about two years ago that were not applying anymore, or some other things that were not flexible enough...

Of course I completely broke FSP :-/ It wouldn't render anything. My new approach was to use DirectX Meshes more intensively to take advantage of the normal calculation facilities... I feared that approach due to my previous experiences with that class... It seems to like to throw InvalidCallExceptions a little too much for my taste...

After a week of tweaking, where FSP didn't look like anything but a bunch of mushy polygons, I finally got some results.

(See the examples of depressing images on the side of this message)

Now that it's working, I'll be able start implementing my new cool shiny bright light effect tomorrow!

I used two tools I had not really used previously:

• NVIDIA NVPerfHud
• PIX from the DirectX SDK

These tools are really awesome, they gave me precious information on my vertex buffer formats, or other internal data/calls. I especially like the new pixel debugger where you can analyze all the states of a pixel and step through the shader code that rendered this pixel ! (In PIX)
I'm addicted to these two programs now! I suggest you give them a try during your next debugging session! :)

Well, I've decided to cancel the project and do a kernel debugger instead because it's much more fun.

Naah, I'm kidding :-)

I removed the dust off of the code again... It's a good thing I didn't forget anything about the code, and that it's still working!
Lately, I've been trying to implement an Autopilot for the Cessna 210. When I say autopilot, I don't mean lock the object on a spline, but act on the controls to make the airplane do whatever the autopilot settings are. 


It was clear in my mind what was to be done. Just compute the error between the actual value and the target... and it turns out it's more complicated than that. To achieve good results for that kind of stuff, I will have to implement a system based on a PID Controller (Proportional-Integral-Derivative Controller). I'm still getting into the theory. I hope I'll be able to implement something soon!

Stay Tuned!

Wow, I just found out Avsim has a front page news item about FSP, sweet ! :-)

So, welcome to avsim readers who are interested in FSP !

Everything you need to know about this project can be found in the Flight Simulator Project section on the left.

(Big thanks to the Avsim staff ;-))

Happy Landings!

Yes, I’m still working on it !

Since the latest release (a few months ago…) there have been lots of changes.
The flight model is way better now, I’ve reworked the glooming effect, there is an entirely new terrain engine that can take pretty much any satellite imagery, and I just added basic multiplayer capabilities…

The server is based on hummm a server me and my team mates from school coded during our last project ;-)
Since I hate network programming, I thought that would be the easiest way to go !
I only tried the game solo with two laptops, but I have a multi player session planned for tonight.

Anyways, I took some screenshots of the super high res imagery I have for Palo Alto. It’s really cool to fly over places you know and recognize every road, house and such…
You can judge by yourself in the gallery section. I also included high res screenshots (1920x1200) of high res imagery.
The gloom quality sucks, I know, but I had to remove the contrast and luminance filters… their pixel shader code were killing the CG at this resolution :-/

About releasing a version… I’m thinking about it. I almost released something last Monday… Problem is, the satellite images make the download package quite huge… (100MB+)
I tried using Bit Torrent for testing, but it didn’t go well…

Click here for the latest Screenshots

Happy Landings !

Alright, I was supposed to fly today with my roommate and another friends from work... It totally blew, two airplanes were available... the first one with broken strobes and beacon, and the next one with a non-transmitting radio... That was frustrating...

We went back home, and I started coding some stuff on FSP...

I implemented a threaded update of the world... it still sucks a little bit but it's a good start. I could do a flight from Palo Alto, to San Carlos and then to Concord Buchanan :-)
I wanted to do that kind of 'long distance' flights for a while and it's now possible !

Well, enough for words, here are some of the pics:

More Pictures Here

Happy Landings

Looking better every day :)

I have captured new high resolution screenshots of the new terrain engine in action.
I have "fixed" the problem with SFO runways behind non perpendicular... but this is a quick hack, so I'll figure out something better some day... meanwhile, this'll do the trick...

 
Moffet Federal

  
Silicon Valley and Moffet from another angle

Low pass over Moffet

This new terrain engine is starting to shape up and some of these screenshots look pretty good I think... Especially the first one with the view from high altitude...

I'll work on optimizing all that in the next few days and try to release a new version by this weekend hopefully... or maybe sometime next week...

Happy landings
 

I continued experimenting stuff with the terrain today...

I'm too tired to start a long blog post about it and my english co-processor is already asleep... that would result in crappy english writting, so this is going to be a short one...

I'm gonna let the screenshots speak for themselves instead...

On the left, low res of a very detailed area of texturing (before reloading), and on the right, a high res version that has been automatically regenated when reloading the terrain. Some sort of adaptive... something...

Kewl thing is that it can actually span on multiple resolutions now, just like in this example where you have the low and high res versions right next to each other. The texture area is overlapping, so it generates high res stuff on the small mesh close to the camera, and low res farther away... Pretty neat...
On these pictures, the blue squares represent the "texture bounds", and the red lines the "mesh bounds"

Spanning on different resolutions again, but at Palo Alto... Man I need to recover the old style, this looks ugly ! :)

San Francisco airport on the left. High res texture on the center mesh, and low res on the edges... Silicon valley on the right. Texture areas are clearly visible over Moffet and Palo Alto.

Well, that was fun, but I'm afraid I found a important issue in this terrain thing and in my coordinate system in general... If you take a closer look at KSFO runways, you'll see that they are not perpendicular ... and that sucks ...

I think I have a few leads on how to solve that... more soon !
Happy Landings

I did the first tests of terrain texturing yesterday, so far it looks crappy, but I'm researching so I guess that's normal ...

The system currently only supports texturing of relief areas that are smaller than the area covered by the texture. That was the simplest case ...

I'll continue that tonight ...

Check out this first screenshot

Slight improvements, check this out :

Before :
Loading time of full scene : 45 seconds to 1 minute
Memory Usage of FSP : 700~800MB

Now :
Loading time for full scene : 10ms (yes ! ten milliseconds)
Memory Usage of FSP : 150 MB

This huge improvement is due to the use of File Mapping. (CreateFileMapping, MapViewOfFile...)
This is exactly what I needed, and I don't know why I didn't think of that before. Basically, what I was doing before was reading the full altitude database file (a huge table, full of Int16) and copied it to an internal table.
I then used this table to lookup the altitude at a specific point in the world. That was fast, but caused a important memory overhead ...

With this file mapping thing, I don't allocate anything and windows takes care of all that stuff for me (more info on msdn for those who care).
I can look up the altitude pretty much the same way as before, but without copying all the data to my own internal memory. I gain both in loading time and memory. The time required to map the file is insignificant.

All that means I'll be able to feed the sim with HUGE amounts of data ... but that's for tomorrow evening :-P mmmm, I want to test now ..... meeting at 9:30 am tomorrow .... okay, we'll see if I snapped and tried tonight :)

EDIT : yeah... I tried hehe :P it works great ! I have the entire bay area from Napa to Monterey, to the Central Valley, Looks awesome ! :-P

Man, I'm happy :-P
Happy Landings !

A Flight Simulator Project post, for a change ?
Well, it’s no secret I’ve been working on the terrain generation lately, actually, I was working on terrain shadowing…
I tried a Shadow Mapping approach, but it sucked… the terrain appears to be too huge and I faced precision issues …
Since I didn’t have any concluding result yet about this terrain thingy, I decided it was time to run some heavy tests and see how it behaved with huge areas of DEM data.
I shot a video of what it looks like ! It’s still untextured but still, it looks good…

Click here to download video.

Disclaimer : The video suffers from stutters and low fps... I only set fraps to record at 20fps, so that's normal. Also, the DEM data is pretty large, it makes FSP overall memoty usage to up to 800MB... Needless to say my laptop was suffering :-)

Anyways, about how I do that … Well, that’s a little different than all the other approaches I’ve seen over the internet… My explanation is not going to include any fancy formulas or anything…
Basically, I have created in my favorite model editor, a huge set of patches at different resolutions, from very detailed, close to the center, to very sparse for areas far from the view point.
Here’s a wireframe view

Click to enlarge

Why did I do that instead of creating a patch by hand? First, because that’s what I did before, and it was a real pain to generate all that stuff. Even though it worked, some cases were really complicated and it was against my principle of coding on FSP.
This principle is : “Make the feature work and move on with life, you’ll refactor when it’ll really start sucking”.
The great thing about this is that I end up with a working feature, certainly not as optimized as it could be, but it works, and the overall game is moving on. That’s probably why FSP is not only a Terrain Generator.
Because the terrain in FSP started as a simple patch, then more patches, then another thing, and it became what it is now, until next refactor … It might not stay that way, as I think I could do better than this, but meanwhile, it does its job of showing the terrain !
One other great thing is that most of the code that was used in the previous version of each feature is reusable, and even if no code is reusable, I already have a view of what to do, and what not to do…

Anyways, back to the relief generation. The thing that kept me from considering this option was the computation time of the position->altitude lookup. In fact, I found a very quick a dirty solution, with just a couple of rules of three calculations … again … It takes about 250->500 ms to recalculate the height of 105’000 vertices. Stutters can clearly be seen in the video when I recalculate the relief, but this will be done in another thread eventually so I don’t consider this as an issue.

The texturing is generic now. It is purely based on altitude, and the lookup is done via a simple pixel shader that matches the “altitude” of a pixel to a texture coordinate.

The next step will be to actually map terrain textures on that … I have some clues on how to do it, but I think this is going to be the trickiest part…

Happy Landings !

Well, okay, I was supposed to talk about my last flights, and I failed to do it for the last two weeks...

Actually, I didn't fly last week end, my flight instructor was not available so we postponed the flight to this week end.
In short, two weeks ago, Steve (my CFI) found out that I had forgotten some of the flight planning basics... so we shortened the flight and made a little tour around Livermore and Byron.

So this week end, I had to be more prepared and plan all the stuff, which I did better apparently, but then some other issues came to light. One of these was the radio... And I gotta say, my english skills are given a hard time when I'm flying... These guys speak so fast, and apparently don't get that I'm not from around here and don't talk slowly :-) (or speak little (private joke))
Anyways, that was this Saturday, and we scheduled another flight for today (Sunday). The purpose of this flight was to make me work with the radio, talk to many controllers, switch between different radio frequencies, towers, ground control and stuff...

We took off from Palo Alto, and asked for a straight out departure from Runway 13. Right after take off, we were asked to switch to Moffet Tower, which is just south of Palo Alto.
I was surprised that the controller at Moffet handed us to San Jose tower very quickly, when we were still over his airfield... We flew along the 101, and I saw my apartment, NVIDIA from above… pretty cool...

Then, we flew just a little north of San Jose airport, and we were cleared to switch frequencies to Reid Hillview airport. Reid Hillview cleared us for a straight in Runway 13L and an option for a left downwind departure to Hayward.

That part was nice, we flew north west to Hayward, playing with the GPS inside the airplane, a Garmin 430, learning how to use it.
After that, I contacted Hayward Tower that cleared us for a left downwind runway 10L.
This time, I was more prepared for this flight, I actually had a pencil in my hand at all time, so whenever a controller said something, I was ready to jot it down ... That something I had not done in a long time ... One of the downsides of flying only to local airfields where you know everything already...

Alright, so no major problem on this landing. I'm glad I can land Pipers way better than I used to in France when I was learning. I used to fly a PA28 Cadet in Lyon, and I remember always having a hard time flaring the airplane correctly at touch down.
Anyways, we took of again and were cleared to Palo Alto. We contacted Palo Alto over Coyote Hills and headed towards a long final for runway 13.
You'll see on the Google Earth track that on the way to Palo Alto, we didn't go very straight, that's because Steve simulated an engine failure... Apparently, I didn't pick the right field to land on... :-P

At Palo Alto, we did a short field Landing, approaching at full flaps, 60 knots, then 55 knots... engine at idle. That gave us a 500ft/min descent rate. I never thought we would reach the runway.
The landing was rougher that usual, we didn't have much speed left at that time, but that was still ok, I didn't break anything :-)
During that flight, I was tracked by my two GPS friends, the Holux and Garmin 96C GPS devices.
I recorded tracks on both devices just to compare which one was better, and they both seem to be reporting the same positions.

Here are the Google Earth KML Track files :

 Sunday's Flight (Garmin 96c) Palo Alto, Reid Hillview, Hayward

 Sunday's Flight (Holux) Palo Alto, Reid Hillview, Hayward

 Saturday's Flight Palo Alto, Tracy, Stockton

 Two weeks ago Palo Alto, Livermore

Happy Landings

Long week end full of code and biking, that was great ... On the coding aspects, I began implementing my terrain system, I think it has some potential hehe, but the shadow thing still clearly sucks ...

You can see what it looks like in the picture... It is vertex based and calculates the lighting at each vertex based on the position of the sun... I'll try to optimize all this stuff during the week ... I think this will greatly improve the visual quality of the terrain in FSP...

This picture is showing the Silicon Valley, with San Jose airport on the right ...

Happy Landings ...

I did a little work on FSP today, mainly on the Terrain Engine. I wanted to have a more open and LOD oriented system ...

I'm experimenting different techniques, mainly to avoid the hassle of having to programatically create the levels of detail. I'll discuss about this in a later post I think, but I just wanted to post this screenshot because it looks kewl :)The colors in the picture are based on the altitude and are applied in a modified version of the Fog shader.

Well ok, just a few words about this experiment... In a nutshell, what you see is a precomputed mesh that I built in max. This mesh is translated underneath the camera and all the vertices are recomputed each time the camera moves out of a defined radius. I know it sound stupid and dirty, but I want to try this option just to see if it sucks as bad as I think it does... The re-computation part is faster than I thought so that's a good point...
What sticks is the time that my algorithm takes to recompute the normals of all the vertices in the mesh... that'll be my objective for tomorrow, but now, time to ... zzzzzz

Well, everything is going ok here :-) Besides the crappy weather of course ... but people say it'll get better soon ...
They better be right, I have two flights scheduled for next week end !

I've been working on FSP for the past two days, revamping the flight dynamics ... Scary business ... I hate to touch to this part of the program, I'm always afraid to screw it up ...
I got some help from my Oakland Flyer pal, he is pushing FSP to its limits and giving me a hand with some math stuff, so hopefully, we'll have more realistic flight models soon !

I've made some modifications to the weight and mass system, basically, I plan to add a way to add weights wherever I want in the plane, to simulate fuel, pilots, bagages and whatnot...

I'm thinking about releasing a version soon, with enhanced shaders ...

Anyways, April 7th is coming, and that's cool !

Happy Landings !

As promised, I have uploaded a bunch of videos showing the latest things added to FSP.

The cirrus in the videos doesn't reflect the very latest version because since then, I've added moving parts and a cockpit.

Click here to see the videos

Happy Landings

One big change today in FSP, I have added a new aircraft : a brand new Cirrus SR22.

Adding this airplane to FSP’s fleet has been on my todo list for a very long while, and yesterday I decided I was going to take a shot at designing it.
It was one of the hardest planes I ever had to design. The shape of the aircraft is very peculiar so I had to struggle with the vertices of the plane to make it resemble the actual thing.

It’s still unfinished work, I only modeled the exterior parts of the airplane, and a raw interior. So far, I’m satisfied with the result. I think that the interior is going to be challenging, especially because of the full glass cockpit … I don’t know why but I feel that I’m going to have to re-think my whole gauge system because of that …

I also worked on the runway lightings. I implemented three new lighting types :
MALSR : Medium Intensity Approach Lighting Systems Runway Alignment Indicator Lights
ALSF-2 : High Intensity Approach Lighting System
Center Line : High intensity center line lighting system.

Both MALSR and ALSF-2 lighting systems contain ramps of lights and a flashing line of strobes that really look great in the sim !

I’ve uploaded a bunch of videos to the website so you can appreciate this yourself :)
(More on that later, I need to create the page before)

Also updated is the airport scenery at Palo Alto. Check out this screenshot

Couple last :)

More screenshots here

Happy Landings

Shaders:
One of the things that have been bugging me for a while now is the gloom. I don't know if anyone ever noticed, but it had an offset ... I had a few hypotheses about this problem and I thought that to correct this problem, I had to refactor the whole filter chain of FSP. So this is now done and the gloom shader works like a charm.
I was kind of fearing that I wouldn’t be able to recover the original look and feel of FSP but it didn’t change, I put the correct shaders back in place and everything went back to normal…

Scenery:
Two weeks ago, I got contacted by someone from XP Simulation. They make sceneries for X-Plane, FS2004 and Alsim…
They offered their help with sceneries and provided me with two complete airports : Brussels (EBBR) and Malaga (LEMG)
I ran into some issues integrating Brussels airport in FSP. First, my runways were way too long compared to the scenery (todo : investigate on that…) and apparently, we didn’t have the same orientation for at least 2 runways out of three…

The import of Malaga scenery went better, and I could add it to FSP in a little less than an hour.
The scenery looks nice, it’s great to see new content in  Flight Sim Project !
I uploaded screenshots in the gallery here.



Runway Lights:
Also, I figured out that one of the greatest hits on frame rate was the latest addition of the runway lights. I investigated and found a great way to improve performance on that type of rendering… Point Sprites. As usual, it took some time before it worked, but I eventually figured out how to integrate them in FSP in place of my old slow sprites thing.

Okay, time to go sleep …
Happy Landings

While browsing my referers, I found out I was linked from an Avsim thread (here)

The post is about Flight Unlimited 3 becoming old ... (RIP, I loved this sim...) and Pete, one of the posters, says this :

"If youre up for another free sim, the dynamics of the 'Flight Sim Project' seem pretty good too"

I love to read comments like that =) I never thought my physics were really crappy but being mentioned next to X-Plane and FSX, this is cool hehe...

Thanx Pete, whoever you are :)

Lots of refactoring today for FSP. I have changed the startup form so that we can specify the airport we want to fly from. I have also added support of situation files à la FS2004. The Flight menu now contains a Save Flight item that allows users to save their flight and even set it as default startup situation.
Okay, okay, I'm ripping off MSFS ideas there, but since I use this often in FS2004, I thought adding it to FSP would be a great move.

There is still some work required on this. I had to move some code around to initialize parts that are now used in the startup form.
I guess it'll be done by tomorrow.

To test this startup location thing, I flew from KHWD to KPAO at sunset. This was too easy so I added wind and turbulences to spice up the flight... and man it was fun. I had to go around at KPAO ! The airplane was shaking so hard, I almost hit the runway :-P

After landing, used the kewl replay feature to take some screenshots of the whole thing...

I'm starting to realize that this sim could actually go somewhere... It lacks data but the feeling of flying from one point to another is getting better and better...

As always, screenshots !

 
Going around on the left, Short final on the right

More screenshots...

Happy Landings

Have you ever noticed that for every single terrain engine there is out there, there is at least one screenshot of the Grand Canyon?
Mine was missing one of these, this is now fixed!
Since the terrain system now supports DEM and SRTM data import, I thought I would also take FSP's origin point somewhere near the Grand Canyon and take a few shots…

Boring project today at school, some financial things we had to analyse… I got bored, and decided to show off with the Flight Simulator Project :-)

I was demonstrating to SharkOne the new lights and clouds, when I got an idea… Why couldn’t I go to a French airport, just to see if FSP crashes or not…
I was not sure of how it would react since I *never* tested it anywhere else than in the US (Negative Longitudes and Positive Latitudes). Since the coordinate system thing is full of stuff like ‘value = _Lat + _Offset - Scale * someVariable’ I was kind of expecting the worst… It’s supposed to work … but you never know … (I’m sure some of you know what I’m talking about :))
So, I used my new fancy Go To window, and selected runway 34 at LFLY my home airport when I’m in Lyon. To my great surprise, I could actually see a runway, over the void, but still, I was correctly positioned on the it!
I tried a few more, LFPG, even KJFK, KORD, the runways were there!

Tonight, I had an idea. How about adding some relief below these runways?! Fired up Internet Explorer went on seamless.usgs.gov and downloaded SRTM data for the region of Chambery, a nice mountainous place in the alps, just a few miles east of Lyon.

I flew there so many times and I just love the “Col du chat”. It's report point in Chambery Airspace where you fly low over the mountains and dive over the Bourget Lake while turning along the ‘cliff’ to avoid crossing the IFR approach route… It's a great place where you really feel like you are flying !
You can take a look at pictures of my flights to Chambery here, here, here, and here.

Here are a couple real life samples :

 
Col du chat and Bourget Lake in real life ! (mmm, FSP sure is ugly compared to that ...)

Anyways, I downloaded this data and loaded it up in FSP and here is the result:

 
The lake from south east 

 
The Col du chat 

  
Slopped Terrain ;)

 
The Bourget Lake

I'm glad it works, so who wants to fly from France to the US in the Citation now ? ;-)

To close this post, just a couple pictures from last summer on the tarmac at Chambery... Two idiots with their toys ... and our ride for the afternoon !

Happy Landings !

I finally managed to have a few hours to myself, just enough to release a new version of the Flight Simulator Project.
Here is the changelog for this new version:

Changes in version 2.0.2203 (2006-01-12) :
- Moved to Framework 2.0
- Default location is now at Palo Alto of Santa Clara Airport (KPAO)
- Options Menu now contains a "Go To..." option. Just type the name of the airport you want to go to, and click OK.
- Added automatically generated terrain
- Included airfields are : KPAO, KSFO, KSQL, KHWD, KNUQ.
- Runways and Ligthing are autogenerated from DAFIF files
- Added strobes to the Cessna 210
- Added support for clouds (Disabled by default, go in Options->Options...->Settings (performance) to enable)
- Runway lights are disabled by default. (Go in Options->Options...->Settings (performance) to enable)
- Smoothed camera transitions have been removed temporarily, until I found a cooler system...
- Aircraft now collides with relief ! (Landings on slopped terrains are now possible)
- Reworked the Effects pipeline (this is internal, so who cares?)

Most noticeable changes are :
The move to the .net Framework 2.0:
This is a great thing. I didn’t upgrade to Managed DX for .NET 2.0 though. I ran into problems with buffered input so I had to give up this option.

Automated Runway and Lights generation:
They are explained here and here

DEM Terrain:
The modeled area is now wider and adding new terrain will be easier now!

I guess this is it, time to go back to school projects…
Happy Landings

Yeah … I’ve been meaning to post about the stuff I did during the holidays…
Two things have changed.

The Terrain :
I have refactored some of the terrain engine. The gaps I had in the terrain are now gone, well, almost… There is still an occasional gap here and there but the huge things that were visible before have disappeared !
There was a problem in my algorithm; I was ‘forgetting’ one of the rows of the terrain… So, it’s no precision issue like I feared it would be :-)

The Airports:
The area covered now includes the following airports :
KPAO, KSQL, KNUQ, KSFO, KSJC, KHWD… Best thing of all it that all of these airports have their runways *auto generated* !! 
I’ve also worked on the lighting system. I’ve thought about some technique to do this properly and support all types of lighting based on what is on each runway definition. Of course, this data comes from unmodified dafif files, so it’ll always be up to date ! :-)
Now I only coded two lighting types :
- Regular Runway Ligthing. (White lines on the edges, green and red lights to indicate the beginning and end of the runway)
- Runway Threshold Identification Light (Flashing lights on the threshold, on each side of the runway)

I could fly from Palo Alto (KPAO) to San Carlos (KSQL) and even to Hayward (KHWD). The cool thing about this is that I didn’t even include special code to support all of these airports. They just appeared in the game :-)
Now, I just have to include new terrain, and all the airports will be present at their actual location! Actually, they are all there now, but over a big void since I don’t cover the whole earth yet.

About an update… I guess it won’t happen before the end of this month. Work is going crazy at school. I’ll be clear starting February 1st, so expect an update around this date. It’ll include all these new exciting improvements!

 
Taxi at KPAO

 
Bay Shore Flight and HWD

More screenshots here

Happy Landings everyone !

Like I said in my last article about the Flight Simulator Project, I’m moving the default location of the game to KPAO. This gives me the opportunity to stress test some of the coordinates stuff as well as the airport data things…

I added a Go To window to select an airport location by a keyword search. This window shows the runways from which you can take off. I’m running into problems with this feature mainly because I can’t find a way to successfully disable ODE bodies when I abruptly move the aircraft to the new position.

The wheels are attached to the main body via an ODE Hinge2Joint, and have to catch up with it at a tremendous speed when the aircraft has moved. The force applied to the wheels then throws the aircraft in random directions … I’ll try to find a workaround for this … (why do I feel like I’m writing in crappy English?)

Anyways, this system is starting to look like something cool and I have been able to make a little flight in the south bay area from Palo Alto Airport to Moffett Field. The runways on the screenshots below are all automatically generated as well as the terrain elevations.
I found a kewl way to make the airport at the correct altitude, by adding a flatten area of the dimension of the runways, maybe this is crappy, but it appears to be working…

This altitude thing also made me work on the slopped terrains, so FSP now supports slopped terrains and potentially slopped runways…

More Screenshots...

I think this is going to be all for tonight… I’m gonna go sleep…
Let’s hope the weather in LFLY will be clear tomorrow so that I can take F-GYKB for a little spin in the cold! :)

Happy Landings

Last week, I decided I would check if my coordinate system worked a little farther than the Los Angeles Metro Area. I downloaded the data for a couple of areas in the San Francisco Bay.

It turned out, it works ! :) I still have some inaccuracies here and there, but the overall is correct and the runways seem to be correctly positioned.

Here are the first screenshots of San Francisco International Airport from a few thousand feet.

  
Offset at KSQL and No Offset at KSFO before textuing (I misplaced the aerial photography on KSQL, it was late...)

 
KSFO from different angles

Happy Landings

A few month ago, I dismanteled a machine that I no longer needed .. The contents of this machine have been sitting around on my desk ever since... I don't know why, but today I decided I was going to check what was on one of the 80GB drives that used to be in this machine ..

I found an interesting project that you may have heard of if you read the article I wrote in the November issue of PCPilot Magazine.
This article mentions a car simularor project that was the starting point of the Flight Simulator Project. And today, I found it hehe :)

I've always loved to find old stuff I've done a long time ago :)

Maybe some day I'll write about a couple of Flight Simulator 98/2000 projects I've worked on back in 2000 ;-)

Happy Landings

I continued to work on the Airport/Runway system today. Lots of refactoring took place!

Now the airports in the airport directory are not loaded each time the simulator is started. Instead, I make a query to the AirportsManager, asking it to return the airports within a 20 NM radius, then for every airport, I look for its scenery. If none is available, the default stuff is shown.
For every airport, the runways are now processed, and displayed in the game as a simple sprite with a texture.

I've taken the Citation for a little spin to LAX and monitored the whole thing on Google Earth :-)
I've figured out there is a small offset in the scenery at LAX.
I've noticed some inaccuracies in the position detection and on the aircraft model when it was standing still on the ground... I'm getting close to figuring out what the distance-to-origin limit will be...


Today, I have also tried to revamp the external camera system ... and it turns out I can't do it ... I've spent a few hours trying to mimic the FS style camera, but I can't do it ... I'll come back to that later :-P
I never give up hehe...

I think my next move will be the runway lights, I want runways to light at nite...

I also had a nice comment-chat with Andreas Jung today in this post, you might want to check it out :)

And now, some shots :

  
Google Earth View and Long Beach Runways
 
Short Final at LAX, and LAX Overview

You can view the entire gallery here.

Happy Landings !

That's what this post is going to be about...

The Coordinate System:
Two months ago, I implemented the premises of a coordinate system when I built the terrain engine and the Google Earth Interface. This system was not including the airports. In fact, when third party designers (well, only me :P) designed an airport, they had to displace the whole scenery in 3DS as if Santa Anna airport was the origin of the world. This was not the way to go. So I changed this to a new way of doing things, kind of like the way we designed sceneries back in the FS98 days. (it might still be the same thing today though)
I added in the Airport.xml configuration file, that exists for every airports, a reference position in earth coordinates. This reference point is used to place all the objects that belong to this airport at runtime.
This is currently working, even though I have a little displacement of a few feet, but that’s hardly noticeable.
With this system I’m currently able to set the aircraft start position “theorically” anywhere on the globe. (I wouldn’t count on weird coordinates like the poles though…). This displacement will eventually be done at runtime to reset the center position and avoid big transformation values.

DAFIF Files:
I’m glad the log file now contains these entries :

Loading Navaids ...
Loaded : 2829 Navaids
Loading Airports Data ...
Loaded : 9994 Airports
Loaded : 24691 Comm Frequencies
Loaded : 13879 Runways

Okay, this only a file parsing, but I can now process a lot of new stuff like the runways. To my big surprise, they are correctly positioned in the game!
The screenshots show the runways, but no actual texturing is done yet. I’ll work on that later.

 
Long Beach and Los Alamitos Runway Debug

Shaky Gauges:
After a little chat with a friend of mine who works in the graphics business ;) I decided I would work on the shaky gauges issue.

This happened when the airplane was flying too far away from the origin. I need the gauges to be precisely positioned on the aircraft panel.
But when numbers were getting too big, the decimal precision was too weak to accurately place the instruments. Therefore, they were shaking.

To solve this problem, I had to change the way I rendered the aircraft in cockpit view. It’s now rendered at the origin. That way, I keep my floating point precision to the top and the instruments are no longer shaking!

One more problem fixed on my route to the endless world ;-)

Happy Landings

Well, since last post, I haven't worked a lot.

I've added a couple of things on the clouds to make them faster to render. This should be available in the next release. But they remain a frame rate killer ...

There is one thing that have been in my mind though ... It's a problem that you can experience when you fly far off in the terrain... You'll notice that in Virtual Cockpit view, the instruments start shaking... I think this is due to floating point precision.
So right now, I'm trying to find a way to overcome this problem by recentering everything periodically ... I don't know if it's the best approach, but I'll try that and see how it goes :-)

I don't really have a choice anyways, if I don't do that, the terrain will be limited, and I don't want that...

Not much news since last post about a month ago… I’ve been very busy on other stuff, but now I’m back to business.
I’m sure every reader of this blog saw that the final build of Visual Studio 2005 was released last week. I had to try to build the simulator with it.
Of course, I ran into problems ?

Managed C++ Wrappers:

I knew these would not compile and I would get one of these weird link errors …

First one I got was about unknown references to DirectX assemblies. Apparently the project converter forgets to transform a macro and leaves a “{reference path}” instead of the actual path or something. I removed the references and added them by hand and the error got away.

Second thing I had was a problem during the linking. I got a link error that was saying that some .ctor function was missing. Of course with no information on what type this constructor was not found in. I only had a mangled function name to work with :-/
I browsed Google and found that I had to add these libraries to the linker additional dependencies.
In case it might help anyone, it was : “msvcrt.lib mscoree.lib msvcmrt.lib”. (does that make sense ?)

ODE :
There was another linker error with ODE. It was unable to find this function: “__iob”. I found out it was called from a printMessage() function withing ODE source code.
I recompiled ODE with the content of this function commented out and everything compiled alright.

fmod :
No specific problem besides the ctor and the reference path thing.

So now, I have the simulator running against the .NET Framework 2.0 !
I put some generics in the sim. It seems like it’s running a little bit faster. But I have 63 ArrayLists and Collections to convert so I’m far from being done on that one.
One problem I have though is that when I run the simulator with F5, it is freakishly slow, about 12fps … I get 60+ in Ctrl F5 … If anyone has a clue on that, let me know.

Also, take a look at this : 

This is the class diagram I generated with VS2005.

Click to enlarge

I’ve also created a simple Line Counter Visual Studio add-in (real easy with VS2005) and it tells me my .cs and cpp files count a total of 13000+ lines. Of course, this is the raw count, leaving the InitializeComponent()’s, comments, empty lines, and other generated functions.

Happy Landings,
Matt

Reading the latest article on my blog doesn’t really tell first time readers what is it I’m doing. That’s why this post will be permanently linked from the main page of my blog and updated as frequently as possible.

Here we go!

What is the Flight Simulator Project?
It is a project I’m developing as a hobby. I go from feature to feature and try to build a fun simulator by approaching all the aspects of this type of game.
It features aircraft dynamics, weather, winds, time of day, visual effects, several aircrafts, replays, DEM data import …

Are you working with Microsoft Flight Simulator team ?
I wish ...

Is your project Flight Simulator 2006 or Flight Simulator X?
Nope ...

How much time did you spend on the game?
I started in May 2004 and developed it in my spare time ever since.

Where can I download it?
On my website here

What is the development language?
The FSP is developed mainly in C#. Some parts of the game are developed in Managed C++ (fmod and ODE wrappers)

What Graphics API are you using?
I’m using Managed DirectX 1.1. I never moved to XNA and i'm not planning to to so. Next API update will be for DX10.

How do you simulate the airplane physics?
Plane physics are simulated using a physics library called ODE. For more information about this library and how I implemented aircraft physics, check out this post.

Isn’t Managed DirectX slow compared to regular unmanaged DirectX?
If you’re talking about execution speed: perhaps, but not that noticeable.
If you’re talking about development time: hell no!

Are you a team?
Nope, just me for both code and graph.

Are you planning to go commercial?
Perhaps one day.

How can I help?
Contact me at flightsimulatorproject at gmail.com

Can I create add-ons for your game? (Airplanes, sceneries)
Sure. If you have a GMax aircraft model that you would like to see in FSP, contact me and we will work something out.

Can I dump all the other simulators and use yours exclusively?
That would be stupid, the FSP is far from being as complete as any other sims  available today on the market.

How can I uninstall your simulator?
Duh... Just remove the directory from your computer.

How old are you?
I was born on March 24 1981. You do the math :)

Are you a real world pilot, Does it help you in the development?
Yes I am. I fly Piper Warriors, Archers, DR400, Cessna 152, and lately tailwheel aircrafts like the Citabria 7ECA.
Flying for real does help in the development of the game.

What kind of 3D Model formats do you support?
Collada files

What's your education?
I have a masters degree in computer engineering from a french school called Epitech.

Where do you live?
In Santa Clara, California

Can I make add-ons to your game?
Sure! FSP Supports aircraft add ons and scenery. The specs are not out. Email me if you have cool aircrafts you would like to see in FSP.
Also, FSP now supports Google Earth KMZ files. So you can drop any kmz file and see it where it should be in FSP!

Flight Simulator Project, that name is.... yeah...
Yes, I'm looking for a new name... any ideas?

The latest issue of PCPilot, a popular flight simulation magazine (printed on actual paper !) is out !

Page 36 of this issue includes an article I wrote about the Flight Simulator Project, how it started, what's fun in developing it, what's not ...

I haven't had the chance to get my hands on a copy yet, I'm really impatient !

Many thanks go to Mark Embleton and Derek Davis for giving me this opportunity.
Not so many thanks go to my spam filter who almost made me lose this chance to talk about the Flight Simulator Project.

One last thing, it seems that a bug appears on some users with the latest version (exception at launch time), I'm in the process of identifying it and will fix it as soon as possible. If the latest version doesn't work for you, try the previous ;-)

Happy Landings !

Lots of changes to report in this post !

The flight simulator earth modeling I’m currently in, contains a step I could not skip. The Navaids. A Navaid is a navigation equipment that is on the ground and that helps pilots when they are flying. There are hundreds of them all over the world. They emit a signal on a frequency and the on-board radios receive it and tell the pilot useful information.
I didn’t want to insert all these navigation aids by hand in the simulator, so I had to find out how the other simulators did to import all this data.
It turns out there is a US military website that contains all sorts of worldwide flight related data (Airport locations, runway types, beacons, ILS …) This is called DAFIF (Digital Aeronautical Flight Information File) and once again, it's free !

I started with the navaids (VOR’s and NDB’s). The file that contained this data was about 1.5 mb of text. I parsed it and reformatted it to include only the US beacons for faster lookup in the game.

The system is now in place, and as you can see in the screenshot underneath this text, the DME shows the distance from KSNA to SEAL BEACH VOR (115.70 Mhz), that is located right next to Los Alamitos Air Force Base.
One thing that I now, is to see debug text like this one :
”Found : SEAL BEACH - SLI - 115.70 Mhz - Distance : 11.2811019896512”
I don’t know why, but I love to see text from real world stuff in my sim !

  
NAV 1 on 115.70, Seal Beach VOR on the DME !

To use these navaids, I had to work on the instruments again. There was no NAV/COM radios in the aircraft yet. It took me quite some time to implement this cause I got stuck on a stupid bug. For some reason, at a certain angle, some of the objects were all lit … It took me a little time (3 hours  of “Ohh, I see ! Now it’ll work …”) to figure out that one renderstate was not properly set ...
Anyways, this got fixed and now the NAV-COM and DME instruments are working ! I like how they look especially at night.

I also implemented a new shader in the game, a saturation/brightness/contrast shader to spice up the colors of the sim ! I think I’ll leave this to default values and let people set these values to whatever they prefer.

Oh ! I almost forgot!
A replay mode is now available ! It records the 125 seconds and you can replay it just by pressing a key ! It’s a really neat feature, especially for a geek like me who enjoys watching his landings !
This replay feature had to come with another, the tower view ! What’s a replay without a tower view anyway !
This new view gave me the opportunity to shoot the aircraft from new angles and watch its behavior in crosswind landings ! This made me figure out that I’ll certainly add another force-point to the aircraft in the middle of the fuselage. The cross winds only ‘push’ the tail, and while this is not bad, I doesn’t feel like the real thing …

Well, enough said, here are some screenshots !

   
Tower views
  
Tower Views again

Tower view take off

Everyone is talking about Google Earth ! It's my turn to jot some words on my blog about a couple things that use Google Earth to display data. Of course, this is aviation related ...

First thing, the GPS:
On the pilotlist last month, I read that some pilots were importing their GPS traces inside google earth. A GPS Trace is a list of positions that the GPS records when it is on. This trace is exportable via the USB port of my Garmin GPSMAP 96c via Navigation, a free software developed by François Fouchet. Navigation helps pilots planing their flights graphically, a really helpful program.
It didn't work at the begining, but after a few tests and some mails to the author about GPS incompatibilities, I could partially import the traces and export them to Google's kml file format. So here's what it looks like when within Google Earth.

The trace of my last flight to Grenoble St Geoirs

Second Thing Flight Simulator 2004 :
While browsing my logs, I picked up a google search referer, searching something about Flight simulator and google earth. I typed this in google as well, and I found out this website : http://www.elbiah.de/flusi/.
Jürgen Haible coded a bunch of utilities for flight simulator, amongt which, MyFsGoogleEarth, a Google Earth link. This program displays flight simulator data in google earth.
I tried it yesterday, and it works quite well ! It shows your aircraft position as well as all AI Controlled traffic around you. This is great for some tourism flights :)

What it looks like in flight sim

In Google Earth

In Google Earth Again ...

Two weeks ago, after the sun shone on my flight simulated world, I felt like something was still missing … A Lens Flare … well, that’s kind of a trivial thing to implement really, all you need is bunch of textures and a couple vector calculations …

The result achieved by this lens flare thing is really cool, and for those who know me, I couldn’t help but spend some time taking a few screenshots. J