Developer Blooper Reel: Water World

Now that we have announced X-Plane 11, I can finally post goofy screenshots and videos from v11 development. Sometimes a bug makes delightfully goofy results, and Austin liked this one so much he wanted me to share it.

I am working on 3-d water for X-Plane 11 – we have a working prototype, but I am not sure if this will make the shipping 11.0 product; it still has a lot of bugs and rough edges.

Traditionally in X-Plane if you don’t have terrain installed, you just get water. This isn’t really an intentional design decision; we just defined “no DSF” as “all water” so that we could avoid shipping DSFs for the huge chunk of the Earth’s surface that is covered with ocean.

But we always have airport data, so in X-Plane you would get an airport floating in the middle of the water! While this was completely goofy and is a huge source of tech support calls (which is why X-Plane 10.50 now offers to install scenery whenever you hit this case) you could, if you really wanted to, land at this water-world airport.

Until now. Now that the water is 3-d, the peaks of the waves actually cover the 3-d buildings and make the entire airport as usable as…well, as it really would be if built in the middle of the ocean.

(This is about the point in the post where I would insert a snarky climate change comment, but I’ll let XKCD do the talking.)

Scenery developers might wonder: why is it that when the water level falls the runway lights and signs are revealed – but where is the pavement? The answer is in the comments.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn

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.
This entry was posted in Blooper Reel, Development. Bookmark the permalink.

