Position of Mesh folders in Scenery.cfg

[Cruachan 705]

Hi,This afternoon I read elswhere on this site that there can be conflicts between the default terrain mesh in FS2004 and some addon terrain mesh.Whereas scenery addons are dealt with in a similar way as they were in FS2002 it appears any addon Mesh should be put in folders (e.g. LAGOTMS_Collection or Addon Mesh)and assigned a much LOWER priority in the scenery.cfg file.My question is where exactly should these additions be placed?This is how my scenery.cfg starts:[General]Title=FS9 World SceneryDescription=FS9 Scenery DataClean_on_Exit=FALSE[Area.001]Title=Default TerrainTexture_ID=1Layer=1Active=TRUERequired=TRUELocal=SceneryWorldRemote=[Area.002]Title=Default SceneryLayer=2Active=TRUERequired=TRUELocal=SceneryBASERemote=[Area.003]Title=Landclass AddonsLayer=3Active=TRUERequired=FALSELocal=Landclass AddonsRemote=Should references to addon mesh be placed at the head of the queue OR between Area 001 and Area 002 OR after Area 002? Or.... does the placement really matter if the addon mesh is of a higher LOD than the default, since my understanding is that FS2004 uses this preferentially as it did in FS2002.As you can see I have already followed previous advice given re. the positioning of addon Landclass files to avoid conflicts with the various default photorealistic areas prvided by MS. That seems to work fine.Thanks,Mike :-wave

[Justin Toposim 16]

HI Mike,In the vast majority of cases, you will have no problems putting all your terrain files in sceneryworldscenery.The only possible conflicts that may arise are with identical LOD files compiled from identical source resolution files, in which case the whole question is probably moot since both files would be virtually identical anyway.-------Justinhttp://www.fsgenesis.netHigh Quality Scenery for FS200x

[Cruachan 705]

Hi Justin,Thanks very much for your help. Can I assume, therefore, that the current positioning of the TMS_Collection and the various mesh addons (having higher LOD than default) I have accumulated can be left where they are towards the bottom of my scenery.cfg file?viz.:(Area.040)Title=TMS_CollectionLayer=40Active=TRUERequired=FALSELocal=LAGOTMS_CollectionRemote=(Area.041)Title=Addon MeshLayer=41Active=TRUERequired=FALSELocal=Addon MeshRemote=Mike :-wave

[Justin Toposim 16]

HI Mike,Yes. But IMO the only advantage you get from putting them anywhere but the sceneryworldscenery folder is the ability to easily them off.As you are probably aware, terrain mesh is prioritized by LOD, and their position in the Scenery Library layering scheme is irrelevant in (the hedge) nearly all instances.-------Justinhttp://www.fsgenesis.netHigh Quality Scenery for FS200x

[Holger 0]

Hi Justin:"The only possible conflicts that may arise are with identical LOD files compiled from identical source resolution files, in which case the whole question is probably moot since both files would be virtually identical anyway."Hmmm... I guess someone hasn't digested the news yet ;-)In FS2002, one could rely on the terrain engine displaying the mesh with the better source res (given identical LOD); in FS9 that's no longer the case. Now I can make a mesh with 1000-m source data and compile it at LOD10 and make it override any 30-m mesh of the same LOD. I can do this by placing it in the same folder as the 30-m mesh and making sure it's the last one (in alphabetical order) in that folder. It's the filename that determines precedence for mesh files with the same LOD residing in the same folder, and I'd call that a conflict, or undesired result!This may be an extreme example but we all know that there are plenty of "oversampled" mesh files out there, old and new.Of course, if all your add-on meshes come from the same provider then one should expect that there will be no conflicts. However, most people have a collection of different mesh files and for all those I recommend keeping mesh files of different authors in separate add-on folders unless you have tested that they work together as intended. There's another reason for doing so, as source and sample resolution are NOT the only factors determining the quality of a mesh. Procedures for interpolation of missing data, coverage of the LOD grid, adjustments to better fit the MS roads, lakes, and shorelines, etc., often differ among authors but have a big influence on overall mesh quality.Steve has spent quite a bit of time trying to sort out the changes to mesh priority and his process is transparent and can be repeated by anyone interested: http://www.fs-traveler.com/priority.shtml Justin, can you support your statement and recommendation in the same manner? That's not a flame :-ukliam I'm just curious because it would be really helpful to agree on how FS9 handles potential mesh conflicts.Cheers, Holger

