EXPERIMENTAL USE ONLY!!! -- [What?] -- Login to add public annotations [How? >>YouTube].

I have been working on visibility and fog-related bugs in X-Plane 10.30; two fixes will improve high-altitude long-visibility viewing:

  • 10.25 has a bug where the fog color changes abruptly at the cut between DSF and planet rendering, particularly when atmospheric scattering is on.  This is fixed in 10.30
  • The 64-bit version of X-Plane 10.30 will load 12 DSFs instead of 6, for longer-range drawing of detailed DSF terrain.

These comparison shots show 35k above KSEA looking at Mount Rainier with max visibility.  (Note that at 35k feet, it doesn’t make a huge difference what ground visibility you pick – the planet-wide upper atmosphere model is almost entirely in control.)

These pictures are taken at “very high res” – the most my Mac Pro can survive with an old GPU; you might get a little bit better definition on “extreme” res.

More DSFs

A few notes on loading more DSFs:

  • My current plan is that the 64-bit version will always load the 4×3 DSF box – if we have to make this a setting for compatibility we will, but I think it’s preferable to not add more rendering settings.
  • The 32-bit build will stay with a lower DSF count for memory reasons; generally speaking, I don’t think we will have any additional visibility improvements in the 32-bit build since we are almost always going to hit a memory wall.  If you have a 32-bit OS, consider upgrading to 64-bits!  (In particular, if you are running Windows XP, please upgrade to Windows 7 or 8 64-bit – there are no more service packs for Windows XP, so you’re just asking to get malware!)
  • In 10.30 the DSF loader can load up to 4 DSfs at a time (for 4×3) or 2 at a time (for 3×2).  So if you have a multi-core machine, the load time should be better even though there are more DSFs being loaded, thanks to multi-core.  (The limiting factor here is that adjacent DSFs can’t be loaded at the same time because their edges need to be matched.)

I am still hoping to address other low-visibility fog issues, but that code is not complete yet.

The Planet Could Look Better

X-Plane renders nearby terrain using DSFs, but it renders the very far terrain and entire planet using a single “planet” model, which is a textured sphere displaced by a normal/height map.  As of X-Plane 10.25 (and 10.30) we are not including as much detail in the 3-d planet mesh as the data on disk contains.

This pair of pictures is 45k above LOWI; the second texture has the mesh spacing on the planet artificially increased from 3 km to 2 km.  (The data on disk is at 1 km spacing, but my machine can’t cope with that.)

You can see we pick up a little bit of definition in the far mountains.  In the long term, I think we could ship a 500 meter planet mesh, which would make the far view in X-Plane as good as the close view used to be in X-Plane 7.

I’m not sure when we’ll ship a higher density far-planet, but I think it will have to be post-10.30.

If 1 km or 500m seems like bad resolution, do consider how far away the planet mesh is. With a 4×3 DSF box, the planet starts 100 km from the viewer.  At 90 degrees FOV (an extreme case, but it makes the math easier) the screen is 200 km across at the DSF cut-over.  With a 2 km planet grid, that means we will show 100 planet vertices left-to-right. At 1080p the planet triangles are thus at 20 pixel increments – not bad for a low res mesh.

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.