47 Responses to Developer Blooper Reel: Water World

  1. Ben Supnik says:

    Here’s why the runway itself is gone – the runways are draped meshes, and thus they are polygon-offset. For polygon offset meshes to be seen, you have to do two things:

    1. Make sure that a non-polygon offset mesh with the -same- location is drawn -before- the polygon-offset mesh..
    2. Make sure that any 3-d meshes that intersect the polygon-offset meshes are drawn after the polygon offset meshes.

    When the water was 2-d, the water met requirement 1. Now that the water is 3-d, it meets requirement 2, but without terrain, nothing meets requirement 1. Without the underlying non-polygon offset mesh, the draped runways disappear.

    If there’s a moral to the story it is: if you don’t get the requirements for polygon offset perfect, weird stuff happens. The easiest way to ensure that things work is to use ATTR_draped in your object and make sure the layer group is greater than terrain and less than objects (or don’t customize the layer group).

    • Steve.Wilson says:

      Really interesting effect. Might be a “blooper,” but it’s a very realistic looking blooper. The effects of Global Warming, as demonstrated in the future thinking X-Plane 11! Has water always had enough polygons to potentially work this way, Ben, or did you have to subdivide the non-terrain areas a bit more?

      • Ben Supnik says:

        The polygons are being subdivided on the fly using tessellation hardware. The effect still suffers from “swimming”, as the mesh isn’t detailed enough (and thus has sampling error as the camera moves); I’m looking at forcing water subdivision to a higher minimum in the v11 DSFs. (The water must be subdivided a bit to allow the water to curve around the earth, but the earth triangles were still pretty big).

        Max hardware tessellation factor is 64x, which isn’t enough when the underlying polygon is really huge. We -might- be able to do an on-the-fly tessellation level on load to augment what the GPU can do – we’ll see.

        Because this is using hw tessellation, 3-d water is Windows/Linux only; the Mac drivers don’t expose the tessellator to the legacy profile, so it’ll be a while (like, a year, maybe two) before we see this on OS X.

        • Dmitry says:

          Is it possible to simply make exclusion areas around airports? Won’t be pretty i.e. will be a wall of water, but I doubt anyone flies into areas where there is no ground i.e. in demo mode.

          • Steve.Wilson says:

            Actually, if you want to test in an area with the least impact on framerates, I don’t know of anything that beats an airport runway in the middle of an endless ocean.

    • Michael Minnhaar says:

      So this version of XP is to be good for the next century then – global sea level rise is already modelled 🙂 Hopefully places like KSFO, VHHH, RJTT and many others will stay dry on a stormy day now !

    • Daniel Leygnat says:

      Maybe you can use the airport boundary to create a fake island at the altitude of the apt.dat when there is no DSF in the area.

  2. Christopher Hallam says:

    another to come significant realism addition, will be nice to have 3d water- will it have island colors?


  3. Marty says:

    Awesome!! 🙂 I thought this was a major-like feature and wouldn’t be in v11.
    Will it support different colors? (rivers,ocean, carribean,etc)

  4. myb says:

    My hat just to fell into the water in gratitude for this. Great.

  5. Santiago Butnaru says:

    Hi Ben, this looks Beautiful!!

    What will be the behavior of the water in small water body’s and rivers? and what is the performance hit?


    • Ben Supnik says:

      Small bodies – not sure – X-Plane -already- let’s the DSF mark them as having reduced wave development, and that does affect the 3-d.

      The performance hit is … I am not sure; right now my goal is to have 3-d be “always on” for hardware capable of the effect; for that hardware the tessellation seems to be a non-factor. There’s a real cost to the wave generation, which is FFT based, but it’s highly multi-core. We may have to provide reduced-detail waves for dual-core machines.

      • xplanefan says:

        How many modes in the FFT (given that isn’t a trade secret, of course)? It looks like you are only using the lowest lowest wave numbers to generate the large scale periodicity. I’m guessing the tessellation is what is contributing to the the reflection noise visible on top of that base oscillation. What prevents this FFT process from being done on the GPU cores?

        • Ben Supnik says:

          I’m not sure what you mean by “how many modes” the IFFT is completely seeded with random waves, and then it’s amplitude shaped to meet the spectral requirements. We’re using four layers of 256×256 at various points in the spectrum, but it could use a lot of tuning.

          The only thing stopping it from being on the GPU is (1) actually coding it and (2) getting some way to read the data back to the CPU efficiently.

        • xplanefan says:

          Sorry… By “modes” I was referring to how many unique sinusoids are used to generate the final waveform (256×256?). So you randomize the Fourier coefficients at some point, and then scale the final wave to more closely approximate what might look realistic, given the surface driving conditions? Are the wiggles in the reflections an artifact of one of those 4 layers residing in the higher-frequency end of the spectrum? It’s very convincing!

          • Ben Supnik says:

            Right – since it’s a 256×256 FFT there are 65k modes. I’m not sure which ‘wiggles’ you are referring to…there is a whole pile of artifacts including aliasing in the under-tessellated mesh and what appears to be some kind of bug in my reflection code.

  6. Jose Luis Castillo says:

    Ben should improve the viewing distance of the city lights at night. sad to fly along the coast of Los Angeles and not distinguish the city nor the size of it. Impressive water effect.
    Thank you for your effort.

    • Greg says:

      Totally agree, although have not seen any comment regarding this and v11 so we might be pleasantly surprised, or disappointed.. It might be something that is enabled during the v11 cycle though.

      • Ben Supnik says:

        It’s not coming in 11.0.

        • Steve.Wilson says:

          There we go with the 11.0 thing again. 😉 Is there hope that you might not mean 11.xx?

          • Ben Supnik says:

            It means we don’t -know- for 11.x. The v11 run after 11.0 is still not at all locked down. We have a big bucket of “Stuff we could do” and we haven’t spent time trying to organize it because (1) we’ve been busy with getting 11.0 done and (2) we expect to learn things from the 11.0 release that will change our priorities.

            (The exceptions are: we expect VR to be on the short list no matter what, and Vulkan fits our long term strategic goals.)

          • Steve.Wilson says:

            Fair enough, Ben. Would love to help sort that list!! 😉 (Me and everyone else that reads this blog and every other X-Plane forum on the WWW!)

  7. Frank Kane says:

    Hey Ben, always happy to share notes with you if you ever want to pick my brain on the topic. I had to solve all the same problems you’re trying to solve when developing the Triton Ocean SDK.

    • Ben Supnik says:

      Hi Frank! You might be the only person for whom this makes sense:
      I tried proj-grid first .. and the performance and wave shape quality relative to performance was -spectacular-. It’s nearly optimal.

      The only problem is that integrating it with an actual engine is absolute hell…as soon as you have to cope with variable-sized variable elevation water bodies close to each other, the entire algorithm falls apart. 🙁 I may go back to looking at it again, but the kind of fixes we’d have to do (stencil buffers, masking, render to texture of elevation, etc.) made the cure way worse than the disease.

      • Frank Kane says:

        Projected grids also have that motion aliasing problem you mentioned above with dynamic tesselation. At low altitudes I actually use a radial grid centered near the camera, with detail concentrated near the camera. It gets moved as the camera crosses a tile boundary.

        Another idea is to use different approaches for the Oceans and smaller bodies of water.

        Also, CUDA and OpenCL are magical things for accelerating inverse FFT’s…

        Your results look great already though!

        • Ben Supnik says:

          Hi Frank,

          Right – the proj grid aliases, but under-tessellation is waaaay worse. 🙁 Re: the FFT, OpenCL (or even OpenGL 4.0) would be the logical target, but they require one bit of trickiness: we need to get the finished wave noise back to the CPU for collision testing, and we pick up latency and timing problems if we’re on the GPU. (If we schedule the FFT “between-frames” on the GPU, we can be assured our results are done by the time the renderer -actually- need them. But we might be one frame behind on the CPU.)

          Right now I’m just using kiss-fft on worker threads and it’s “good enough” but I have a note to try other FFT libs at some point.

          • Frank Kane says:

            Yup, I do the asynchronous one-frame-behind thing too. Actually what I do is kick off a CPU copy right after the GPU program is done asynchronously, and then retrieve the result on the next frame before kicking off another FFT computation on the GPU.

          • Ben Supnik says:

            This results in one frame of latency between the rendered waves and the physics-tested waves, right? E.g. our main loop is something like:
            – compute physics iteration.
            – compute camera location (so camera is attached to the FINAL airplane location).
            – render frame.

            Wait – I just realized (and this might not apply to Triton because you give your SDK uses a LOT of extras) – we could compute the FFT one frame ahead, e.g.
            – Keep FFT A around
            – Queue compute FFT B
            – Do physics using FFT A
            – Do camera setup
            – Do render (using FFTA)
            – Read back FFT B

            There’d be latency from the computation of the FFT to having it, but because the FFT field doesn’t depend on input data from the sim*, there’s no reason it can’t be done “ahead”.

            * That’s a slight lie – in a variable fps situation you have to know what your time step is….if the framerate is ‘jtitering’ the wave movement might be really uneven. But that situation already sucks.

          • Frank Kane says:

            I actually live with the one frame delay; there’s enough temporal cohesion in the water over the course of one frame that it doesn’t really matter. People use it for real maritime training and simulation and it’s never been an issue in practice. Buoyancy doesn’t react instantly to waves anyhow.

            Kicking off the next frame’s FFT while computing and rendering the first could work too, I think. Neat idea. Like you said it’s mostly a question of how well that fits into your current architecture / pipeline.

          • Ben Supnik says:

            Yeah I thought that after posting my idea…a frame of latency in water contact is almost certainly acceptable for anything other than decaling…

        • montify says:

          I implemented the Projection Grid into my Planet renderer.

  8. bargbill says:

    Finally a first class seaplane base!

  9. Ed says:

    Fantastic Ben!
    Will the coastlines be updated to HD as well?

  10. Maurits Veen says:

    Does it has the same textures as the normal water we have right now

  11. Leonardo Faria says:

    Hey Ben, I’m about to change my video card and the suggestion is the RX 480 from AMD (I have an intel i7 4770K), but I know that in the forum AMD is much criticized, and I want to run X-Plane 11 with good graphics, it would be a bad choice this graphic card? Do I need something much more powerful and expensive? Are there any changes to benefit AMD in the X-Plane 11, like Vulkan? Grateful for the attention.

  12. Eric says:

    3D water, awesome stuff !!!!

    Airplane Simulator, Boat Simulator ? Scuba Simulator ? lol….

    Will boats and seaplanes go up and down with the waves ?


  13. Colin S says:

    Amazing video, so far this is, to me, the coolest thing coming with V11 other than PBR. My question is, with this new way of rendering water, will bathymetry data be put into use? Are there plans for semi-transparent oceans to be come a thing in X-Plane?

    Amazing work and very stoked for X-Plane 11.

    • Ben Supnik says:

      Not sure what we’ll do with the bathymetry data – I’ve looked at going semi-transparent but it’s not implemented yet. I had that once as a tech demo for Stradale perhap 5 years ago when it was still a desktop app.

  14. Oscar Pilote says:

    Since it is only a few days ahead of what would have been his birthday, it seems a good occasion to celebrate the work of Alain Fournier, who in particular introduced (joint with Bill Reeves) the “simple model for ocean waves” (siggraph 1986) which Ben is building upon.

    And if it is not considered too much chauvinism either, I’d like also to advertise the not so recent implementation of these ideas by french INRIA fellows Bruneton and Neyret into the open source (BSD 3) proland C++/opengl library.

    3D water: now I understand why your mailbox is flooded Ben 😉

  15. Dave says:

    Hi Ben, on the topic of x-plane scenery, what’s the chance of tall buildings outside the US making it into x-plane 11 default scenery ?

Comments are closed.