A quick thought on procedural vs. algorithmic scenery: there was some discussion on the X-Plane dev list about procedural terrain; the Outerra screen shots have stirred up interest.

There is a fundamental difference between what you see with Outerra and what we do with our global scenery:

  • Typically procedural scenery is based on the idea of ‘amplifying data’ – that is, making a little bit of data look more interesting by applying a recursive algorithm to “generate” detail.
  • Algorithmic scenery involves taking a large amount of unique input data and translating it; the detail comes from not losing information in the source data.

The key difference is whether the resulting scenery comes from a process that “creates” information through a ‘procedure’ or “translates” information.

Our scenery process does a bit of both, but we are more in the algorithmic camp than procedural camp; the global scenery is produced from hundreds of GB of input data, and we are constantly looking for better input data to create more interesting and accurate output scenery.

In fact, I would say that we are becoming more algorithmic and less procedural. In version 9, the urban roads in non-US cities are “procedural” – an algorithm generates them from the terrain data, an algorithm, and some random noise. For version 10, we are importing OSM.

One thing I have noticed in the work on version 10 global scenery is that we’ve finally crossed a line. With version 9, the question was ‘what is the best data we can get’. With version 9, the question is ‘how much information can we keep’; we’ve reached a point where the resolution of our input data is so much higher than what can go on DVD, that it’s a question of filtering down, not synthesizing up the resolution.

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

9 comments on “Procedural Or Algorithmic

  1. I know this would add a lot of complexity, and in the end might not be worth it, but it never hurts to ask…

    It would be cool to be able to install different detail levels of scenery for different areas. For example, I'd like the highest possible detail for the airports and metro areas I fly regularly (e.g. most of the US west coast). I'd like a moderate level of detail for the rest of the US. And I'd still like to have very basic scenery for the rest of the world.

    As it is now, I have to make the tradeoff of either installing scenery for the whole world and using up massive amounts of disk space for something I'll rarely use, or completely limiting myself to a smaller set of areas I did install scenery for. Multiple detail levels would allow for a bit more of a "happy medium."

    A slightly less complex version of this might be to leave things as they are now (where you select which areas to install scenery for), but have one additional option to use a bit more disk space to install low-res scenery for the rest of the world, or install none at all (as it is now). Basically, changing the default from water to low-res scenery.

    Just an idea.

  2. Well, usually it will be always a mix of procedural and algorithmic approach, but the ratios can also vary with the detail level.

    Speaking specifically of roads, roads in Outerra can be based on OSM data too. You can see that here the procedural part is just about how it generates the fine detail of the surface and road borders, and how it blends with the surrounding terrain using fractal based algorithms. So the procedural technique is dealing with the detail level that you probably won't bother with anyway (or not just anywhere), and in fact a similar approach (augmenting a real data set with procedural detail below its resolution) is or will be used with other data as well.

    Thanks for mentioning!

  3. Perhaps the roads could be more procedural? Like in Outerra?

    For me roads are by far the weakest part of the scenery. They just like a vector line sitting on a bitmap background (when they're not floating!) – not homogeneous at all. To be honest, I leave them off most of the time as I find they break through my suspension of belief threshold.

    The roads in the Outerra engine have nice feathered edges, enough detail to tell whet type of surface it is etc. Very believable (which should be the goal of any simulation of real world scenery?)

    Having said that I don't know if the Outerra data is "real world" or a convincing fantasy land?

  4. IMHO Laminar should seriously consider licensing the Outerra engine for use in XP 11.

    I don't see how its possible for XP to ever compete with the visuals that Outerra will be able to offer.

    Outerra is also OpenGL based!

    XP+Outerra as XP11 would put the upcoming Aerosoft FS in its grave.

    Aerosoft almost licensed it except Mathias didn't like the fact it was OpenGL and not DirectX! Foolish man, he made a big mistake that they will sorely regret.

    If you don't partner with Outerra then somebody else will and make their own flight sim which will leave XP visuals in the dust! Ok XP will always have better FD but 50% of the market will be swayed by pretty visuals IMHO. Those low level shots Outerra details shots are just amazing.

    Please, please consider…

    MatthewS

  5. In the bigger scheme of things, my guess is that ground-level details such as flowers, dirt and poop aren't that important when you spend most of your time 5000+ feet in the air.

    But it certainly wouldn't hurt either *if* such near level details where present … especially around airports.

    -Carrotroot

  6. the level of detail you see on outerra is not that relevant if you are cruising at 38000 ft, but if you are flying a helicopter or a cessna in the "cañon del chicamocha" or in the scotish mountains that would be absolutly amazing, candy eye doenst make the simulation more realistic, but it makes the sim a lot more inmersive, plus is totally diferent to land a helicopter in xp or fs on a monutain that land it in a outerra-like scenery (i guess)

  7. The low level detail is great for bush flyers whilst the superb visibility at high altitudes is great for the jet jockeys.

    XP+Outerra would deliver a knock out punch to any competitor, eg Aerosoft!

  8. As mentioned, the choice is not between one OR the other, it is a choice of the mix between the two.

    My take on it, as a MSFS scenery developer (who intends to look into X-Plane after the release of my latest scenery project for New Zealand) is this:

    Data storage capability and processing power are increasing fairly much in line with Moores Law. The collection and dissemination of highly accurate real world data (I.e. LiDaR derived terrain, high res aerial imagery), however, is not…in fact it is quite slow and expensive when you can get it.
    So we are faced with the problem of having the ability to present highly accurate information to the user, but not actually possessing the data to generate it in many cases. Furthermore, as mentioned, it simply doesn't make sense to try and provide a worlds worth of 1m resolution terrain data if the user is only going to be exposed to it 1% of 1% of their simming time.

    So the answer, in my opinion, is to extend the principle of procedural data adding value to algorithmic data via the use of fractal terrain generation at very small view distances.

    Obviously, people want to fly over 'real' terrain, and algorithmic data can provide that by converting DTMs and land classification data, but different fractals can be tied to different land classes to generate the sub 100m detail. I.e. A landclass file (algorithmic) containing a class and texture of 'rock' (algorithmic) will be linked to a fractal which will start to generate a representative fractal terrain and textures to 'add value' when flying low. A landclass of forest will link to a slightly different fractal representative of under-canopy terrain.

    Given the relatively small overhead (?), I think this would be the logical next step for FS development.

  9. Hi Ben,

    Will we have our own OSM to edit?

    I'm not sure if your aware, but at certain large airports enthusiastic OSM users have included airport ramp roads in OSM.

    How do we avoid default scenery having roads across the airport? and how can we fine tune the way access roads interact with Airport roads?

    Cheers.

Comments are closed.