‘Alpilotx’ or Andras Fabian as he is sometimes known, was a bit of an enigma for the last few years, we had heard of him (mainly for his V8 trees project), knew he was behind xplane’s ‘terrain’ (whatever that meant), but knew precious else about him. The well known ‘front of house’ names, like Ben Supnik, Austin and Tom Kyler (we know him through our street-chats at X-Pilot) have all had a fairly high profile (hehe, Ben for good or bad – no, it’s not that bad!), but Mr X-Terrain as I now dub him, is very much a dark-horse. As I expected, the story is much deeper and more in-depth than you would EVER imagine. Let’s just say that Laminar are VERY lucky to have such a smart and enthusiastic guy on their team.

Today’s interview resulted in some massive, intricate replies from Andras, he certainly can type! Amazing considering he’s German, and also taking into account the complexity of the topics he is discussing and is able to clearly explain. Don’t be scared of the size of this post, it’s fascinating and well worth a relaxing read with a cuppa and a few dozen donuts/pretzels.

For those who can’t be bothered reading all this – fine, I’ll summarise it. Andras works closely with Ben by bringing together the many, disparate sources of land-use, terrain and climate data from around the globe, converting it into a standard format for Ben’s fabled ‘Renderfarm’ that creates the base scenery you all take for granted.

X-Plane’s way of doing all this relies on its ‘library’ which enables fantastic flexibility to create many different regions for varied/specific terrain and object placement within a single 1 by 1 degree DSF tile, doing this across the globe.

After reading this, and seeing the numerous complaints from users in Avsim (where else?) about whole cities not being ‘plausible’, I personally see we have a long yet exciting road ahead for xplane. The structures and tools that Andras discusses below, mean that  in time, we should see whole new regions and cities emerge with custom made objects and even newer, better terrain. The guys at Laminar have created an efficiently adjustable world, that once a few talented artists (me included, though I’ve got more persistence than talent!) get to grips with the processes and structures, will rapidly gain in beauty and variety.  It’s for this reason I will come out already and say that Xplane 10 could be with us for quite a long time – say 4 yrs minimum! We may not recognise the world in 4 years time – a bit like real life eh.

I am already looking forward to creating custom Australian homes for our region, that don’t need positioning, Xplane just knows where to put  them and in what ratio. Same with trees.

As I said before, there are many complaints about the look of cities, e.g. New York. Andras has hinted at Laminar looking to use more of the Openstreetmap data, my hope is that they’ll be able to use the building mapping of OSM to get more accuracy. There are are art assets for houses and buildings. All we need is a large library of varied skyscrapers and these could be sized and applied automatically by Xplane. Only my conjecture though. If it’s not possible, then even yours truly might start a massive project to model all the Melbourne buildings! Well, most at least, with the odd filler or hundred..

The X-Terrain Lecture by Andras:

The DSF scenery is a quite interesting data structure, which was – in its basic form (but most of that didn’t change) – designed around the switch from XP7 to XP8 (and no, I wasn’t part of the team at that time). It is a layered data structure, where you can put in different data layers, and then the sim will take care of it. Each of this layer takes care of one aspect, like for example the base mesh, road networks, forest polygons, object positions etc.

One very, very important concept of the entire scenery system – and if you understand this, you can understand a lot of things – is the decoupling of the scenery from the final artwork (kind of an abstraction) What does this mean? It means, that the scenery file itself knows nothing (well, almost nothing) about the way it will be represented in the end. It only holds the geometric structure/information of base mesh triangles, of road line vectors, of forest polygon forms, or the position of objects etc.. AND it attaches only a name (think of a pointer) to each of these geometric entities. Now comes the abstraction. Each of these names/pointers points  to an artwork definition. Essentially a file in the file system, that then describes how the artwork should look (depending of the type, it can have a lot of different attributes, which greatly influence the final rendering) and what artwork it should use (so, this definition file points to the textures, the 3D objects etc.). A very simple example for these definitions would be the forest defs (those were the first I learned to use – and where I understood this whole abstraction scheme). You can find a lot of FOR files in the Resources folder (deeply buried in the xplane directory), and to each forest polygon (the forest geometry) one of these FORs is attached. So, in the end the scenery only gives the form of the forest, but the FOR describes which tree textures to use, with what random distribution patterns etc. etc.