[Justin Toposim 16]

HI Holger,Note "the hedge." :-)There are nearly unlimited combinations of third-party mesh possible, only a tiny fraction of which may result in the conflicts you mention. These rare conflcts can be dealt with in individual cases by applying the alphabetical rule or layering priority.But in the vast majority of cases, in Mike's case, and as a general rule, the "highest LOD will display" will suffice.-------Justinhttp://www.fsgenesis.netHigh Quality Scenery for FS200x

[Holger 0]

Hi Justin:I respectfully disagree, for all the reasons I mention in my previous post.For the average mesh user the main interest will be in avoiding potential conflicts, not resolving them. Piling all add-on meshes of different authors into one folder will not achieve this. There are quite a few areas, particularly in the Americas, where there are 5 or more add-on meshes available by different authors for the same area. Given what we know now, I won't trust my FS9 that it will pick out the best one for me :-)Keeping add-on meshes in separate folders, by author and/or region, is IMO the most convenient and reliable way of avoiding conflicts and, if they happen, resolving them. This has become more important with FS9 than it was with FS2002.It's not necessary to place each and every add-on mesh in its own folder. I separate those that overlap spatially and are made by different authors, even if they are of different LOD (remember "oversampling" and "overall quality"). In total, I have about 20 different folders for worldwide coverage.As for priority in the Scenery Library, I keep all folders together as a group so that I can switch priority levels easily, if necessary.Cheers, Holger

[Guest sgreenwood]

Hi Mike, The problem is not so much one of conflicts between default and add-on mesh as it is between the various add-on mesh files available, and then only when the LOD is the same. (A larger problem for the US, for which much more mesh is currently available.)If you do find a conflict with the default mesh (unlikely in Europe), you would have to assign the add-on mesh a lower priority - Layer 2 will always be low enough.Mesh and scenery operate independently, so you need only consider the priority of each mesh folder relative to the other mesh folders when deciding where to place them. (You can probably place them all above all the default scenery folders.)My own perspective on this welcome development============================================In the long run, this change is a "good thing", because it gives us more control over the rendering of our mesh. But the first stage in the process of adapting to changes of this magnitude is "denial". It has already started, and we will see much more of it in the days ahead.It might be useful to compare this situation with the Y2K "crisis". We'll describe only two extreme cases.Over the years preceeding the year 2000, Company A developed code that handled dates correctly. Company B took shortcuts, because that was easier, and worked just as well.As the year 2000 drew close, Company A required little or no additional preparation for the New Millenium. Company B had to spend Billions of dollars to stay in business. Both may have been valid business models prior to the year 2000, but on 1/1/2000, only one business model was left standing.And so it is with mesh. Individual A carefully installed his mesh in separate folders, retaining control of the situation.Individual B installed all his add-on mesh in one folder, along with the default mesh. Both "business models" worked well.Enter FS2004, with new rules for mesh rendering. Individual A spent a minute or two reassigning the priorities of his folders and is off flying again.Individual B has hundreds, perhaps thousands, of accumulated mesh files in one folder, and very little recollection regarding their LOD, source resolution, or other factors contributing to the quality of each file. Individual B has a problem. These are extreme examples, but I expect there are many users represented by each. Many others fall in between. And, for now at least, there is only one reliable "business model" for installing mesh left standing as well.Fortunately, there is no fixed deadline for dealing with this change, and the consequences for failing to do so depend on the amount and variety of mesh installed, and on its importance to each individual. Because we will be dealing with this issue for some time to come. :(Stevewww.fs-traveler.com

