Is there a way to tell which area a landclass bgl covers? In many cases, they have very cryptic names.With some landclass files collections at different levels in my scenery.cfg I'm pretty unsure what gets used in the end, and there are certainly many overlapping areas (e.g. I have the MyWorld global landclass installed at a very low priority level to assure at least it will be used in areas where I have no specific landclass files for, and installing GE for instance wouldn't override its precedence I'm afraid).Andreas

Andreas,I use BGLAnalyze which disassembles a .bgl file (Landclass in your case) which displays the coordinates that the file covers. You can find it here:http://www.scenery.org/design_utilities_a.htmEIDT: I usually keep all different LC files in two folders and give them some meaningful names. That way I know what goes where and I have more control what LC file should be on top, if there are more for the same area.Regards,Jure

Hello Andreas,Microsoft provides a nice little tool that will visually display the coverage of these terrain files. You can find their TMFViewer in the Terrain S.D.K.Please note that you can, and probably would find it advantageous to, rename all cryptic bgl file names to something that you can understand. FS does not care about the name of a bgl (with only one exception - see below), so there is no problem at all with renaming the file. File names can have a maximum of 255 characters, which is just a little less than the above paragraph; as you can see, there is lots of room, and you can make file names as descriptive as you want.The only exception to renaming file names is those that must be loaded first before the others in the same folder. Usually, you will find that these begin with the character "0", so when renaming, keep that character at the front.Best regards.Luis

Hi there,not much to add to Luis's great advice except a link to the Terrain SDK: http://fsinsider.com/downloads/fs2004_down...m#Terrain%20SDKMaybe you'd also want to read what I wrote about the "memory leak" issue here: http://forums.avsim.net/dcboard.php?az=sho...id=305006&page=Cheers, Holger

Thank you all for the suggestions!I think landclass is among the most underrated topics in he FS world in terms of importance/order and usage.While scenery is usually relatively well controllable, landclass is not because of the reverse ordering in scenery.cfg and the fact that many scenery comes with landclass which gets installed in a way that it cannot be made certain it will be used accordingly/properly.In addition, changes in landclass are not so obvious as it is the case with e.g. mesh, and in my own experiments I found that different install/usage methods of landclass files have sometimes only very subtile but nevertheless very impressing different results.I'll try the tools of the SDK now.Andreas

Hi Andreas,I do agree that land class files are underrated in their importance to increasing the realism of FS. After all, what good are nice and shiny new ground textures if they are placed in the incorrect location? ;-) Unfortunately, making realistic land class files is a very tedious job because you have to determine and manually place the most appropriate tile for each square km of your area of interest. That's what makes some of those tiny (in kB) freeware files real treasures."While scenery is usually relatively well controllable, landclass is not because of the reverse ordering in scenery.cfg and the fact that many scenery comes with landclass which gets installed in a way that it cannot be made certain it will be used accordingly/properly."Actually, land class is much easier to control than mesh and similar to scenery, as the file with the highest priority (i.e., at higher position in the Scenery Library or higher Layer= entry in the scenery.cfg) will always be used. The only potential issue with land class files is if they are placed in the same folder. In general, it's the name that determines priority, e.g., "Z_LC.bgl" will have a higher priority than "A_LC.bgl". The exception is if those two files have a major difference in area covered. In that case, the file with the smaller coverage area will automatically have higher priority, regardless of alphanumerical order.That's why I don't recommend stuffing all land class files into the generic land class folder (SceneryBasescenery) or a single add-on folder, particularly if those files overlap spatially. Instead, I place all my add-on land class as individual entries and then manage those in the Scenery Library, which allows me to 100% control display priorities. See the discussion and screenshot of my library menu in this thread: http://forums.simflight.com/viewtopic.php?t=49134Cheers, Holger

Holger,From what I am understanding reading yor post... I can copy the Land class files (from addons) into my own directory like "C:Myaddon_landclassLandclassset1*.*" and then assigning them into the scenary menu and then checkmark select and unselect them instead of copying them into "..SceneryBasescenery" like regular addon scenaries? Is that right?Manny

Hi Manny,that's correct. In addition, I would give them meaningful names that include the geographic location and the author and also copy the read-me files into the add-on folder (not the scenery subfolder, though that wouldn't make a big difference).Cheers, Holger

Oops, so I think I've completely misunderstood something basic:I was told (several sources at least say this) that contrary to other scenery files, landclass is layered in REVERSE ordering, i.e. higher priority (=level number in scenery.cfg) means higher priority for scenery (mesh, VPTs, LWMs,...) but LOWER priority for landclass.So, aaccording to my understanding, I have my separated landclass scenery folder at level 3 or 4 or so.Is this totally wrong? I'd then need to reorder my scenery.cfg a bit it seems ;-)Andreas