To make things a tiny bit more complicated (but also vastly more versatile), I have to add one point from the previous part (in the first place I wanted to make it simpler). The names in the DSF (the pointers), don’t even directly reference the artwork description files. But they use a second indirection through the library system (all those fancy library.txt files you find everywhere). This library file accomplishes the mapping of the names (the pointers) to the real definition files. In the first place this might seem redundant (or nonsensical), but it becomes very interesting, if you see the extra features of the library system. For example, assigning different artwork definitions depending on some conditions. Like for example regionalization, which allows to use different artwork definitions for the same “name” (the pointer) in different geographic regions (yes, it can vary this on a per 1×1 degree DSF tile basis). So, for example if a forest polygon references conifer_hot_wet (in the scenery file), you can assign a different artwork description (and thus different artwork!!!) to it depending on the region where it shows up (and the library system knows many more tricks) … so the conifer_hot_wet in the scenery can look differently inJapanorSouth America.

And this same concept works for all artwork, for the mesh texturing, for buildings, roads … everything, yes even autogen (namely, there is a quite flexible way to replace definitions, and thus how the artwork should look!).

Edit – an additional note supplied by Andras to help clarify – “Climate regions do not depend on the library! They are already hard coded in the scenery, because its such an important fundamental feature. Essentially we have two ways to regionalize. Either in DSF or via library. In DSF is pre-production and hard coded (kind of). Its advantage is, that we can make its borders accurate down to the triangles So transitions are more organic. Library regionalization is post-production. With it, you can change any re map any artwork definition as you like AND can (but not necessarily need) do this differently fir different geographic regions. It’s very flexible BUT has only an accuracy of 1×1 degree (per one DSF tile). We only used it – that was Albert’s last minute idea – to make some more localized textures for NW America.

Back to the lecture -

Now that this is cleared up, let’s go a bit more to the parts of the global scenery I am working on. Because, I am “only” (well, it’s more than enough) responsible for the base mesh (how it looks, how it links to the artwork etc.), the forests (an old heritage) and closely working with my texture artist (telling him how everything works, why things turn out in the scenery as they do, how he can achieve specific effects with artwork files etc. etc.). So, the roads and the cities are not so much my part (I know the basics, but not all the gory details).

The global base mesh

It’s a very interesting beast, and a bit different than MSFS (at least to my knowledge!). First, and most important is, that the X-Plane base mesh is not a regular mesh (the triangles are not equally sized), but an irregular mesh (triangles can have arbitrary sizes depending on the detail needed for some geographic features – controlled by our internal algorithms). It’s also different – from MSFS (again as far as I know) – in that it is not calculated on the fly out of simpler (raster) raw data, but it is completely pre-computed (so the DSF scenery files hold the final triangle structure). Also, the mesh is not one, big contiguous triangle mesh (even if it looks like that in the sim … and it should!), but rather a gigantic patchwork of a lot of smaller triangle-patches (each patch can consist of many triangles – usually not single triangles) which do overlap (the overlapping – the overdraw – allows us to have the soft transitions between different terrain types … the textures in the end). And finally – everybody remember my first paragraphs – each of those triangle patches represents one type of terrain (very simply spoken, a forest, a meadow, a crop field etc.) and has a terrain definition name assigned to it (here we have it again, that “pointer” to the artwork world!). So, this last link is maybe the important one for all of you … as we again have the complete library system and the artwork definitions it points to (terrain definitions in this case, or simply TER files) to give us a lot of flexibility to define the looks of the scenery!

So, the base mesh of the scenery is a simple (but often very big) collection of triangle patches, with lots of names assigned to them. Those names (the “pointers” to the artwork, we remember) usually are descriptive, as they describe – in short – what kind of artwork is intended (Intended! Not necessarily implemented in that way!) to be used for them. It usually tells the land use type, something about slope of the terrain and the climate it is in geographically. But how do we get to this point to have this base mesh scenery (and of course all the other stuff I didn’t even start talking of)?