[Justin Toposim 16]

Hi Holger,I guess this begs the question as to >why< would someone want to purposely install duplicated mesh, thus inviting these conflicts?It seems that the most common scenario would be for a simmer to pick one mesh to install, rather than all available terrain for any particular area.Thus, the avoidance of conflicts is attained by >not< installing every mesh available for a particular area. I think we're talking primarily about the various freeware meshes with "cookie cutter" coverages, which may have some areas of overlap by the very nature of the randomness of their boundaries. In these cases, sure it's probably best to install to separate folders.But for those many simmers who prefer either of the commercial full-coverages, the point is probably moot. I'm not sure why someone would install my or Steve's US 38.2m full coverage mesh, then try to install freeware of similar LOD in the middle of it.-------Justinhttp://www.fsgenesis.netHigh Quality Scenery for FS200x

[Holger 0]

Hi Justin:"But for those many simmers who prefer either of the commercial full-coverages, the point is probably moot. I'm not sure why someone would install my or Steve's US 38.2m full coverage mesh, then try to install freeware of similar LOD in the middle of it."I fully agree (and said just that in my original post), alas not everyone has either of these payware meshes. I don't know the sales figures but its probably safe to assume that there are still more simmers without FDG /FST/LAGO products than with ;-)In fact, Mike's original question does not mention US payware mesh (though you may know more about him than we do) and his message indicates only that he has some LAGO mesh installed. My intent was to propose a setup that works for any collection of mesh files, not just single-source payware.Seems to me that there is more to agree on than to disagree...Cheers, Holger

[Guest sgreenwood]

Hi Justin,"I'm not sure why someone would install my or Steve's US 38.2m full coverage mesh, then try to install freeware of similar LOD in the middle of it."Consider this scenario, which I think you will agree is desireable, at least in part. Someone, living in Oregon, decides to upgrade from the default FS2002 mesh to brand RS, covering the US with mostly LOD10 mesh. They are pleased with the improvement, but later learn that most of their mesh is constructed from 90m data, and that much better mesh is available, constructed from 30m data, also at LOD10. Since they have already invested in mesh for the US and fly mostly in the West, they decide to add one of our packages for the West Coast. Recently they have upgraded to FS2004, and learned about even better mesh available for the Pacific Northwest, including the entire state of Oregon, constructed from 10m data, also at LOD10 (since higher LODs show no additional detail in FS2004). Another upgrade.They now have three sets of mesh, all with an LOD of 10, and all overlapping. These are all realistic upgrades reflecting a growing appreciation for high resolution mesh. The only way they can benefit from their informed investment in all of these upgrades is to install them in separate folders and assign Priorities accordingly.(I also have two areas of freeware 10m LOD10 mesh available which I hope everyone will download and install over our 30m LOD10 mesh. In appropriate folders, of course.)Hope this helps :)Stevewww.fs-traveler.com

[Guest Marky Parky]

