mrbump

Perfect! As expected. So you're basically agreeing that mesh changes by CGL breaking airports are a non-issue if the airport is done properly (as we would expect from any reputable designer). Since the priority of the base mesh is always lower than any terraforming. By the way: I wouldn't trust the height profiles. When measuring the resulting elevation of the defined points they are hardly ever where they should be. And the shape is only roughly correct, often totally wrong. I'm starting to replace those and the polygones with heightmaps which seem more trustworthy and more correct and allow sideways sloped runways and aprons (Les eplatures...)

It's not that strange. This is the type of artefact you get all the time when you're tinkering with terraforming. What people need to realize is, that heightmaps are not "the mesh". They are a modifier to the base mesh that needs be resampled and applied to the base mesh (that is also in memory) constantly at run time. So the thread that occupies itself with this resampling task possibly just couldn't keep up. Too much to do...

Well, since "protecting airports" seem to be a high priority for you, have you considered doing the exact inverse of what you are doing now? Let me explain: As far as I understand you, the traditional approach for airport developers is this: Asobo gave us a crappy initial mesh and we built our airport on it conforming to the crappy mesh. Now the mesh has to stay like this forever, therefore we can only allow heightmap-"meshes" with holes for the airports, where the crappy mesh can persist for all eternity. For those wanting to install a better mesh we just have to say "Sorry, incompatible". Well the problem with that approach and cloud streaming scenery is, that sooner or later a world update will come and break your airports anyway. The inverse approach would be to future proof YOUR airport from the inside RIGHT NOW. The heightmaps are the right tool for that. Your Airport will look great with a highly detailed and correct elevation model. The coming world update will not break it and custom CGLs that will inevitably be coming are playing along just fine. After the world update you can decide if you want to leave the heightmaps in or whether it's fine to remove them. A picture to illustrate: LSPH has had dams and troughs for a flood retention basin built around it a few years ago. These structures are quite prominent so I wanted to have them. Hence I plastered the airfield area with heightmaps. Now I'm experimenting with CGLs (test patterns etc.) I find, that LSPH is still looking exactly the same, no matter how broken the base mesh is. "Protected" as you call it. But without restrictions for the rest of the world. In my opinion this is the way to go. But yes, it's just my opinion. Sorry, this is getting a bit off topic for a user forum....

Look, this doesn't have to be a pissing contest and I'm totally fine with you and others making money on heightmap sceneries generated with Paavo's tools. I just wish these developers would be more informed and then upfront about the technique they're using. This is from Paavos documentation: (but he's obviously also just speculating) So with all that misinformation I read in this thread I just had the urge to jump in. No harm intended. Full disclosure: I'm working on my own CGL tool based on muumimorkos documentation and improved with my own research. My goal is to mainly improve a few meshes to bridge the time until they are officially world-updated. Whatever I may be releasing will be Freeware/CC so I don't have a financial stake in this discussion. I use Paavo's tool to get even finer detail as part of airfield sceneries (small areas, as they were intended for). But for all I care plaster the whole world with heightmaps, buy it, download it, be happy with it if it works for you. But don't spread misinformation!

This here is about the only thing I could theoretically agree with were it not for the fact that you completely ignore that your use of heightmaps is well beside their intended use (and I would therefore consider it unsupported). That is totally not a fact. If you see "terrain morphing" in let's say ItalyDEM it's because it was built on a an early version of the tool by muumimorko which does downsampling wrong. It has nothing to do with the CGL format. They don't have issues working together if properly done. The way it works (my current theory...) is actually quite logical. In general the local CGL is prioritized. When you get closer and there is a higher LOD in the cloud it will switch to that (per 257x257 tile). So that would allow you to publish a CGL with high resolution Switzerland and low resolution france, where your low resolution france would not overwrite the (world updated) high resolution france from the cloud. PS: I don't mean this as a personal attack. I just had the impression there was some misinformation in this thread.

Funny to see the CGL method shunned - because I would have thought it's the other way round: CGL is the proper solution while heightmaps are a total hack. Yes, CGL is undocumented as of now, so such sceneries will have to be regarded as "experimental" - apart from that this format is the way to go for large scale meshes. CGL: It's the format that is used by default. A low resolution version is installed locally, a high resolution version is streamed from the cloud - but this can be prevented if there is a higher resolution CGL installed locally in the community folder. The CGL contains the lower LODs precalculated/optimized. Render distance is all the way to the horizon. As this mesh is on a lower level than all terraforming primitives there is no need to create holes for specific sceneries - airport terraforming always has the higher priority. So if there are conflicts - it's the airports fault. Once Asobo will come up with a better mesh from the cloud it will also work like the CGL. Heightmaps: The original intent by asobo was probably to provide a slightly more versatile terraforming tool to airport makers. I doubt they ever thought that people would abuse it to plaster over whole countries. And I doubt they would endorse this technique. Because heightmaps occupy the same level as the terraforming on airports that is where the conflicts happen and therefore why there needs to be holes. Heightmaps are not really a mesh, they have the ability to modify the underlying mesh but they are totally unaligned to it. I'm therefore also guessing, that both the underlying CGL based mesh and the heightmaps have to be loaded into memory - it's not a replacement. As the heightmaps are not aligned with the underlying mesh and so the mesh needs to get calculated/modified at runtime. Probably has to be recalculated at the time of an LOD switch. Render distance is really not that far and very visible for those flying high.