Developer Blooper Reel: Water World

47 comments on “Developer Blooper Reel: Water World”

1. 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).

   1. 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?

      1. 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.

         1. 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.

            1. 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.

   2. 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 !

   3. 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. another to come significant realism addition, will be nice to have 3d water- will it have island colors?

   thanks

   1. We are looking at water tinting – it’s on our list, but I don’t know when it ships.

      1. sounds like I have a long wait anyway since I am on Mac, unless I xfr to PC just for x-plane.

         1. X-Plane runs just fine on Mac OS. Is the only multi platform Flight sim in the universe 😉

            1. He was talking about tessellation (read here: http:/2016/10/developer-blooper-reel-water-world/#comment-15017).

            2. I have it on Mac. I’m saying switch to pC for X-Plane to get all features sooner. More performance and less $.

            3. Not true. See http://www.flightgear.org/

3. 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. My hat just to fell into the water in gratitude for this. Great.

5. 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?

   Thanks!

   1. 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.

      1. 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?

         1. 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.

         2. 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!

            1. 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. 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.

   1. 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.

      1. It’s not coming in 11.0.

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

            1. 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.)

            2. 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. 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.

   1. 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.

      1. 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!

         1. 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.

            1. 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.

            2. 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.

            3. 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.

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

         2. https://www.youtube.com/watch?v=iu39GH1Sae4

            I implemented the Projection Grid into my Planet renderer.

8. Finally a first class seaplane base!

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

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

11. 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. 3D water, awesome stuff !!!!

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

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

    Cheers…….

13. 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.

    1. 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. 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.
    http://graphicsinterface.org/awards/chccs-scdhm-achievement/alain-fournier/

    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.
    http://proland.imag.fr
    https://www.youtube.com/watch?v=2AVh1x-Uqjs

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

15. 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 ?

    1. Not sure – Alpilotx has data for me – it might have to come in an update.

Comments are closed.