I know zero about BGL's but would imagine that they are a script created either manually or with a scenery programme then compiled. So is it the scenery programme, the compiler or how a particular section of code is handled within P3D?

 

I don't know about FSX, as far as I know the ASM process is "safe" with FSX but it's a big problem for P3D.  

 

However, in the  case of the cvxOresund_Terrain.bgl and it causing rapid VAS depletion to eventual OOM, I've been informed it was a BGL produced by the P3D SDK.  So if that's the case then it would warrant some investigation by LM and yes it could have far and wide implications.  Even if it's some conflict with another 3rd party product, it should not exhibit massive VAS depletion like I demonstrated above.

 

BGL's are produced via the SDK and hold all kinds of info ... there are "outside" tool's and process that work with BGLs that aren't a part of the SDK but are used by developers primarily to work around the limitations of the SDK.

 

Identification is key to resolution ... no amount of statements about "code is junk" or "code needs to be re-written" is going to help or solve problems ... I see a lot of these comments and frankly their painful to see ... what makes people think that re-writing entire code base is going to solve anything?  Since programmers are human (and do make mistakes), re-writing an entire code base would just introduce even more bugs and issues to be resolve ... I'm not aware of any programmer from top to bottom that can write bug free and highly efficient code of this complexity from scratch and get it done in one shot (and I know A LOT of very talented programmers, way more talent than I).

 

It's a process of working with 3rd party and working with LM to come to resolution (or at least identification).  Now is the time to use that opportunity as LM do listen, do adjust, and do fix issues.  With my "end user" hat on (not my developer hat), I'm just trying to help pin point specific issues as this will save both 3rd party and LM time ... in the hope of more rapid problem resolution.

 

Cheers, Rob.

Hi Rob mate,

 

What has the developer said? He's a nice guy and usually responds pretty quick.

 

Alex

VAS depletion to eventual OOM

 

Hi Rob,

 

From my experience the main problem is arriving at a major airport, as VAS depletes enroute and usually leads to an OOM on final or shortly thereafter.

 

Interestingly enough I've never experienced the OOM you mention leaving EKCH, though I've had plenty on arrival. There are certain areas I now avoid flying over altogether, as trying to engineer a flight plan around OOM hotspots like London is just tedious.

 

It's a shame that we now have hardware to run FSX and Prepar3D at a decent framerate, but are stuck in this OOM-bubble due to the 32-bit VAS limit. I hope LM will eventually come up with a solution for all of us to enjoy complex scenery without having to worry about any program crashes.

 

Cheers,

 

Jerome

Strange indeed. Never had this issue leaving my home airport but had to disable UTX2 or vector when i was planning arrival. I do have the HD pack installed but using 1024 tml in the NGX and 777 with lod 4.5.

 

Anyone tested if there is a impact with hd textures using TML=1024?

 

Michael Moe

Interesting.. I'm experiencing the same high VAS issue with FT Dubai in P3DV2. Anyone else having that issue?

 

ROMAN78

The high VAS at OMDB is not surprising - look at all the autogen for the entire city of Dubai surrounding it, including all those skyscrapers.

 

OMDB is another order of magnitude more complex than EKCH.

What has the developer said? He's a nice guy and usually responds pretty quick.

 

Yes, the dev is VERY nice guy and has responded and is looking into it ... the dev has been open to discussion which is pretty rare and I certainly appreciate it.  

 

3rd party development can be a coveted world (especially from an "outsider") which can make problem identification/resolution difficult ... and finding end users to spend hours pin pointing a specific file (or files) that causes problems in certain situations is pretty rare.  I just happened to have a free weekend to dig in as I was working on some other testing for LM.  

 

 

 

but are stuck in this OOM-bubble due to the 32-bit VAS limit.

 

In this specific instance 64bit would not have solved the problem (memory was being consumed at a rate of 400MB every couple of seconds) ... 64bit would have extended it a little until all your RAM was consumed and then started paging memory to your OS paging file until that ran out and then OOM.

 

The surprise was that just one tiny 1K file could cause this issue ... I'm waiting to see exactly what this triggered and why.  Like I said 32bit or 64bit will not matter, identification is they key to problem resolution regardless of 32bit or 64bit code.

 

We all want a 64bit product and it will come, but for here and now figuring out existing VAS consumption issues is important moving forward ... if it turns out there is a problem with P3D SDK when it builds a BGL with specific set of parameters then it could have wide spread implications.  BUT, we'll need to wait and see what comes of this ... step 1 is to identify, now we wait for step 2, 3, etc.

 

Cheers, Rob.

I completely concurre that identification is the main ingredient. As an example, when I was on the technical side with a major retailer and DVD was introduced, as a company some off our players would not play certain disks. Some major manufacturers also had this problem with their players. Was it the disk or was it the player? As you can imagine arguments ensued. I was given the unenviable task of finding the solution.

 