Well, it might seem like black art, but its “just” a lot of algorithms, and a lot of data management going on. It all starts with the raw data. Yes, raw data and a lot of it. Because, as you might have guessed, we definitely don’t do all that mesh building by hand  (usually we do almost nothing by hand). For that, our little blue planet is far too big! So, we need raw data, and usually it is raw data from the GIS (geographic information system) realm, mostly from different remote sensing projects. To just name a few, here is a short laundry list.

Land use data comes from different sources, like the CORIN data at 100m resolution for Europe (from the EEA), NLCD data at 100m resolution for USA/Alaska/Hawaii (from the MRLC), LCDB data at 100m resolution for New Zealand (from Ministry of the Environment), and the GlobCOVER data at 300m resolution for the rest of the planet (from the ESA). Then we have the elevation data from many different sources, like the CGIAR SRTM (an improved version of the original SRTM data), lots of elevation tiles from the fantastic Viewfinderpanoramas project for all the northern (above 60 degree areas), the CDED data for Canada, and some NED data for Alaska (and maybe I have forgot one or two others!). Plus – this still goes to the basic mesh – we also factor in climate data from the WorldCLIM project (we “only” use the annual mean temperature and precipitation information). … (and then I don’t even detail the OpenStreet map data, which was prepared by Ben and is used by the road / city “department” )

So, you can see. A lot of raw data (it fills up hundreds of gigabytes on my disks). Which also means a lot of pre-processing, because, they are all different in some ways, have some little faults here, some little specialties there and they need to be brought to a common format with common attributes. Especially with the land use it was quite some fiddling, to bring the different sources together, map the different land interpretations (classification) to one system so we can use it easily in our algorithmic scenery creation process. And the same holds true for merging the different elevation data sources (different formats, projections, resolutions … you name it). All in all, many months of scripting, and many months of CPU hours on my machine. And for those who are interested, most of the processing of the data was done with GRASS GIS and GDAL tools (all open source geodata processing software) plus some of our internal tools.

