But not now.  

 

I know Denali, it's what I just said...

 

Backward compatibility is a major strength for Prepar3d. 

 

On the other hand we continually hear the admonishments from folks responding to those who bemoan problems w/ P3D V2.x that they are using add ons aren't really fully 'P3D V2.x ready', therefore the implication is these add ons should not really be considered to be compatible.   But you're right, even w/ this there is still a lot of compatibility.

 

Please take the time to read my report and articles (over a few beers!)

 

In my experience w/ the RA T Duke, QW757, Super MD80, there is a big variance in how these eat up VAS, so they at directly appear to have little to do w/ land class per se.  Did you testing look at various aircraft?  The QW757 is by far the biggest beast on VAS, whereas the RA T Duke despite its complexity sans FMS is very VAS friendly.

 

I'm puzzled still by some issues that just don't make sense to me, despite folks trying to add their insights to this question re VAS.  To me, VAS should reach a steady state and stay there, and that this should be very closely tied to things like 3D objects, textures, and so forth, so that, and here it comes, if you load an exceedingly processing intensive scenario (PMDG bird for example, TO out of KJFK) by the time you get to altitude and you are now VAS is maximally saturated, as you fly AWAY from this dense area to areas of less complexity, VAS should really be going DOWN not up, relative to what was processed say 50 miles back, yet this is not what we see.    As jabloomr mentioned why should it be that autogen/vegetation, should be retained in VAS at all, once the plane is a certain distance away where that data cannot be resolved visually anyway?  I wonder how much more optimization is possible in this regard.

 

 

Did you testing look at various aircraft?

 

Hi Noel,

 

I specifically stuck to one aircraft knowing that, at the time I did my tests the "gauge" problem was an unknown avraible. I also wanted to stick to just testing scenery and autogen settings, without introducing the "aircraft variable, and this shows very clearly (one aircraft) that landclass does make a difference.

 