The dvd consortium issued two huge documents one was for the player manufacturers and one for the disk manufacturers. Call it the SDK of player and disk manufacture/authoring. Of course, as you mention, everything was written and made by humans. Like all documents of this type, some things were clear and some things were open to interpretation. A DVDs player is like a computer it has to have its own operating system written and it had to have the correct memory etc. The disk had to be authored so it too was reliant on a computer programme being written to correctly author the disk according to the SDK. So, was it the player? Was it the Disk? Was it the authoring tool? Who was suffering? Everyone! We were getting returns of players, the retailers selling the disks were getting returns and the big studios releasing blockbuster movies were not happy.

 

To cut a long story short, before a certain first for DVD blockbuster title was issued by one of the worlds biggest studios, so sales were expected to be huge I was already working with them to find the problem. Let's just say that by this time the legal eagles were starting to extend their tendrils so their was a lot of pressure. We brought together the manufacturers the studios and the authoring houses and because of one certain disk (a little like you finding the BGL) step one was accomplished.

 

People that say the words "bad code" simply show their lack of experience. Finding problems is about the detail and sometimes bringing all the different parties to the table. It's all about finding the hook and sometimes facilitating to solve the problem. In my example above, knowone had made an error everyone had done everything correctly, by the book, and the two books were huge. The issue was interpretation in this case. Step two followed quickly but their was also a step three which was solved and by getting everyone to talk and finding the hook, the problem had a resolution. I call it the Appolo 13 solution. The Luner module was made by one manufacturer, the command module by another. NASA issues the SDK and when that one in a million problem occurs, all the parties got together and solved it. Software is no different.

A little bit off topic but this also appliable to this airport :

 

In the last week I done at least 10 flights.

 

It is always the same : 1.4-2.0 Gb free VAS at the departing airport.

Then in flight VAS gets less and stabilizes at 800-1000 mb.

 

When descending VAS slowly gets less till 500-700 mb.

When the airport is 20-30 mls away free VAS gets less quick.

 

After landing ( only with very light settings ) free VAS stabilizes....

 

As free VAS doesn't get higher when leaving the airport it looks like the scenery stays in the memory.

However when flying at 10.000 + VAS stabilizes.

That looks like there is scenery unloading.

 

But when descending free VAS is getting less again till OOM or with ligt settings I can land....

That looks as if scenery is not unloading again...

 

Can someone explain what is happening ?

 

Just did a test flight from EKCH to 29 palms new airport EDBC

with LOD set to 6.5

 

Hi David,

 

I dare you to reverse your route and now head back into EKCH with a 6.5 LOD 

 

Cheers,

 

Jerome

Can someone explain what is happening ?

 

Currently NO.  If we get some diagnostic tools (other than remove BGLs one at a time and repeat until solved), then we stand a better chance at identification.

 

In the case of A to B flights there will be 1000's of BGLs being read from disk and loaded into memory during that flight ... as we can see, it only takes 1 small BGL to cause memory issues (and that's ignoring all the other possible memory issues from various 3rd party products that have nothing to do with BGLs).

 

I'm not saying this is the case, but for example suppose the wind data is far more dense (as in much more of it) at lower altitudes than it is at higher altitudes ... there is a possible source of VAS consumption.   Or what if your AI traffic product filters out aircraft within certain altitude range and when you get lower more AI aircraft get loaded including ground aircraft (not airborne) - more VAS is used.  What if some of your AI aircraft are actually pointing to a real flyable aircraft which could be a huge consumer of VAS if you assign flyable aircraft to AI aircraft.

 

Basically there are many possibilities for VAS consumption, not just the one I found with a single small BGL.

 

Cheers, Rob.

Hi David,

 

I dare you to reverse your route and now head back into EKCH with a 6.5 LOD 

 

Cheers,

 

Jerome

 

OK Done, I've included SS with the Clock so you can see the ET just in case you think this is not true!

Route 

MAG1K MAG UM736 BUREL M736 SOGMA UM748 ERNUD UM726 ROSOK T296 MONAK MONA1F

 

Ready to taxi

 

Gear up!

 

Close to final

 

Landing!... if you wonder why i have two blank screens that's because there on another screen and i was landing....No AT/AP

 

Taxi'ing

 

Complete shut down

 

Fire up GSX just to add more VAS

 

Bonus shot

 

No dings no nothing.  :smile:

 

Who's lol now Jerome?

 

 

Thanks Rob great work.

 

 

Thanks Rob great work.

 

Nice images ... looks fantastic!

 

Cheers, Rob.

HAHAHA, brilliant, well done David, thanks for that  :smile:

 

So are you saying that removing the cvxOresund_Terrain.bgl file made all the difference?

 

Your landing shot is usually about to where I get on 22L final when I get an OOM with the NGX.

 

So what's the secret, all AI off, no car traffic, water on lowest setting, texture res. at 1024 and autogen at sparse, most shadows off? I'd love to try and see if I can get a similar result, please share your settings for your return leg into EKCH.

 

Cheers,

 

Jerome

Yes it because Rob found the leak.

 

"The secret"!!!

You could not be more wrong.

AI =MY6 @20%, no cars water max

Go here all setting shown same setting for every flight including the above ofc

http://forum.avsim.net/topic/468421-well-impressed-with-the-777-after-vas-test-ss-of-settings/