42 comments on “Better Long-Range Visiblity in X-Plane 10.30”

  2. Great change. Just a quick question, how will this effect users of photoscenery, especially the higher resolution tiles? I can see loading 12 tiles instead of 6 would kill memory very quickly. Will X-Plane respect the available memory and downgrade?

    1. The limiting factor on photo scenery is VRAM.

      If the photo scenery uses “load center” directives (which it should for best performance) then adding more DSFs far from the airplane has very low cost.

      If the photo scenery does not use “load center” then it is likely to exhaust VRAM even with 3×2 tiles.

      Since this is 64-bit only, memory itself should not be a factor.

      1. I’m also worried about memory.

        Currently I have 8 GB RAM (and I _think_ I can upgrade it to 16 GB) and 2 GB in my graphics adapter (which I can’t upgrade). At the moment this is enough to use “extreme” or “very high” resolution in non-HDR mode under nearly all circumstances.

        Will the new (good looking! 🙂 ) way you load the sceneries force me to upgrade my RAM or to turn down texture resolution? If so, I’d prefer an option to have the old way.

      2. When I load up photoscenery with the current build of x-plane I am sometimes using 6gb of VRAM which is my chard limit(GTX Titan).

        I there some way to ensure that the photo scenery uses the :load center” directive. I created my own photoscenery with G2XPL.

        Thanks

          2. Great!

            In that case (1) I don’t know what’s going on with the scenery and (2) the cost in VRAM of more DSFs should be quite tame, because all of the textures in the 6 new DSFs will be at the lowest possible resolution paging, due to their far distance from the user.

  3. When the news comes it comes with great content as always, keep up your great work.
    Now for a really stupid question (hope not)
    Not sure if you have followed this thread http://forums.x-pilot.com/topic/6557-flying-with-lua/ or the initial one on avsim.com regarding art controll tweaks, but in my mind it has revolutionized the x-plane up to a point. The atmospheric scattering or releigh scattering brings realism to x-plane and makes more people use HDR which up to now has been to harsh (pardon my critism) in color.

    So up to a point this works like a charm, but over a certain altitude the world turns cyan, horrible too. I know one should not attempt to change art controll settings as it is not default, but from a technical aspect I am keen to understand why this happens and can it be fixed?

    1. I know the post directly above is slightly off topic, but I wanted to indicate Ben, if you haven’t already checked it out, those atmospheric scattering tweaks produce some pretty stunning results.

      I’d seriously considering incorporating something like it as a default (once tweaked for realism) as an (relatively, i know any feature always causes a cascade of other bugs) easy win – this sounds like of lame, but I gasped when I saw those screen shots

      1. Yes – that’s why I contacted Pascal. 🙂 I coded atmospheric scattering -specifically- so this kind of thing would be possible, so it’s great to see people using the shaders to their full potential.

    2. The short answer is: I don’t know why the effect turns cyan, but there is no guarantee that it won’t. The shader is a mathematical formula, with some of the constant valuables controlled by art controls – there is no guarantee that you won’t get nutty colors by putting random art values in. 🙂

      The longer answer is: the actual optical physics of atmospheric scattering are insanely complicated and beyond what can be simulated in real-time; X-Plane’s atmospheric scattering is one of many approximations, the first of which I am aware is O’Neil’s work: http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter16.html

      Since the equations are vast simplifications of the real-world math, some of the possible constants for atmospheric scattering produce unrealistic results. I may be able to come up with a better approximation to handle these cases, but the true scattering equations are beyond real-time by a huge amount (since the actual atmosphere can have millions of scattering events per photon you see).

      1. maybe turning back to opengl 4.3 I had some big issues with the open gl driver 4.4 with my 780 gtx. now I turn back no problems anymore and no crazy fps slow downs anymore

  4. One of the things I’ve noticed is that only a small portion of the 2×3 tiles loaded can actually be seen up to a limit of 25miles from the given viewpoint.

    With the 4×3 tiles loaded, will we be able to the whole area of the 4×3 tiles loaded (visibility permitting), or just a small portion (e.g. upto 50miles from the given viewpoint)?

    1. The limit of viewing is set up so that in the worst case before tile scrolling you won’t run out of DSF. In a 3×2 we have to wait until we are within 50 km of the border to scroll, so our max DSF vis is about 50 km.

      With the new DSFs we can scroll at 100 km because we have a bigger box. So the DSF limit will be higher.

  5. Kewl ! Looking fwd to the betas !

    Rumor- is there a new GPS in the works ? 10.30 maybe ?

    Regards…..

  8. great!!!!! i do like heavy metal and visibility was one of my biggest complain since you do spend lot of time at high altitudes. can we also expect visibility/fog issues being improved on both cristal clear days as well on weather?

    hopefully we get 10.30 soon to start testing. great news!

  9. This is a very welcome improvement and was one of my major complaints.

    My impression is that if you reduce visibility range the fog starts rather abrupt which doesn’t seem realistic. Visbility should be reduced more gradually. Is this one of the things you mean by “I am still hoping to address other low-visibility fog issues, but that code is not complete yet.”?

      1. Does this include fixing the abrupt visibilty change when entering a cloud layer? or just the the fog?

        1. No – this post is ONLY about -long range- visibility. Short-vis fog is a separate area, and cloud white-out is a separate area. We have been working on clouds – I’ll write that up in a separate post.

  10. This is great! Keep up with the good work.
    Now, it’s time for X-Plane to get some major improvements on the volumetric fog 😉

    1. First, great news (though I fly in low altitudes)

      I also think that the low cloud fog or haze should be also on the 10.30 plate (I hope), It will greatly improve low flights and immersion. Currently having the big wall of fog does not cut it for me.

      Keep up the good work.

  11. Pingback: X-Plane 10.30 in aantocht - simFlight.NL

  13. Another how will this affect question: How might this affect users of Andras’ high definition tiles besides the obvious extra load time they incur? Seems like there’d be a good dollup of frame-rate hit.

    1. We’ll have to try it and find out! But I am not super-paranoid, because the far tiles don’t have any autogen or 3-d on them; when you look at X-Plane’s vertex budget, the vast majority is consumed by 3-d, not the mesh itself.

      (The worst case here is we make the setting optional I think.)

      For that matter, I think we don’t draw the terrain transition overlay triangles at very far distances* – once you get far enough from the camera, you can barely see them. If that is the case, even some of the mesh is gone for those very-far DSFs, further lightening the load of far DSFs.

      * I don’t know the exact status of this optimization – it gets turned up and down as we tune things; it was a very important optimization for the original iphone.

  14. Great news, Ben. Thanks. This was something we discussed many moons ago. Sounds like we’re getting beyond the current… “design limitation.” 🙂 Very happy camper here. When the world outside the window feels more real, then what’s happening in the cockpit does too. Looking forward to the beta! (Are we there yet? Are we there yet?) 😀

  16. Those 64-bit long views are a great advancement. Looking forward to the Clouds post too, as they have enormous impact on frame rate.

  18. Ben,
    Just to echo Tom Knudsen’s earlier comment about the Rayleigh Scattering effects; I know you, like many of us, have been following with interest the very positive effects of these “art tweaks” on the long range and high altitude views – even to the extent of making an offer to some of those authoring those tweaks to contribute to the XP code. Is there a chance that any of that has developed into something that might be incorporated into a future build?
    In all this is now looking very good. Many thanks, Andy

    1. I think there is a good chance – I contacted Pascal about this; I owe him a special build with some of the fog shader bugs fixed. I’m hoping to get him that build real soon.

Comments are closed.