Strange FSX file accesses....

[Bert Pieke 7,584]

Luis, I love your logical explanations! The whole area of loading scenery at distance makes more sense to me now... but I am still stuck at my original question: How does detail up close relate to tiles half a world away?I would like to be a smart fellow as well, with LOD at 2.5. That would save me memory and likely improve performance, but the close in visuals would be severely compromised. I fly with LOD at 4.5, not to load distant scenery, but to get a wider range of detail scenery when I fly low and slow.Hopefully Phil can get me straightened out on this..

[PhilTaylor 45]

I was talking analogy and not to specific sliders, can we not change contexts so fast?conceptually the idea of LOD and texture resolution accomplish the same thing for mesh and texture.physically they are linked to different sliders, yes.there seems to be both conceptual and physical confusion, so I tried to develop an analogy to clear it up.that is all.

[Bert Pieke 7,584]

OK, as you can tell, I am still getting my bases straight, but I've now read the terrain SDK cover to cover and can at least follow your analogies. Thanks for helping me through this !I'm still stuck on a simple question which I have not seen addressed, maybe because I have not asked the question clearly.So, here goes one last time :-)Does the lod_radius parameter in fsx.cfg adjust both the number of tiles to be loaded for the scenery and also the close-in radius for displaying detail textures?And if yes, does that mean it is not possible to keep the maximum close-in detail scenery radius and reduce the far-out loading range?

[PhilTaylor 45]

off the top of my head on a Sunday, I do not know.I'll have to dig during the week and get back to you.

[Bert Pieke 7,584]

Fair enough, thanks and have a great weekend - or what remains of it !:-)

[Gypsy Baron 10]

