Many thanks Rob.

I have read it all ,I don't I understand it all , but I get the red line.

 

 

have read it all ,I don't I understand it all

Same here. Above my head, but if Rob has a handle on it, that'll do me.

Let me break down my interpretation of this and where things could go pear shaped (read OOMs).

 

 

 

Each cell in the quad tree is assigned a unique identifier composed from the cell's depth in the tree and its distance in cells south of the North Pole and east of the 180th meridian.  With this scheme, only simple integer operations are required to find the identifier of any cell's parent, siblings, and children.  We use the cell identifier as a search key when retrieving the data for each cell from disk and to cache and find cells in hash tables at run time.  Explicit links between quad tree cells are only used where necessary for speed but otherwise we save on link storage and maintenance by using the cell identifiers as implicit links.

 

The unique identifier is a GUID (globally unique identifier) ... if you look in the SDK almost everything has a GUID to identify it.  Lets say an airport's runway 12R object has a GUID -- it's what makes the object unique to any other object in the virutal world.  Use the SDK to get a GUID or if your using .NET call Guid.NewGuid method.

 

Side note: There is a long standing debate about GUID's and if they repeat and/or collision ... it is possible, but you have significantly better odds at winning the lottery 3 times in a row.

 

So now lets take a look in the Terrain.cfg for example:

 

// Telephone Lines

[Autogen.13.0.0]

guid={2727330E-C355-B743-9174-E0097031523A}

LegacyId=13

AutoObject={46F3D6CB-4270-4373-AEE9-89FB38462EA9} (ag_telephonepole)

ObjectSize=200

Offset=15

Density=0

MinAutogenDensity=20

PlaceOnWater=No

RandomHeading=No

 

There you have it, a couple of GUIDs ... now suppose the GUID used in the above was not actually a reference to the intended object ... above suggests Telephone lines and it's Autogen so it's probably 1KB or less in size ... lots of telephone lines in the virtual world.  Now suppose that GUID ended up actually pointing to some other object or the object with that GUID identifier was now significantly different ... it's not a Telephone line it's now a complex D-VOR/DME ground station that's 100KB worth of data.

 

So P3D is now trying to render what it thinks are 50 telephone lines at 1KB each so 50KB total ... but P3D is actually rendering 50 D-VOR/DME ground stations at 100K each so 50 X 100K = 5000K (5MB).   

 

Now these are just hypothetical numbers, but it demonstrates where rapid memory consumption issues can happen if entries get mixed up in the Terrain.cfg and this is by no means the ONLY place this can happen.

 

There are also 3rd party techniques used to improve (reduce draw calls) performance that may not be conducive to VAS usage.  There are so many things that can cause VAS issues and that's why its so VERY hard to pin point the problem and even harder when your trying to pin point the issue using products that are NOT your own (aka 3rd party products).  I'd like to show some of my VAS testing I did for LM, but my results documentation covers NDA stuff so I can't.

 

It's not a trivial process even when one is using 3rd party products to try to emulate.

 

Cheers, Rob.

 

 

I'd like to show some of my VAS testing I did for LM, but my results documentation covers NDA stuff so I can't.

Don't worry too much about that, Rob. We know you have the shoulder at the wheel. I for one will await your joint work with LM cause this leakage concerns you as much as the rest of us in this thread.

Thanks for the great explanations Rob, I see now where some of the tools you have been mentioning would materialise from and how they could be extreamly useful. I also see a dilemma, a fault finding tool by default will point to a problem. you then need some method of fixing the problem other than crude extraction, e.g. Uninstall

Plain vanilla P3D. Only had Orbx's EU:England active. Would it then be a conflict between Orbx's EU;England and UK2000 that was 'sucking the VAS out of my system'?

ORBX England is very VAS heavy if you have the autogen slider towards the right. And UK2000 Heathrow Xtreme is a big airport. It's not a conflict as such, but trying to run those two simultaneously gobbles a lot of memory, doesn't leave much for anything else (such as a PMDG aircraft).

 

If you want the "perfect storm" max your sliders (especially autogen density, scenery complexity), get UK2000 Xtreme London Heathrow and London City, ORBX England, some HD textures sets and some AI traffic then fly between them for a bit in the PMDG 737 NGX, you will OOM before you finish the 10 minute flight! In FSX or P3D.

 

EDIT: Someone's already done it!

Probably late to the party but I run UK2000 extreme (EGLL) and very early on I had to load the airport with its lowest settings otherwise I'd OOM on the ground using the NGX. It still won't play with ORBX EU and the NGX. those three in combination guarantee an OOM on the ground for me. If I want to fly out of EGLL in the NGX I have to turn off ORBX EU and use lower settings.