Landclass controls the amount of autogen - slider settings are "post-filters" on that (Landclass determines land texture sets - textures determine autogen (AGN annotations on textures)

 

Am now flying Carenado's C90 with the gauge fix on one on my report test flights, and am seeing the same VAS usage patterns I did in the Mooney Acclaim, related to Landclass variations en-route. 

 

Using settings I suggest in my report I am OOM free and looking like it will stay that way.

 

Rob

 

 

Using settings I suggest in my report I am OOM free and looking like it will stay that way.
 
Rob

 

Even w/ minimal testing I find it's quite easy to avoid OOM as long as I stay in the Duke, OR, if I play w/ the veggie sliders in mid flight.  I concluded a 467m flight yesterday in the Super MD80 by starting w/ veggies at Normal, autogen at Very High, then as VAS dove down to about .4Gb, I turned veggies to None, after which VAS slowly climbed all the say up to .8Gb at one point, at which point and this was in the last 60m or so of the flight so during arrival where it mattered to be able to see veggies again, I put the veggie slider back up to Normal and landed no problem.  Unfortunately this strategy didn't work well for the QW757 which couldn't even make it 250m or so despite putting veggies at none.  So it appears there is something happening w/ specific airplanes to cause VAS to trickle down, and that really to me sounds like a memory leak.

Geolpilot, Thanks for that, good read v informative K

Errrmmmm....... P3D is what was ESP, and ESP was simply FSX re-branded... The two are not that different.

 

Best regards,

Robin.

Since though LM rewrote the code to load in objects, hence why you don't have pop up autogen anymore, added FSX doesn't have this issue, unless you throw in a NGX or LRX into the mix, the problem was most likely LM's code.

 

 

Geolpilot, Thanks for that, good read v informative K

 

Thanks Kevin, Glad you found it a good read. happy Flying this weekend!

 

Rob

 

 

Even w/ minimal testing I find it's quite easy to avoid OOM as long as I stay in the Duke, OR, if I play w/ the veggie sliders in mid flight

 

Noel obviously you are free to read my test and other articles or not. The problems you are having is related to "veggie".  Changing density sliders all the while during the flight is not due to the plane "leaking memory". It all has to do with where you are flying (over what landclass), at various times in the flight.  Take off in the QW757 at a coastal airport, and head out to sea. Tell me how often you then have to adjust your sliders? Is the plane leaking memory at sea? If it is the plane, that "memory leak" should continue. Turn back to fly over land and see what happens as soom as you hit some landclass again! Easy to test

 

Same plane like the QW757, different results in different areas. All to do with the heavy load placed on VAS by veggies.

 

My final proof is that you will discover "one day" that you just have to turn veg autogen off totally to make it into SOME areas, or taking off in SOME areas to not have a few minutes flight into OOM. Then think Why now?

 

Planes like this have a "heavy memory" footprint at the outset (start of your flight), and veggie loads just make it worse as you go along

 

Rob

It's not really how much RAM that is the issue, it's how it is being managed - efficient use and release.

 

Ugh ... please enlighten us.  Assume of course you're a programmer, have programmed D3D applications and more specifically global simulations?

 

Sorry if I sound annoyed, probably because I am annoyed.  If you are going to make statements like this, then back them up.

 

Look at the LOD_RADIUS restriction already (6.5) ... are you honestly telling me/us/anyone that you think this is good?  You do understand why LM have it restricted?  LM's easiest solution is to further restrict those display sliders ... you are NEVER EVER going to be OOM free as long as P3DV2.x is 32bit.

 

I've managed my OOMs P3DV2.1 ... I manage my settings and live with it.  Every day that people continue to complain about OOM (the exact same way they did in FSX) is one less day LM could be spending on moving the platform to 64bit ... where it really needs to be.  

 

Can the ESP code be further optimized, sure it can, any code can be further optimized given time, money, and resources ... can optimization perform feats of magic, no ... maybe if you're lucky you get 100MB improvement, extreme case of optimization maybe 200MB ... this still isn't going to be enough to really make much of a difference.

 

The sad reality here is that I can return to this thread in a decade (yes full 20 years after ESP) and I will still see people complaining about OOM's in a 32bit address space just because they don't want to give up their legacy products ... they want to somehow force some magical code that can make a 32bit address space limit seem limitless.

 

So when exactly is the right time to move to 64bit ... when everyone has given up with flight simulations and having to deal with the same OOM issue, and 3rd party content providers have given up also because their hands are tied and can't improve quality because they'll just create OOMs.  Or will people just continue to call LM software engineers sloppy and inefficient?  Or maybe we should just tell all 3rd party content providers to stop improving and give us 16 x 16 textures 8 color (bring back the good old days).

 

Watch me, delete this comment, whatever ... it is what it is ... can you smell the frustration in me? 

 

Cheers, Rob.

It's beginning to look like the 32 bit-64 bit camps are going to be as polarized as many other different groups in flight simming.  If LM stays with 32 bit, it's going to require some workarounds to avoid OOMs if they can't optimize the code enough, and some people aren't going to mind these workarounds.  Others will hate them.  When LM goes to 64 bit, it's going to break backwards compatibility pretty much across the board, and some people aren't going to mind this while others will hate it.

 

Guys, we're going to have to learn to live with each other.  Evangelize all you want in whichever direction you want, but please don't fight the other camp as if they were mortal enemies. 

 

I predict that LM is going to optimize the 32 bit code as much as they can to retain backwards compatibility, but they probably won't ever eliminate ALL the workarounds or the occasional OOM.  At some point they'll switch over to 64 bit code.  Hopefully they'll maintain two versions, one 32 bit, the other 64 bit, and everyone can have what they want.

 

Hook

Same plane like the QW757, different results in different areas. All to do with the heavy load placed on VAS by veggies.

 

So by your logic, you are saying if I fly the EXACT same route AT THE SAME SPEED in the Duke versus the QW757, the outcome will be the same?  Interesting, I'll try it.  I frequently DO fly the same routes, so your interpretation of your experiments were not apparent to me anecdotally, i.e. since I do frequently fly the same routes in a few different planes.

 

 

I tell you the AA trick was absolute magic and seems to really jive well w/ 2.1.  Others here try to say this isn't true but a mega BS on that response--maybe for them it isn't working but here it's completely better and now on a par w/ FSX w/ DX9.  The swimming textures in the distance, and dizzying jaggies in specific runway thresholds & runway border lines, are no more.  

 

Hi Noel

 

I'm also having big problems with the swimming textures in the distance, and dizzying jaggies in specific runway thresholds & runway border lines in P3D V2.1. what is the AA trick that you refer to.

 

Cheers  John

 

 

So when exactly is the right time to move to 64bit

 

Rob, from Devon's depiction and tacit support of the Outerra engine and for the reasons he states it employs a fundamentally different approach to coding isn't it time to move beyond not only 32-bit but also this older model of coding for a 3D application exemplified in the ESP code?  In a heartbeat I would give up ALL of the backwards compatibility for this provided the key features were implemented.  Also, the developer of this next gen sim has to have the correct vision to put the whole package together 'just right'.   I see huge potential for this increasing market share for civil aviation simulation in a meaningful way, and of course it has the potential to have a very very long service life, just on the initial well-developed core and SDK kits.  I agree the 3PD community is constrained in being able to improve quality, so there comes a certain staleness constrained by the 32-bit address space.  And that of course stifles sales of 3rd party content and stales the growth of the platform big time.  What's sad is the is 100% contrived:  it's not that the hardware hasn't kept up.  It literally cost no more to run the 64-bit platform that encourages long term investment, other than the initial conversion cost.  In fact, I dare say the move to 64-bit will breath new life into the 3PD content market so that enthusiast users will struggle to at least get back to where they were by purchasing upgrades and new product designed to work in the 64-bit environment.  I see sales going up w/ a 64-bit engine, not users turning away due to lack of backward compatibility.

 

Others will hate them

 

Why?  Their 32bit product exists, it just will not be updated (once and if they start working on 64bit) ... this isn't new?  FSX continues and is enough for many.  LM's 32bit P3DV2.x will continue to be used and will be enough for many.  There is nothing that says one has to stop using their 32bit product because a 64bit products exists ... where is the logic behind that?  Why would there be camps?  Perhaps a camp of denial and refusing to understand or believe in the limits of 32bit address space and how the OS manages memory allocations/releases.

 

The issue isn't usage, or really 32bit vs. 64bit -- it's the statements being made about optimizations ... how can someone say something isn't optimized without:

 

1.  Having access to the source code

2.  Being a D3D programmer and programming experience is global simulations (the tree model)

3.  Having gone thru all the source code and understanding it

4.  Understanding how the OS works VAS 

 

Just assume LM developers and ESP developers are guilty of sloppy coding and poor optimization?  Sorta like me telling a brain surgeon that his surgical methods are not optimal.  my issue is the continue perception that some magical optimization exists that is going to make OOMs go away and have some huge impact on VAS reduction.  The only way OOMs are going to be prevented in a 32bit P3DV2.x is if LM apply further restrictions to the display settings ... making LOD_RADIUS 4.0 max instead of 6.5 max, make AutoGen vegetation "extreme" setting be the current "normal" value, etc. etc.  Is this what flight simmers want?

 

Cheers, Rob.

Hi Noel

 

I'm also having big problems with the swimming textures in the distance, and dizzying jaggies in specific runway thresholds & runway border lines in P3D V2.1. what is the AA trick that you refer to.

 

Cheers  John

Hello John,

 

Here was my original post that initially got naysaying, then as people continued trying discovered there is merit to it.  Since I made the post I've discovered the best of all combinations I've tried, and by best I mean best AA + best water + best performance, was the following:

 

In-Sim:

• AF: 16x
• FXAA: Off
• MSAA: 4x (can use 8x w/ small hit)
• Frame Rate:  UNLIMITED
• VSYNC:  ON (I have a 60Mhz display)

nV Inspector:

• AA Compatibility DX1x:  Bioshock profile
• AA Mode:  Override any application setting
• AA Setting: 8xS   (this is not the best for runway lines compared to SUPERVCAA 64x_4x, but it's much better for REX4 water using the DX11 textures)
• AA Transparency Supersampling:  4x Supersampling
• Anisotropic Filtering:  Application-Controlled
• Texture Filtering-Neg LOD Bias:  Allowed

Good luck--what really amazes me most is that the distance swimming textures has virtually completely disappeared, and of course runway lines/thresholds are vastly improved.  I'm amazed there isn't more consensus from others on this.  AA could be improved as I mentioned above, but it's quite decent now.  I can get SUPERVCAA on but somewhat frequently when an initial flight loads it will be a black screen, though the AA is superior than w/ 8xS.  With 8xS I never get the black screen issue.

 

 

Why would there be camps? Perhaps a camp of denial and refusing to understand or believe in the limits of 32bit address space and how the OS manages memory allocations/releases.

 

I rest my case.

 

I am not your enemy, Rob, and you aren't mine, even though we are seeking different goals. 

 

Hook

So by your logic, you are saying if I fly the EXACT same route AT THE SAME SPEED in the Duke versus the QW757, the outcome will be the same?  Interesting, I'll try it.

 

Nope that is not what I am saying.

 

If you fly that same route at the same speed in the Duke vs the QW757 you will get the same "VAS usage pattern"; which you would only see if you logged VAS-remaining to a file during your flights (FSUIPC), and plotted the curves  as I have done in my report.

 

The VAS-usage pattern is a function of changing scenery, not of airplane model (major changes in VAS-remaining on the plotted log-curve correlate 100% with noticeable changes in scenery around you).

 

Now the QW756 I would assume, has a bigger memory footprint than the Duke. So the two VAS curves, although the same shape, will be offset from each other, the QW757 curve to the down-side (more VAS is consumed buy the plane model itself). That could just take you into OOM territory with the QW757, but not with the Duke!

 

So the outcome may NOT be the same!

 

Rob