"Is the scenery being loaded, or are the scenery files only being queried by the scenery engine? There is a difference, and the queries are normal procedure - the scenery engine must query the files everytime you move or change orientation since it does not know where you intend to go and it must be ready to load the scenery before you get there.This is pretty important to determine, and there seems to be some confusion in the use of FileMon, so please be specific and indicate whether the files are loaded or just queried.Best regards.Luis"Hi Luis,with all the inputs here from Phil, martin, you and others I ambeginning to get a better picture, so to speak, of what to look forin my particular case.As to the excerpt from one of your posts that I cut&pasted rather thenrelpy-with-quote, I am seeing a sequence or "QUERY, OPEN, READ" and eventually "CLOSE" happening.Just a couple of cut&pastes from a FileMon log enroute KBWI-KROC:19:48:21.562 fsx.exe:1640 READ I:Program FilesMicrosoft GamesMicrosoft Flight Simulator Xaddon scenerystatic objects libraryscenery206b.BGL SUCCESS Offset: 0 Length: 4096 19:48:21.562 fsx.exe:1640 QUERY INFORMATION D:fsx addon scenery 2denmarksceneryobjglobalx.BGL SUCCESS Attributes: A 19:48:21.562 fsx.exe:1640 OPEN D:fsx addon scenery 2denmarksceneryobjglobalx.BGL SUCCESS Options: Open Access: All 19:48:21.562 fsx.exe:1640 READ D:fsx addon scenery 2denmarksceneryobjglobalx.BGL SUCCESS Offset: 0 Length: 188 19:48:21.562 fsx.exe:1640 QUERY INFORMATION D:fsx addon scenery 2denmarksceneryobjglobalx.BGL SUCCESS Length: 1420895 19:48:21.562 fsx.exe:1640 CLOSE D:fsx addon scenery 2khrabrovosceneryobj_bus4.BGL SUCCESS 19:48:21.562 fsx.exe:1640 READ D:fsx addon scenery 2denmarksceneryobjglobalx.BGL SUCCESS Offset: 0 Length: 4096 19:48:21.562 fsx.exe:1640 QUERY INFORMATION D:fsx addon scenery 2denmarksceneryobjglobal.BGL SUCCESS Attributes: A 19:48:21.562 fsx.exe:1640 OPEN D:fsx addon scenery 2denmarksceneryobjglobal.BGL SUCCESS Options: Open Access: All 19:48:21.562 fsx.exe:1640 READ D:fsx addon scenery 2denmarksceneryobjglobal.BGL SUCCESS Offset: 0 Length: 188 19:48:21.562 fsx.exe:1640 QUERY INFORMATION D:fsx addon scenery 2denmarksceneryobjglobal.BGL SUCCESS Length: 156506 19:48:21.562 fsx.exe:1640 CLOSE D:fsx addon scenery 2khrabrovosceneryobj_bus3.BGL SUCCESS 19:48:21.562 fsx.exe:1640 READ D:fsx addon scenery 2denmarksceneryobjglobal.BGL SUCCESS Offset: 0 Length: 4096 19:48:21.562 fsx.exe:1640 QUERY INFORMATION D:fsx addon scenery 2utahcompletescenerykslcobj2.BGL SUCCESS Attributes: A 19:48:21.562 fsx.exe:1640 OPEN D:fsx addon scenery 2utahcompletescenerykslcobj2.BGL SUCCESS Options: Open Access: All 19:48:21.562 fsx.exe:1640 READ D:fsx addon scenery 2utahcompletescenerykslcobj2.BGL SUCCESS Offset: 0 Length: 188 19:48:21.562 fsx.exe:1640 QUERY INFORMATION D:fsx addon scenery 2utahcompletescenerykslcobj2.BGL SUCCESS Length: 421199 ....20:30:46.421 fsx.exe:1640 QUERY INFORMATION D:fsx addon scenery 2khrabrovosceneryobj_kdp.BGL SUCCESS Attributes: A 20:30:46.421 fsx.exe:1640 OPEN D:fsx addon scenery 2khrabrovosceneryobj_kdp.BGL SUCCESS Options: Open Access: All 20:30:46.421 fsx.exe:1640 READ D:fsx addon scenery 2khrabrovosceneryobj_kdp.BGL SUCCESS Offset: 0 Length: 188 20:30:46.421 fsx.exe:1640 QUERY INFORMATION D:fsx addon scenery 2khrabrovosceneryobj_kdp.BGL SUCCESS Length: 19866 20:30:46.421 fsx.exe:1640 CLOSE D:fsx addon scenery 2khrabrovoscenerylib_followme.BGL SUCCESS 20:30:46.421 fsx.exe:1640 READ D:fsx addon scenery 2khrabrovosceneryobj_kdp.BGL SUCCESS Offset: 0 Length: 4096 20:30:46.421 fsx.exe:1640 QUERY INFORMATION D:fsx addon scenery 2khrabrovosceneryobj_iterm.BGL SUCCESS Attributes: A 20:30:46.421 fsx.exe:1640 OPEN D:fsx addon scenery 2khrabrovosceneryobj_iterm.BGL SUCCESS Options: Open Access: All 20:30:46.421 fsx.exe:1640 READ D:fsx addon scenery 2khrabrovosceneryobj_iterm.BGL SUCCESS Offset: 0 Length: 188 20:30:46.421 fsx.exe:1640 QUERY INFORMATION D:fsx addon scenery 2khrabrovosceneryobj_iterm.BGL SUCCESS Length: 113434 20:30:46.421 fsx.exe:1640 CLOSE D:fsx addon scenery 2khrabrovoscenerylib_fence.BGL SUCCESS 20:30:46.421 fsx.exe:1640 READ D:fsx addon scenery 2khrabrovosceneryobj_iterm.BGL SUCCESS Offset: 0 Length: 4096 20:30:46.421 fsx.exe:1640 QUERY INFORMATION D:fsx addon scenery 2khrabrovosceneryobj_hangar_tu134.BGL SUCCESS Attributes: A 20:30:46.421 fsx.exe:1640 OPEN D:fsx addon scenery 2khrabrovosceneryobj_hangar_tu134.BGL SUCCESS Options: Open Access: All 20:30:46.421 fsx.exe:1640 READ D:fsx addon scenery 2khrabrovosceneryobj_hangar_tu134.BGL SUCCESS Offset: 0 Length: 188 20:30:46.421 fsx.exe:1640 QUERY INFORMATION D:fsx addon scenery 2khrabrovosceneryobj_hangar_tu134.BGL SUCCESS Length: 70472 20:30:46.421 fsx.exe:1640 CLOSE D:fsx addon scenery 2khrabrovoscenerylib_equipment.BGL SUCCESS 20:30:46.421 fsx.exe:1640 READ D:fsx addon scenery 2khrabrovosceneryobj_hangar_tu134.BGL SUCCESS Offset: 0 Length: 4096 Lots of other accesses like this between those times.I just had a look at the KSEA scenery and Moffet Field scery files andfound KSEA had files with levels of LOD4/QMID6 while Moffet Field hada landClass file with LOD5/QMID7 levels.I have seen files in both of these addon scenery folders beingcontinously loaded while sitting stationary at KROC but "lookingaround" in the VC view.Looking at the above log data I see the "length" of the READs to be 188 bytes from the beginning of the file. I am assuming that thatis most likely where the LatLon type data is located. If I am understanding all that I've read here, the above extents ofthe "4.5 tile' boundries from those locations should not includeRochester NY. In the case of Khrabrovo, I haven't found a file yet in that folder thatis loadable by TmfView. There are 144 files and since TmfView dropsme back to the last successfully loaded file directory it is a rather tedious process to attempt to find any terrainmesh related files ifthe file name doesn't indicate such types as I have to keep repointing TmfView to the Khrabrovoscenery folder....At some point I hope to arrive at a set of test parameters that I canuse to gather as much data on what appears to be happening here.Although the discussions on 'tiles' seems to relate more to meshand landclss tyoe data, I'm seeing object files, files containingdiscreet scenery elements Queried, Opened and Read and this perplexes me. Paul

