I have been stingy with pictures of next-gen global scenery for one reason: it’s really hard to get a nice shot of the global scenery that doesn’t show unfinished features. With something like global lighting I can zoom in and show just the new trick, but with global scenery, I can’t take a picture of a new house without showing a city block that looks funky due to a bug and a road that isn’t finished. Posting a working shot of the global scenery where some sub-systems have bugs and artifacts would just freak everyone out.
I figure if it’s obvious that the shot isn’t a production shot, I can get away with posting it though.
A lot of the times when I work on the rendering engine, it is with test textures like this. Our art team does their best to hide the seams between different art assets, so that the scenery looks like one continuous world. The problem for me is that the better they do, the harder it is for me to tell if the underlying shaders are doing what they should do.
So alpilotx sent this test: it’s all of the Innsbruck area painted with a test texture. What’s new and interesting here is that the flat, hill, and cliff areas are all shaded by a single shader that selects between multiple textures (and rotates the textures) based on the underlying mesh.
We are adding the cliff shader to version 10 for a few reasons:
- Often we can get better cliff and hill definition by processing in the shader than by painting different triangles with different textures; our ability to control the transitions using different .ter files is limited.
- Using one slope-sensitive shader saves over-draw and triangle count, which makes the DSFs faster and smaller.
- Some day we may have the GPU distorting mountains on the fly to make them more mountainous. If we do, we need the GPU to also apply the correct textures; if the cliff areas are precomputed then they won’t respond to GPU distortion.
And I immediately thought … hmm, I have seen that picture before. And still, we didn't show some of our really funky test cases 🙂
That's pretty cool – really lets us see how the shader works…
…it even makes sense to colour blind folks!
Wow… I had to read that a number of times slowly to get the picture. Be nice to see that same shot with an 'art asset' texture one day. I get the theory; I'm amazed at the ingenuity of it all; I just can't picture how it works seamlessly. Actually, I don't think I want to know now.
good idea to keep things "procedural". will you have a hight value that adds to the angle value for further variations based on altitude? and maybe a landclass value that allows art-sets for things like deserts? the hint for procedural gpu displacement in the future should calm down all the outerra/xplane fans abit 🙂
We'll see what happens with procedural displacement..I've done some tests using geometry shaders a while back and the performance is unusable. Real tessellation hardware should be a lot better, but those experiments will have to wait until I have more time for R&D;.
krz: well, just height would be too simple. We are using a gigantic rule set, that does decide what goes where. Its main "input" parameters are things like:
– landuse (quite detailed data, especially for Europe and USA)
– detailed climate data (average precipitation/temperature)
– inclination of the terrain
– and some more "derived" terrain structur infos ("relative elevation", "elevation range").
will x-plane 10 look like this?
scnr 😛
Yeah, this is the new "Tron" look for X-Plane 😉
Just some considerations from a FSX scenery developer 🙂
Automatic slope remapping like this (FSX does similar) is useful for breaking up inaccurate/low res landclass definitions, but it can be a PITA for more detailed data (at least it is in the FSX implementation).
In FSX, the slope threshold is tied to the landclass which meant for my VectorLandClass project, finding suitable landclasses/textures became even more tricky- Some landclasses had great textures/seasonal variation but were somewhat ruined by a slope remap threshold that was too low (i.e. it remaps to bush on moderate slopes, to rock on steeper slopes but the amounts vary by landclass type). Because my landclass data was very accurate (i.e. I knew exactly where bush and rock were on slopes), the slope remapping got in the way of presenting a more accurate portrayal of reality.
Ideally there should either be some way of turning the automatic slope remapping OFF or to allow definitions of parameters (i.e. slope threshholds, underlying rock types) in a separate file.
Cheers
Well "Admin", that are the big differences between FSX and X-Plane. The approach how one and the other create the final visuals.
FSX is more like a GIS tool. You feed it different RAW data (yes, of course you need to do preparations) and it fianlly merges them together to form the final visual representation. So, a lot of how the raw data is interpreted lies within FSXs domain. The disadvantage is, that some of these "internal interpretatins" you can't control, and it also eats quite some CPU cycles for sure. The advantage is – especially for scenery developers – that you don't have to care too much about data preparation.
X-Plane is completely different. X-Plane is showing you what you have put into the scenery file (DSF). The DSF file format is really close to the final 3D representation of the data (very closeto OpenGL). The big advantage here is, that X-plane doesn't meddle too much with you base mesh. It takes it how you have created it, and then shows it. So, you have complete control over how that mesh should look (and as a nice side effect, X-Plane doesn't need to spend much CPU cycles here – you have done that at creation time already … and you can spend lot of it at that time). The big disadvantage – for developers – is, that of course you need some quite sophisticated program which translates the different RAW GIS sources to the internal DSF representation. But you also have lots – all – of the control over the mesh you need.
And this is how we build – internally – the Global Scenery. A quite big piece of program, that can eat a lot of different raw data sources, can use rule tables (which we specify/fine tune) and finally spit out the DSF.
So, of course we use a lot of different rules which look at slope angles etc … BUT be aware, that what you seen in this screenshot is only a little part of that system. This "cliff" shading is one of the few "effects" which changes the texturing at runtime (most of it is decided at scenery creation time … this is kind of an override if this helps to understand). But you completely control it! You assign to a bunch of triangles a so called "terrain definition" (well, our tool does that) depending on rules or what ever. And in this "terrain definition" you can place extra rules for the shader (which is working at the runtime of the sim) which might kick in at some slope … or not, if you don't need it (then you just leave that out of the "terrain definition").
So yes, the X-plane scenery system is quite different from what you might be used to …. with its own advantages and disadvantages. But I think it is definitely far more flexible (as in the end you have maximum control over your mesh). And because it is pre-computed, you can do much more time consuming GIS tricks, than a sim can do which need to do this at runtime.
I figured alpilotx might jump on that one.
A key difference between FSX and X-Plane is that in X-plane you can't provide land class without also providing elevation, because the base mesh come as one big package.
Alpilotx: if there is a tkae-away thought here it might be that we should provide a second set of .ter definitions with the cliff directives removed. This set of library files would make the base land class texture set available with cliffs turned off, so that authors could control land class entirely ahead of time.
The disadvantage of this is, of course, that the cliff shader does a better job of putting cliff on the right pixels than changing land class, which is a per vertex (not per pixel) operation.
Cool- Thanks for the explanation (and apologies for the slightly misleading posting name- I'm using my VLC google login which has me name as 'Admin')
Good to see that this has all be thought through- Global scenery rendering certainly is full of pitfalls and it is interesting to compare the different approaches to the same problem!
I'm intending to look more into X-plane scenery development once XP10 is out 🙂
Has the plugin system changed? Will XP9 plugins work in XP10?
v9 plugins will work fine with v10.