Hi Andreas,it's mesh, not land class, that has the reverse priority "bug" in FS9: http://www.fs-traveler.com/tips-g.shtml . Thus, I have my LOD9 and LOD10 base mesh files at the top of the scenery library so that other add-ons that provide their own mesh files will use theirs as intended.It doesn't really matter where your landclass entries are as a group. What matters more is the order within that group should you have files that overlap spatially. Thus, a regional land class file should have a lower priority than a local land class file (assuming that the local is more accurate). However, because many scenery add-ons, even airports, include their own local land class files I keep all my land class entries near the bottom of the scenery library, above the 39 or so default entries.Generally, my scenery library looks like this:mesh entries on topairport and other object scenery entriescomplete landscape add-ons, like Misty Fjords or Rhode Islandland class entriesUltimate Terrain entries (because they replace the default water/road/railroad files) default entries at the bottomCheers, Holger

hi holger,http://holger.fs-shipyards.net/images/mesh...%20Ferranti.jpgin this screenshot from your website you see this wierd chess board effect. i have that too in my fs9 with your mesh. is that the lack of some flattening algorythm ? can you smooth it out somehow ? it looks really wierd.http://holger.fs-shipyards.net/images/mesh...ranti_variants/the effect is on most of your screenshots.regards, tom.

Hi Holger,Given this logic, shouldn't we pull the default mesh files from the SceneryWorldScenery directory, and then put them in a new directory and give it the highest priority?I suggested making a new directory, because I imagine the SceneryWorldtexture directory should stay just where it is in the hierarchy.Thanks,Thomas[a href=http://www.flyingscool.com/FC_StartJava.html] http://www.flyingscool.com/images/Signature.jpg [/a]I like using VC's :-)

Hi Tom,good observation - I was waiting for someone to comment on this ;-)The problem is a combined issue with the source data, the resample tool used to generate the mesh, and the specific land class type of the area. Also, the Terrain_Max_Vertex_Level used (in my case 20) will have an influence on the visibility of the "steps" (it should be less pronounced with TMVL=19).Because most of the area is snow and thus a very bright texture (and no autogen) the terrain shadowing exposes those small stair steps in the data. If you use my photoreal textures for that area you'll notice that the effect is less pronounced because there's more of a mix of dark and bright textures.http://holger.fs-shipyards.net/images/mesh...0with%20ETM.jpgI was considering using a smoothing algorithm to reduce the effect but that would also have reduced the sharphess of the ridges and accuracy of the peak's elevations. Thus, I decided to leave the source data as they are.Moreover, look at the screenshot of the same position with Raimondo's version of the same data (available at FlightSim). He did the opposite and used a sharpening filter to enhance small detail in the data, which also increased the stair steps. http://holger.fs-shipyards.net/images/mesh...OD10%20mesh.jpgI'll check in with Jonathan to find out what options there are for smoothing the data at the producer's side but that would involve a lot of work.Cheers, Holger

Hi Thomas,most of the default mesh is compiled in very low resolution (LOD5 or LOD6) so any add-on mesh will overwrite it automatically.However, you bring up a good point because there are some LOD8 and LOD9 sections in the default mesh that are not of the same quality as add-on mesh of the same LOD. For example, if you use an add-on mesh of central Africa you may want to disable the default LOD9 version of the Kilimanjaro area, demkil19.bgl to prevent it from being used. Similarly, any LOD9 add-on mesh you may be using for Hawaii won't be displayed unless you disable the default Hawaii mesh file, demhaw19.bglHowever, I don't think that moving all of the default mesh into a separate add-on folder will work because FS will crash if some of the lower LOD files aren't in that folder (if I remember correctly).Here's a great graphical overview of the default mesh: http://portal.fsgenesis.net/index.php?modu...y&ceid=6&meid=4 And Steve has a list of those files and their LOD on his website that includes the exact coverage areas: http://www.fs-traveler.com/resources-g.shtmlCheers, Holger

Well, I tried it. I moved all the LOD 8,9, and 10 files into a new scenery library and put that at the top. Didn't seem to suffer any ill effects. At least it makes logical sense to me now. So now I basically haveDefault MeshMeshAirportsSceneryPhoto SceneryUTDefault regionsCorrected ElevationsDefault ScenerySeems to workThomas[a href=http://www.flyingscool.com/FC_StartJava.html] http://www.flyingscool.com/images/Signature.jpg [/a]I like using VC's :-)