Then, finally we have the raw data prepared in some nice, easy to use format, all cleaned up, all consistent attributes. Nice! But then – you still keep asking, I hear it – how is it turned to into scenery? Now comes some nice magic. Let me introduce you RenderFarm (the name might be misleading – but that’s how it called), a fantastic piece of software coded – mostly (but not entirely) – by Ben Supnik (yes, the guy is not just coding X-Plane … so you see, he for sure is never bored (as I always nag him, when RF has bugs … or need new features). Put very simply, it takes all the raw data (a lot of them … not only the ones I need but also the OSM data etc.), takes a gigantic rule set (this is very important!) and finally, after some time – if all goes well – it spits out the final DSF tiles (the scenery I partly described above), which X-plane can (could) use then. And it also can do a lot of other fancy tricks (its like a Swiss Army knife), for example create the artwork definitions files (our TER files – you remember from above?) from our big rule tables (because we don’t hack those definitions one by one – would take too long, and would be too error prone).

But heck, what are those rules files? They are the key, to transform the raw data to scenery. When the RenderFarm begins to create the terrain mesh, it needs this information, to know, where, what terrain types to assign (remember, only the names, those “pointers”) to triangle patches. So, those rule files – kind of big config sheet, we even work on them using OpenOffice Calc – define a big set of conditions. RenderFarm looks for each triangle at all the raw data, and depending on a lot of conditions decides the final terrain type to assign. The nost important conditions (there are more – but they are really fancy) are the sloping of the terrain, the mean annual temperature and precipitation (decides the climate), and of course the landuse. So, RenderFarm checks this for each triangle (well, triangle patch), goes through our rules and as soon as a condition hits, it assigns the terrain type (so we need to create the conditions in a way, that RenderFarm always finds some kind of hit … or it gives an error, or “purple” landscape … This was not always easy.  Quite “easy” isn’t it ? And this big rule set for the terrain alone consists of many thousands of rules (in a structured way of course, otherwise we couldn’t handle it) … so, yes, I needed to fiddle with that a lot in the last more than two years.

And so finally it happens. RenderFarm does its magic (remember, far more than I described here – it also creates the forests, fits in the roads/railroads, cuts coastlines and rivers, places the zoning for the city autogen etc. etc. ) and we get our DSF tiles.

At this point we still can’t use those DSFs. We are missing the artwork. So, this is the point where all our artists step in and create the artwork definition files (the ones, the scenery point to trough the library system – you still remember?) and all the real artwork (textures, 3D objects and so on), which they can use in the definitions. For the base mesh of the global scenery, we for example use another rule table in very close coordination with the first one. This second table does not define the conditions for what terrains to assign, but holds – in a structured, easy to use, tabular way – all the information for our artwork definitions, the TER files. This is also the rule table, which I do work on far less … this is much more often worked on by my texture artist Albert Laubi. Because, he knows how he wants his textures to be deployed. What scaling to use, how to blend them (at the borders between different terrain types), or what shaders to use Oh yes, we have a lot of tricky shaders (this tech is in X-Plane, which takes effect at the time the scenery gets rendered) … like the directional shaders, which rotates textures depending of the slope heading. Or the cool cliff shaders, which  can change the texturing of a tile completely, if it is applied to a really steep surface (of course, as the name suggests, it usually paints the cliffs!) …

AND then, when all is done, the DSFs are in place, the TERs (terrain definitions – the artwork link, you remember) are generated and the textures are in their folders (and yes, of course, all the other artwork for the forests, roads etc. etc. – whatever our DSF references and needs) we can start up X-Plane and hope, it renders what we intended to see in the first place. And if there are visual bugs, then we have to go through a quite long chain of possible errors to find it (maybe X-plane renders it incorrectly, maybe the texture is corrupted, maybe there is a mistake in the terrain definitions, maybe the rule system put in wrong terrain types at the wrong places , or maybe the raw data is flawed … endless hell of  possibilities )

So, if you look at the scenery creation process from a fair distance, it seems quite straight forward (and it really is ) … but all the gory details make it quite a “funny” process, and one, that takes a lot of time.

At the end of this short scenery lecture, I would also highlight one more, and very important feature of RenderFarm, namely its RenderFarmUI cousin. As the name already says, its a UI version of our “little” tool. It allows us to visualize a lot of the things RenderFarm does with our data, and especially see the resulting DSFs structure visually. This is very very helpful when we are debugging our scenery. For example, we can click on each triangle, see the input raw data variables, and see what kind of terrain was finally assigned to it depending on the rule sheet described above (so, I see the name of the terrain, then i know which terrain definition belongs to it, and in that terrain definition I can look up the artwork used). To save going into more, lengthy descriptions of RenderFarmUI, I will just show you a few screenshots, which give a better feeling of what it really can do and show (the more knowledgeable ones out there will immediately recognize it as kind of a GIS data viewer – which it really is … kind of

And no, I am not telling you big internal secrets of Laminar. Because – and I doubt many of you knew this – all the scenery tools are open source!!! Yes, indeed, there is even a CVS repository, where you can download all the sourcecode (though, it might be another question, if you can get it to run ). And not only the source of RenderFarm, but also that of WED etc. (which might be more helpful for some out there – and I think there are already a few who downloaded that code). The details, how to get the code, you can ask from Ben (and yes, it runs on Linux … thats the only platform I used all the time while creating the new scenery!) OK, enough lecturing. Now, after you have learned so much about the scenery…..

on to the questions of Simon and Chip

XP10Blog: Creating a global mesh and textures Is a massive job, and it can be hard to keep the locals happy. How have you approached this massive task?

Yes, indeed this is quite a big task, and you also learn a lot about your own planet as you check out different locations and are surprised what fancy features are there in reality). And of course, we try to differentiate the scenery a little bit, so that it can better represent the local landscape. The most important technique we use here is, to make the terrain types climate sensitive. This means, that we use the annual mean temperature and precipitation data (real data), standardize it, and create kind of climate zones (we have up to 28 of them). So, depending on some temperature ranges and precipitation ranges (we found out by lot of experiments) we differentiate the same terrain type. So, a coniferous forest terrain can have a “temperate wet” version, and a “hot dry”,or “cold semi dry” variant, and so on. That’s why you see in the terrain definitions so many, almost identical, but slightly different terrain types, like coni_tmp_wet, coni_hot_dry, coni_cld_sdry etc. etc. (and yes, there are even more postfixes in the name, which usually hint at what kind of slope its used). So, by having these different variants of each terrain type, we can assign different artwork, and thus, different textures to terrain in different climate zones. This helps, to make them fit their region at least little bit better

And then we also would have the regionalization trick (I hinted at this when I talked about the library system in my “lecture”). There we can map (via library.txt) different variants of the terrain definitions to the same terrain name (the pointer in the scenery), depending on a global region (the accuracy of the region definition can be 1×1 degree here – the size of a single DSF tile). So, we could assign different terrain definitions to – for example - our “coni_tmp_wet” in Japan and South America.

This regionalization trick will – I think – come in quite handy for 3rd party developers (or the community), when they start to bring in some regionalized modifications. Because it does not only work with the terrain (the texturing of the ground), but ALL art assets. So, this way, you can even change cities depending on their geographic region.

XP10Blog: how will any corrections to terrain be updated? So will we be seeing larger size updates?

Thats hard to tell. We have quite some ideas floating around internally, but because of other priorities (ironing out the first big issues, improve performance, improve artwork) we don’t have finalized plans. So, you will need to wait and see what we come up with for updating scenery tiles (the DSFs)  But everything else (not just the X-Plane 10 binary, but ALL the artwork), can and will be updated trough the well known update mechanism!

XP10Blog: how do you balance the need for high Rez textures with pc performance and storage space? Can you outline the tests you might have done to help decide?

Well, the storage space is not sooo extreme. We are not delivering photo scenery, but special, derived textures (kind of “plausible” textures) which are a generalized representation of a specific terrain type. And by mixing them – you read above, how the scenery is created, and terrain types assigned to triangles – we create a believable world. You can think about it as a very “lossy compression” of the real world. Instead of using real photo textures, we use a few look-alikes, which then mixed and represented in the right way, give a feeling of “plausibility” (the feeling of “yes, it could look like that in reality”). So, we have no too big constraints on storage space here (we only have a few hundred textures … and growing ). And neither is the resolution a problem here. We try to rather make them high resolution, and the user can then down scale them via the “texture resolution” setting in the rendering options.

XP10Blog: Describe one of your hectic days and some of your interactions with ben /others. No swearing please!

I usually work nights for Laminar And those can be very different. Sometimes I had weeks, when we had almost no interaction (only few mails here and there). Then, on other days, we exchange 50 mails in a few hours with Ben or Albert (Albert is my texture artist from Switzerland). Of course, the latter would qualify as more hectic days. A nice example would be one of the last days before the scenery data had to be sent to the DVD  burning. Ben has created the complete DSF set for the planet, and only in the final checks we discovered, that there were some very remote locations, which turned up very very strangely (no sane texturing) …. The reason was found quickly. Those few, remote places did not have land use information in our raw data! And I have not prepared rules for RenderFarm (you remember, our scenery tool, which uses a big rule set to transform raw data to scenery), which take care of this rare situation … So, I had to quickly hack up some fall backs, that could handle this, and would assign some usable terrain types to those places (usually tiny islands). Yes, of course, in this case we are going away from plausibility, but can still make it look OK (essentially I applied some very simple heuristics in our rules).

And no, we have no wars internally (at least I don’t have). This is one of the very positive things of my work for Laminar. I can discuss with Ben or Albert very very constructively. Yes, of course we had quite often strange ideas, or different concepts where we needed to discuss. I mean, really discuss. Often for days. But we can always stay on a technical level, where everybody can lay out his thoughts, and we find a solution in the end (even if its one we overthrow just a week after the decision … when we realize, that it was a bad idea). Sometimes I even work as a mediator between Albert and Ben. Albert is really more the Artist guy (and someone who knows a lot about the physical realities of our planet!), and he often can’t immediately understand the tech talk (for example new rendering features) Ben is talking about. Or the other way around, he has a great idea, but can’t easily bring it to a technical description which Ben can then translate to code (or  dismiss, as “won’t work” :-) ). Here (ok, not only here, but with all the scenery work I am involved in) it helps, that during my university time I attended some computer graphics courses (and was always interested in this topic which I tried to keep up with over time).

So, maybe this gives you a feeling about the daily interactions (and of course there is much more, sometimes a skype chat involved, or a remote debugging session etc.)

XP10Blog: There’s a huge amount of complaining in some forums. Tell us how you think the reception has really gone. What are you happy with, or not, and tell us why

Aaah, the forums. Well, they can be a snake pit sometimes Which is not surprising, as they are just a mirror of very normal human nature (everydays madness ). But yes, of course there are times, when I am banging my head on my desk … and also learned to just step back in some cases. I can’t let my emotions go every time I read one of those “special” posts … so, I just let them pass (there are enough other posters who then do the flaming – and I don’t mean, that I support that … it is as it is).

Generally, the reception was more or less as I expected it. A lot of euphoric people (which makes me smile, of course), and of course also quite a few critics. With the latter group, we can differentiate between the constructive critics, the ones who you can argue with, and who give normal feedback. And finally the users, which are just letting their negative feelings out in the forums. Its ok, we live in a free world, with free speech  But I am not entirely surprised by the negative responses. A flight sim has too many facets to make them all perfect. And every user has other priorities, and is – of course – unhappy if his beloved topic doesn’t shine. It’s understandable, and in this sense, X-plane is far from perfect or complete.

XP10Blog: Was all of your approach fully planned, or did you have to change tack at any point, and why?

LOL, of course not. Yes, I had a big idea, when I started with the global scenery development many years ago. And in many ways, I could bring those ideas to fruition. But the way was definitely not linear. I always started out with what was there, but over the time we had lots of new ideas (ben has brought a lot of new rendering techniques to our table) and so we often had to adapt to them. So, it was -and still is – an evolutionary process. There are often dead ends, but the best of breed survives, and helps us to reach new levels

XP10Blog: What are the areas you are most proud of? Least proud of? Any plans to improve?

If you mean the scenery (edit: haha..), well, of course the Alps. I am from Germany and really like mountaineering, skiing. Albert lives inSwitzerland. So what else do Ihave I to tell ? The Alps where the first region which we perfected, and then went outward from there (and many other parts of the planet which have similar characteristic to theAlps do profit from this). But I also have to admit that there are still many places on the planet where we were unable to improve on  details. So, here we still have a lot to do (and can do a lot because of the way the scenery system works – remember my lecture ), and all of these improvements will come to the end users step by step via X-plane Updates!

XP10Blog: We have been very impressed with the variety and undulation of Seattle’s terrain, roughly how is this achieved so well? Describe for non techies your methods

Well, I think, a lot of this was described in my above “lecture” above So the trick is, to bring in a lot of versatility by using the available raw sources. Make a lot of rules, which change not only with the landuse, but also the slope of the terrain etc. This makes the terrain types vary enough, so that in the end we can apply many different textures to them (the higher the diversity, the less boring the scenery is at the end). And on top of this, we have Albert with his very nice textures (he has his own black magic, which not even I know in all details ) and all the fantastic shader tricks Ben has coded for us in X-Plane 10 (my favorites are the one that rotate textures depending on slope heading, and the cliff shader).

XP10Blog: Then how do you approach the challenge of areas with less mesh or texture detail?

Sometimes we fail on this. Yes, indeed there are areas, where we can try our best, but the landscape is so flat, and the land class has so little variations, that you get almost no variations. But even in this cases, there are few tricks, like the swizzled textures (google this, or look in Ben’s blog … he has written about this) or our new composite shader, which combines two different textures through a noise pattern. So, yes, we have invented quite some tools for situations like this, but still there are places to be improved.

XP10Blog: Trees-  tell us about your famous trees addon for V8 /9 (click here) and how that has moved forward. How do you balance detail with load. Any future plans?

Oh, this one is old. The tree project was a very interesting start for me. My motivation at that time was – it was X-plane 8 ! – that Ben wrote somewhere, that X-Plane 8 could draw forests. And I always wanted forests in a flight sim. But they never appeared in the V8 global scenery. I was waiting for months, update after update … but no forests. Add to this, that at that time I was already quite curious about different geographic data sources on the internet. And one day I found the famous CORINE land use data (from EEA, the European Environment Agency) … Then I thought wow, this one needs to be transformed to a forest scenery. And so it began. I learned step by step the internals of the DSF scenery system, how I can create those forest overlay tiles etc. I also needed to learn a lot about GIS data processing (there I started with GRASS GIS), and batch scripting (yes, I always use batch scripts for my projects … its simple, and usually enough for what I do). I even had to do my website to make all of my work public …. and finally the first scenery version has seen the light.

Shortly after my first release, which used some default tree textures, and rather simple forests, Albert contacted me. He offered me to help with tree textures, and to craft the forest definitions (aah, see, here we have it again – from my lecture – the abstraction from forest scenery and artwork), which describe how the forests work. He turned out to be also very knowledgeable in geography, which was a big help in representing real word phenomenon (forests)in a simulator. We even started to divide the forests up by climate zones, so we get them fit their regions much better … And a long friendship with Albert ensued with many new forest scenery releases to follow (for the USA, and then all of it ported to XP9 etc.).

So you see that I gained a lot of the basis of understanding the scenery system, what tools to be used and  what raw data was good at this time. And it also showed me the way to Ben (Edit: “The Way To Ben”, a new cult coming your way!), because with all my forest scenery work, I had more and more communication going on with them. To the point, where I had the idea, that with all the cool data, we could have a much better global scenery … the rest is history .-)

