DSF Mesh Formats – v9 vs v10

31 comments on “DSF Mesh Formats – v9 vs v10”

1. Can you explain how the elevations of mesh vertices are interpolated from raster?

   1. It’s bilinear from the 4 surrounding raster points (since a mesh triangle’s lat-lon doesn’t have to be grid-aligned.

2. This blog kind of went over my head. What’s a mesh ? Is that the shape of the terrain in a nutshell ?

   What is the mesh going to look like once you code this new feature ? Is this something your planning for the V10 run ?

   Regards

   1. Not every post is for a general audience. 🙁

      1. Ben; is it in X-Plane’s road map for it to be used by a general audience; say for example like FSX?

         Cheers

         Dom

         1. That depends on how general general is. I would say it _is_ our intention that X-Plane be usable by a general audience, but our strategy is _not_ to be as mass-market as FSX tried to be. (But: I don’t know what FSX’s real marketing goals were, so who knows.) I do think that anyone who uses FSX with add-on aircraft or scenery could be using X-Plane.

3. 64-bit… Tessalation… Oh my god, this isna dream come true. The more we can load the gpu the better! X-plane is the way of the future!!!

4. Thank you for elaborating my question!

   My follow up question is two parted!

   “Right now everyone uses the same meshes, so we have to limit mesh detail to meet the specs of low-end supported computers. With GPU-enhanced terrain, users with more powerful systems can crank up the detail”

   Will this be done with sliders?

   Microsoft has this feature with their sim and it tend to be very (FPS) load heavy , especially when DEM data is i.e 10meter.

   Will this be any different with the GPU-enhanced terrain?

   1. I don’t know anything about the flight-sim version of this feature.

      I do not know what the ‘cost’ of tessellated terrain will be in terms of fps – since we don’t even have a prototype right now, we have no initial data.

      But I can only say that the MSFS behavior won’t be predictive of X-Plane’s behaviors because the implementations will be radically different.

5. Wow that sounds amazing. I can’t wait to fly over some Alps when the tessellation is done!

6. WOW!!! nice to read this! tessellation!!! TESSELLATION!! wow!, I think this is the most important news of all!, I am attentive to see progress on this.

7. This is absolutely fantastic news. A 64-Bit X-plane with the monumental upgrade of GPU accelerated tessellation will truly make it THE flight sim long into the forceable future. I’ve seen what this feature can do in other games and it makes a literal world of difference.

   One question I do have though, and I don’t mean to keep harping on prior FSX features, but it does have a slider which controls the polygonal mesh terrain detail up to a certain maximum available level. I think it’s something like 15m for the USA and 30m for most of the rest of the world.

   As far as I know, and from my experience in 3D animation, this basically just cuts each tile into smaller and smaller triangles until it reaches maximum detail. Which is also why with some add-ons you can turn it up even higher to 1m or even more if they include more detailed terrain information. I know also that FSX is notoriously CPU bound and makes little use of of the power in modern GPU’s, so it must not be a feature which utilizes any special graphics card capabilities.

   Is there a particular reason why something like this can’t be done in X-plane?

   Really just curious, for discussion sake. FSX is not the end all be all of flight simulation, though some seem to think that it, or the derivative Prepar3D, is.

   1. Until a few weeks ago, the answer was “subdividing the mesh on load time causes us to run out of memory very quickly” because the subdivided mesh was stored in memory.

      In 64-bits, this feature is -possible-. In fact, we had a very hacky version of it running as an experiment during v10 dev, just to see what it would look like. But in 32-bits (what we had at the time) we had to turn off ALL 3-d to even try the test feature.

      1. Hmmmm…interesting. Yet, how is it that FSX, a locked 32-bit program, has been able to do this? From some online perusing I gather that FSX shipped with specific targets for mesh resolution, derived from public domain SRTM data. The highest source data is 38m for most of the continental US, about 70m or so for Europe and Canada, and into 300m per 1 meter for places in South America and others.

         The highest setting of 38m is actually in the middle of the slider for Mesh Resolution and also requires that another slider dubbed Mesh Complexity be set to 100%. Also from what I’ve read, FSX interpolates between the known data point values in order to fill out the mesh. So you start with a high polygon count and as the sliders are turned down, the program does more and more interpolation, until you basically turn mountains into mole hills, if you will.

         If subdividing the mesh at runtime chews through memory, couldn’t you start from the other end and have the default high quality mesh in X-plane, which is quite good I might add, load as it does now if say, a detail slider was set at 100%; then as the slider was turned down you reduce the number a data points as you increase the level of interpolation?

         This may not be something truly feasible or that could be added with a reasonable amount of work, I don’t really know. I’m not a programmer.

         1. MSFS doesn’t run out of memory from high mesh density because the mesh is rebuilt dynamically and only the close mesh is at highest resolution. X-Plane does not currently have anything to dynamically change the mesh res based on camera position.

            That’s why we like tessellation – because the tessellator changes a mesh’s resolution on the fly using the GPU very easily; MSFS users can tell you that when your CPU gets behind, the mesh transitions can ‘pop’ because the CPU hasn’t had time to rebuild the mesh before you see it up close.

            1. “That’s why we like tessellation – because the tessellator changes a mesh’s resolution on the fly using the GPU very easily”

               completely agree, tessellation is the immediate future, I’m exited to see progress on this, and my head is back to dream, I guess if the mesh terrain can have this feature, you also will be able to have other objects like airplanes?? 😀

            2. In theory we could tessellate other meshes. In practice it’s not clear exactly what the win would be. Real-time displacement from normal maps is pretty standard in high-end game engines now.

            3. if it is true, but the point of my question is different, is focused to save resources,

               for example: we have an airport x, where we have eight 737 hd model (project 737x for example) with lots of polygons each, when we are in approximation (10 nm for example) there are a lot of polygons that are not seen but overload the system, even lowering fps. with tessellation, we would just eight basic low poly models and once we have approached, the same model looks fantastic without being overloaded the system. by the way thank you for all support 😀

            4. Right. _If_ all of these are true:
               1. Authors can use tessellation to seriously lower the polygon count of their models and
               2. Tessellation is available everywhere so that authors are willing to do (1) without looking bad on old machines and
               3. Vertex count is the limiting factor in performance

               then we could get a win.

               But I think that there are problems with all three of those assumptions; the most obvious one is (2) – until tessellation is guaranteed everywhere, the motivation for authors is to use a lot of tris – it’ll look good for all users. And (2) is tricky too – you can replace some detail with displacement maps but complex arbitrary shapes still need to be complex and arbitrary.

8. > DirectX 11 class graphics cards can enhance meshes on the fly

   I looked up DirectX on Wikipedia and the explanation has Microsoft all over it. Does that mean that this change won’t have any impact for non Windows users, or does the choice of graphics card have nothing to do with the choice of OS?

   1. No. Here’s what I mean by “directX 11 class”:

      The Direct3D spec describes hardware capabilities of cards. So _all_ DirectX 11 cards can do tessellation.

      But the cards can be driven by two software APIs – Direct3D or OpenGL. Both allow you to use tessellation if the hardware has it, and OpenGL is available everywhere.

      So there’s nothing Windows specific; I’m just borrowing Direct3D’s markings of _generations of hardware_ because the line for Direct3D is really clean-cut. For example, Nvidia:

      DX9: GeForce FX, 6nnn, 7nnn
      DX10: 8nnn, 9nnn, 1nn, 2nn, 3nn
      DX11: 4nn, 5nn, 6nn

      OpenGL versioning and features are quite a bit messier. But when Microsoft sets up a new D3D spec, everyone sort of listens.

      1. Cool!

         I look forward to seeing the results of your efforts then! (Subject to checking the graphics card on my computer.)

9. ….
   * There are also a million other v10 0nly features that the global scenery requires that v9 does not support. Besides not supporting Mesh + DEM, v9 doesn’t support the new terrain shaders, the new draped road system, or the new autogen!
   …
   i am very interested in these new features, especially in the new autogen. Can you please suggest any reading where one can learn more about that?
   Another question for better understanding of the tesselation process: tesselation needs a displacement map to become effective; does the 2 dimensional array of elevations (the raster data) represent this displacement map?
   thanks in advance,
   Dscho

   1. Hi,

      We’re short on docs for some of these new features; I’ll try to get more written when I can.

      Re: tessellation, I think that’s not quite true…tessellation needs a _data source_ to create displacement but a displacement map is only one option. Tessellation shaders can also generate curves from normal vectors (e.g. PN-triangles), or use a procedural source of displacement.

      But in our case, our idea was that with the full DEM available, we could use it as a displacement map for tessellation, yes. We could also add high-frequency shaped noise to it to create sub-DEM detail.

      1. Thanks Ben!

      2. mmmm… yummy
         high frequency noise displacment.
         thats what I want.

         A good technique to fake close detail.
         Also a good technique to melt your video card.

         keep up the good fight.

         1. That’s why they have such huge fans. 😉

10. Hi there, I’m new to the Xplane game and this may not be the best place to ask but I’ve trawled lots of forums and haven’t had an answer. Is it possible with this tool or others to use a small set of data (airport surrounds) to create a mesh for XP at a res of 1 meter/pixel?

    Thanks

    1. No. In X-Plane you currently have to provide mesh data in 1-degree lat/lon tiles.

       At that density you could model features using a 3-d model sitting on top of the mesh.

       You can put _orthophoto images_ down around the local airport at 1 meter/pixel on top of the _existing_ Mesh – use the draped orthophoto tool in WED…

       1. Good thinking. Is the draped othophoto the draped polygons tool?

          Any plans for anything less than 1 degree tiles, and using 1 GeoTiff rather than polygons? 🙂 🙂

          Cheers

          1. You make draped orthophotos by checking the “uv map” button with the draped polygon tool.

             DSF overlays are already less than 1 degree. We are not going to use GeoTIFFs for shipping scenery; you can already use them in WED though.

Comments are closed.