FSNG: Burn out? Burn baby!!!

Ping to all of ya' outta there. Itz been quite some time when looking at the date of the latest update of this pHunk'd up blog place.

Well, I am very busy in the moment. As you probably know, I'm working on a project called FSNG - a flight simulator.

Now after finishing school, I currently own the status of an umemployed, so I have loads of spacetime to work on the project (this typo was intentionally).

And I do ... very hard. I stand up in the morning, start to work on my baby (FSNG), eat some food on short/rare occasions, and continue to work 'till round about 1 a.m. in the night. Can't remember to have remarkable hobbies - only very rare bedroom DJing 1-2 times a week and maybe formula one; but don't have no doubt that I am hanging over my sketchboard, figuring out my problems, while the cars are racing around the racetrack.

No idea what this guy is talking about? OK, I did a new website, check out http://www.aj-productions.de - you'll find all the details about FSNG there. By the way: it uses very interesting XML-technologies without any content management system eating up my webspace/bandwith. I didn't write a line in this blog about the semi-painful development process, because I simply didn't have time besides FSNG. So please don't bother about this website - it's there now; enjoy it or shut up. Thank you [in Paris Hilton style pronunciation].

Ladies and gentlemen - we are approaching the climax of this post as we get closer to the true message of this post. You are allowed to scream now when done fastening your seatbelt.

So, I've spent half of last week download roughly 15-16GB of SRTM3 elevation. Did I mention connection-burn-out? By the way: If you do not know what SRTM3 is, check out my website or google.

So, 15-16GB is pretty large, but still acceptable when thinking of DVD-distribution. The real problem is: this 15-16GB are *compressed*. Uncompressed, they make up maybe 30GB of data. Ouch, that's not acceptable.

Problems arise, because FSNG has to load the data during runtime in a background-loader-thread, while realtime-graphics are executed and an aerodynamic needs to be kept numerical stable.
So it is *not* designed to do uncompression in a background thread. So I have to store the elevation data in uncompressed form. Did I mention ouch?

So currently I am brainfucking my mind [spirituality] in order to find some acceptable solution; so I can at least half the data amount to 15GB or so (that's my target).

My recent options I figured out are:

• Half the alignment from 2-byte-short to 1-byte. This way, the accurancy decreases to 256 elevation steps, which need to cover roughly 9000 meters of elevation-range. You can figure out the pretty bad inaccuracy: 9000/256 = ... [tired ... start the damn calculator on your own ^^]
• A modifcation of the 1-byte option: distribute the lower range (1-128) to lower terrain (e.g -500 -> 1500) and the upper range (129-256) to higher terrain (e.g. 1501 -> 8?00). This way one has the small details for the low lands, and the large elevation-steps for the mountains, where they occur in fact
• A better concept for the 1-byte-modification option: use an exponential or potential function, where the byte is only a parameter. This way, a wide range of elevation is covered with suitable accuracy.
• -Start first block: Pick the first elevation-point; pick a byte between the full elevation range of 0-9000 and call it orientation-offset. Now take the accurate value of the first elevation-point and store the difference between it and "orientation-offset" in "fine-offset" for this point. Take the next point and store the same offset between the initial orientation-offset the this point's accurate elevation fine-offset for this point. etc...
  
  if fine-offset for point Pn becomes larger +/-127
  -Start second block: Set orientation-offset according to Pn and the fine-offset for all subsequent points. etc...
  
  This way, wide parts of the terrain are reduced to 1-byte-alignment without precision-loss.
• Try to find a (de)compression algorithm which works fast and in-place if possible.
• Store the DEM's as compressed image and simply use some built-in .NET image-loader-class. If this works fast, this could be a serious (and - for me - productive option).

In the meantime, I have (and will continue to) built a sky-system, which renders atmospherical scattering according to some paper. Looks already good by now, altough it still needs work (day/night transition!). Watch out for screenshots on my website in the next few days.