And future plans. To be honest, after all the global scenery work I don’t see much reason, why we would need my forests in XP10 anymore (not to mention, that with many of the new stuff in the X-Plane 10 scenery, it would be almost impossible to reuse my old processes – and new the one might be extremely complicated). Well, the XP10 default forests all come now from the same, high quality data which I previously only used for my V8/V9 forests. But now it’s all there and its even more or less in sync with the ground terrain types. And the XP10 default forests are still in my – and Albert’s – hands. So, we can do any customization (I think, we will definitely tweak them at some point … when Albert is tired doing textures )

XP10 Blog: How has OSM benefited your work? any good examples?

Well, I was one of the first guys inside Laminar who started pushing for the use of OSM (I recognized its potential quite early). Luckily, Ben started to look into this quite early and in XP10 you can see it now natively used the first time in Laminar’s – indeed any flightsim’s -  history But then, in the scenery development process itself, I had not much to do with the OSM part. As I said earlier, I see myself as the “nature” guy, the one responsible for the natural scenery. Others, like Propsman and Ben had much more to do with all the city generation … so of course, for them OSM was very important.

Other than this, I can tell you my general view of OSM. I see it as a fantastic project on the internet (if not one of the most important ones since Wikipedia). They have liberated the geographic data, which before their project was very hard or extremely expensive to come by. And OSM is a treasure chest of unimaginable value. Yes, for X-plane’s future too (we are having quite some ideas to extend the use of OSM in future).