[cklink 0]

Great topic and progress, really looking forward to see if these can be independently controlled. As you, I just want to increase the LOD texture rings radius- without having to load mesh & etc from the other half of the world.I've cranked my LOD-Radius parameters up to 6.5 (for mountain flying) which does extend the texture resolution rings, but your really taking a hit in FPS due to the huge increase of file activity for everything that is getting loaded with it at that 6.5 grid size. I might be wrong, but was pretty sure these where independently controlled in FS9. While most other quirks/issues I have and can live with, this one is the biggest show stopper for me in FSX.Regards'Garett

[Bert Pieke 7,584]

Here is some good reading in the interim... note the 2.5-4.5 cells in the detail texture explanation.http://dev.fsinsider.com/developers/Pages/GlobalTerrain.aspx

[Gypsy Baron 10]

While investigating what might be causing the strangefile access behavior, that appears to be somehow linkedto my having the addon scenery for Khrabrovo enabled,I came across some "alt=" values that seem odd in severalof the object placement BGL's when I used BGLAnalyze to convert them to XML.Here are a couple of samples from the 14 files I have foundso far that contain wierd altitude values. In some instances I see the same object 'placed' at what lookslike a normalALT and again at the extremely high ALT. There are toomany of these instances to believe they are typos.First, what appears to be a placement file for a seriesof light poles:------------------------------------------------------This placement code for what I believe is astatic TU-134 ( File name "place_134" )---------------------------And finally 2 entries for the same library objectfrom a file named "libplace_ms". There are severalother entries in this file but these 2 show a"normal" ALT and a "suspicious" ALT.--------------------------Is it possible that BGLAnalyze is interpreting afloating point number incorrectly and these ALTanomalies are actually a negative number? I thinkthat is unlikely but trying to explore all possibilities here.I did remove these 14 files from the scenery folder butthat did not change the file access behavior in FSX.When converting the AF2_UMKK file I did note one messagethat stood out in the middle of the file as I scanned theLATLON values:.. ..Many of the 134 files in this scenery folder contain model data and contain no placement info so I don't suspect them of creatinga problem. There are also some BGL's of the 'old type' which I haven't examined yet. Of all the XML code I've looked at, none of the LATLON values appear to be out of the immediate area. Only the ALT values as shown in the samples above and the 'unknown subrecord type'seem abnormal.Anyone have any insight into what I'm seeing here? Paul

[Mace 1,901]