Only for your information - it is possible to show more detail mesh than LOD10. In FS9.cfg in section terrain is a value named like "terrain vertex complexity" or something like that ( I don't have FS right here beside me to take a look, but I may post it in the evening ) and it's default value si 19. If increased to 21, it show LOD11 mesh and increased to 23 shows even LOD12. I didn't experimented more with it ( in fact, LOD11 was enough for my propose ) but I think it wil grow simmilar way.Marky Parky

[Guest sgreenwood]

Thanks Marky,You've got the right idea, but it actually operates a bit differently.The TERRAIN_MAXIMUM_VERTEX_LEVEL (TMVL) parameter plays two roles in the sim:* setting it to a value higher than 19 enables the sim to use mesh with an LOD greater than 10 (as you suggest)* the higher value also allows the sim to reveal additional detail in high resolution mesh. This is true even for LOD9 mesh, when constructed from high res source data. Note: A value of 20 is sufficient to display mesh up to at least LOD13. Values above 21 have no further effect.In FS2002, 10m source data (for example) displayed in the sim with a TMVL value of 21 provided increasing amounts of detail as the LOD was increased from 10 to 11 to 12.In FS2004, this is no longer true. Screenshots show that the amount of detail rendered in the sim is now exactly the same, not matter which of these LOD values is used. Increasing the LOD above 10 is no longer of any value. (Increasing the TMVL values still reveals additional detail, however, but not as much as in FS2002.)This is a rather disappointing step backwards, probably a concession to performance. We can only hope that MS will give us back the additional detail in the next version.But for the next 2 years, mesh constructed using an LOD greater than 10 only increases file size and reduces the radius under the aircraft where this mesh is used. :(Regards,Steve

[Guest Marky Parky]

Thanx for interesting info, I had this information from my experiments with FS2002 and I didn't expect MS would make a step back like this.But there is one think I do not understand. Please correct me if I am wrong. If I make I whole "sqare" of LOD9 it gives me appriximately 128kB of unpacked TMF data ( 256*256 in 16 bit ). It doesn't matter whatever I use source in LOD8, LOD9 or LOD10. I will always get the same file size. If source was in LOD9, i'll get almost the same file, if source was LOD8, resampler will use value of any point fourtimes ( twice for longitude a nd twice for latitude ), if I use LOD10 source, resampler will use only 1/4 of points ( 1/2 for longitude and 1/2 for latitude ).I understand, that increasing of TMVL value can increase number of visible vertexes and make even low detail mesh "smoother".But you wrote this:* the higher value also allows the sim to reveal additional detail in high resolution mesh. This is true even for LOD9 mesh, when constructed from high res source data. That makes no sence to me, because the proces of resample has already dropped away all detailed data and there is no possible way to find them out but a new resample in a higher LOD.Thanx for explanationMarky Parky

[Guest sgreenwood]

Let's look at the process a bit differently, omitting the details for now. There are two parts to this story. First consider the mechanics of creating the bgl file.You use the inf file to describe your source data resolution (CellX and CellY) and the resolution you want it converted to in the final bgl (LOD).Resample then uses a secret (and probably somewhat complex) algorithm to create your new set of elevation points for you. Each point is probably calculated using a number of source data points in the immediate area, weighted according to their distance from the new point. This should mean that the higher the source resolution, the more accurate the mesh will be, whatever final resolution (LOD) you use. For any given source resolution:Mesh with a resolution about the same as the source data should be about as detailed and as accurate as the source data.Mesh with a resolution lower than the source data (undersampling) will have less detail than the source data, but what detail it has will be fairly accurate at the locations of the data points. Mesh with a resolution higher than the source data (oversampling) will have more detail than the source, but accuracy will suffer because so much interpolation is required to construct the additional data points.This is a bit more sophisticated than throwing out or reusing the data, but it is the same general idea.Now that you have your bgl file, we have to consider what the sim does with it. "the proces of resample has already dropped away all detailed data and there is no possible way to find them out but a new resample in a higher LOD."In a sense, that's true, but you are assuming the sim is using all available information in the bgl when the TMVL value is 19! I don't know how the TMVL parameter affects the detail we see, but consider two possibilities (which probably operate together):* MS uses a default value of 19 to limit the amount of available detail used in order to insure reasonable baseline performance. If this is true, then increasing the value may relax this constraint and provide more detail, at the expense of performance.* The amount of detail we see per vertical inch of screen real estate in the foreground is far greater than the amount of detail we see in a similar vertical inch on the screen at the horizon. This is accomplished by collapsing multiple polygons into one once they reach a minimum threshold size. TMVL may be adjusting this threshold, preserving detail out further toward the horizon as we increase the value. (Probably not a linear relationship, however. It could just be an entry point into a lookup table which provides parameters for any number of variables affecting resolution.)So, converting the source data to a convincing image on the screen is a fairly complex process (Thanks, MS). We are not likely to learn much about the details, so the best we can do is test theories by comparing screenshots. I try to do more testing than speculation, but I'm not always successful. :)Steve