BUT … this had to come … OSM is a snake pit too. Its only problem is, that because of its very free – wiki like – nature, there is quite some chaos in the data sometimes. Not only can the vectors be very strange sometimes, but the tags (the properties which describe each geometric object in OSM) can be very chaotic too. For example water … there are a few glaciers (yes, glaciers), which somehow were labelled as some kind “water” … Now you can imagine, how funny some mountains looked with big, sloped lakes all around (and if you don’t believe me, just search “Mount Shasta” in OSM, look here:

http://www.openstreetmap.org/?lat=41.40932&lon=-122.19501&zoom=15&layers=M)

Or there is also often a very inconsistent way, how people map some stuff (someone maps a river just as a line, while others map the same type of river as polygons etc. etc.). Or the just the very incoherent coverage around the planet (some areas are mapped down to pebbles, others don’t even have the largest highway). So, things like this make it sometimes hard to work with OSM, and you always have to take care of all this problems when you work with it algorithmically (which is the case in a scenery creation process). Ben Supnik needed to swear and curse because of this quite often !

XP10 Blog: the new sim seems to cope very well with huge amts of objects and trees. Does this give you more ideas, like having more complex trees? Clutter?

Yes, ideas we have enough for the rest of the decade. But seriously, there are  already some vague ideas floating around about the trees. The current ones (2D billboards) are OK, but they could be better. A little bit more 3D-ish … so, I wouldn’t be surprised if we would come up with something like that in the next 1-2 years (but I really can’t promise anything here … this is really only ideas ). And what we can expect from the city guys? I think , you need to ask them (I don’t know ).

XP10 Blog: Some scenery textures in 10 are holdovers from 9. Is there a strategy to replace these older textures over time?

Yes, I think I have already answered this above. Indeed we use quite a lot of the old V9 textures, just to have our landscape in a form, which can already be sold. But of course there are still many regions (all the warmer climates), where we would like to invest some work. So, expect improvements there, though, they will not come over night and will take quite some months (or even a year), before most of the old textures are replaced. But the good thing is, that because of the way the scenery system work – see my lecture above – there are not many limitations to achieve these improvements (even 3rd parties can pick up some of this).

XP10 Blog:There have been grumbles about generic scenery elements, like houses, being used globally. For example, US style suburban housing showing up in African villages. What kinds of alternatives are being built into XP10 to increase options in this area, or will third party developers need to tackle this?

Well, again, here my lecture applies. Because of the abstraction between scenery and artwork, we can modify a lot. Usually the scenery only knows, that we have a zone, of type “low residential”. Then it looks up the artwork definition, and starts filling the zone with houses (in some way). Now, because we can assign different artwork definitions (and thus artwork) depending on regions, there are almost endless possibilities to regionalize cities …. There only needs to be people who are willing to create all the artwork (some of this will come from Laminar – and is still worked on – and some of this will come from 3rd parties).

But as cities are not my area of expertise, I recommend to ask this questions from other guys on the team too (Ben and Propsman come to my mind).

XP10 Blog: What do you think about ortho-sceneries, and their future in XP10+

How should I put it. I am definitely not someone who opposes them, but I also have seen to many, badly made photo sceneries. But there is one good example, how to do it best. See the products of FranceVFR (I have never used them myself, but their screenshots / videos always amazed me!). They do a perfect mixture of photo textures (which are well coloured and prepared too), and add enough 3D clutter on top, to make it look fantastic even close up. So yes, if photo scenery then that way please (and I realize, that it is a very resource hungry and time consuming way to achieve)

XP10 Blog: Do you think there will ever be a way to simulate shallow water details globally, in the way we see coral heads in the lagoons of XPFR’s French Polynesia scenery?

Hmmm, yes I think there is something already in the scenery (some bathymetry data), which we will later be able to use for this. Maybe not as “perfect” as in MSFS, but definitely better than what we see now. But you better ask Ben Supnik about this

XP10 Blog: Phew, that was really informative Andras, with plenty of ideas for the future. Keep in touch and best of luck for the following years!

Andras also sent us a note about his pretty amazing Flickr photo collection, that reveals his photography talents and the amazing areas he visits nearby. Almost dreamlike some of these landscapes:

‘I have a quite extensive photo collection on Flickr, which might give a good impression about my “relationship” with the mountains (especially the Alps). And also shows, that I have a good idea how real landscapes look .

Here is the link:
Http://www.flickr.com/photos/weathermaker/sets/
And another sidenote: Albert used some of my photographs for his textures

Oh, and if you’ve made it to the end of this interview, congrats and thanks for reading! Below are some examples of Andras and Albert’s work, showing how all this effort can produce very nice, high-resolution terrain that is well integrated with the perfectly placed trees, and also showing off how a flat, ‘featureless’ landscape can still be made interesting (actually it’s still a beautiful place, just no buildings, which can be nice..)