>>Is it possible that BGLAnalyze is interpreting a>floating point number incorrectly and these ALT>anomalies are actually a negative number? PaulThat is possible. I would suggest you use a different decompiler (I suggest BGL2XML by Jon Masterson) and decompile your obx file with THAT decompiler. Then see what altitudes are for those same entries.There are various versions of BGLAnalyze, not all of which are for FSX bgl's. In fact BGLAnalyzeX is the FSX one if I recall. But I rarely use BGLAnalyze or BGLAnalyzeX.On the other hand, Jon's BGL2XML is for FSX no if's ands or buts about it.Compare the output of both and see how things go.RhettAMD 3700+ (@2585 mhz), eVGA 7800GT 256 (Guru3D 93.71), ASUS A8N-E, PC Power 510 SLI, 2gb Corsair XMS 3-3-3-8 (1T), WD 150 gig 10000rpm Raptor, WD 250gig 7200rpm SATA2, Seagate 120gb 5400 rpm external HD, CoolerMaster Praetorian

[Gypsy Baron 10]

>>>>>Is it possible that BGLAnalyze is interpreting a>>floating point number incorrectly and these ALT>>anomalies are actually a negative number? >>Paul>>That is possible. I would suggest you use a different>decompiler (I suggest BGL2XML by Jon Masterson) and decompile>your obx file with THAT decompiler. Then see what altitudes>are for those same entries.>>There are various versions of BGLAnalyze, not all of which are>for FSX bgl's. In fact BGLAnalyzeX is the FSX one if I>recall. But I rarely use BGLAnalyze or BGLAnalyzeX.>>On the other hand, Jon's BGL2XML is for FSX no if's ands or>buts about it.>>Compare the output of both and see how things go.>>>Rhett>Well, that was it Rhett.I used Jon's utility and it shows those ALT values as negative values: So, on to search for other possible problems with this scenery that is causing FSx to continually access the files as well asothers.Thanks for that reminder about BGLtoXML. I have it in my 'FSX Tools'folder but didn't use it as my first choice, obviously. Paul

[Mace 1,901]

>>So, on to search for other possible problems with this scenery>>that is causing FSx to continually access the files as well>as>others.>I have two questions about this interesting thread that can help me work through it in a logical manner:1) Does it do it with all default scenery? Have we determined that?Or is it just the 3rd party like this Khabrovo?2) These file accesses in filemon...are these accesses just QUERIES, or are they actual scenery items being loaded into mem? Luis asked that question earlier and I never saw any response from anyone.RhettAMD 3700+ (@2585 mhz), eVGA 7800GT 256 (Guru3D 93.71), ASUS A8N-E, PC Power 510 SLI, 2gb Corsair XMS 3-3-3-8 (1T), WD 150 gig 10000rpm Raptor, WD 250gig 7200rpm SATA2, Seagate 120gb 5400 rpm external HD, CoolerMaster Praetorian

[Guest EdrickV]

From what I've seen in the log above and some experiments of my own, it's not loading all the stuff from the files it's accessing. First it reads 188 bytes (checking the BGL header?) then reads up to 4096 bytes, which is only 4k. Maybe that 4k is where the location data is stored, and it's just checking to see if it needs to load the full object? I don't know the actual structure of the basic BGL format, but running filemon while using the Go to Airport function I noticed that it did a second read on one of the airport data BGLs with an offset of 4096 and it read a much larger chunk. After typing something in one of the boxes to change the airports it showed, it did the same thing with another file. (188 read, 4096 read, larger 4096 offset read)Of course, most of the files in the Khrabrovo scenery are so small that it doesn't really need a 4096 offset read."Let me help you out. You're cleared to taxi any way you can to any runway you see."

[Mace 1,901]

>From what I've seen in the log above and some experiments of>my own, it's not loading all the stuff from the files it's>accessing. That's the key thing that needs to be determined, as I see it.Is the sim merely querying these files, or is it actually loading them into mem? Querying is one thing. Loading them into mem is another.RhettAMD 3700+ (@2585 mhz), eVGA 7800GT 256 (Guru3D 93.71), ASUS A8N-E, PC Power 510 SLI, 2gb Corsair XMS 3-3-3-8 (1T), WD 150 gig 10000rpm Raptor, WD 250gig 7200rpm SATA2, Seagate 120gb 5400 rpm external HD, CoolerMaster Praetorian

[Guest abulaafia]

thank you for this fantastically clear explanation!