OOM errors revisited

[Simmer2050 28]

gGSaiden

 

Thanks for explanation, I assume that means, the smaller the object contained in the texture file

the more likely you get  away with resize without much visual degradation impact  the sim.

 

Thanks for this very key explanation, cause I would have hit all my texture folders with  *.* 

 

Please recommended single tool for this if possible,  don't mind if its payware for being easier to use. But trying to avoid multi tool solution am no texture expert, I came to fly, and p3d now got me looking at textures like I never did before.

[Bobsk8 12,889]

No, Max upper vis is 80 miles,   Max cloud draw is 83 miles.   I want the clouds to be created behind the haze layer so I don't see them popping into existance.      Minimum vis is 0 (default), Max Surface is 40 miles,  Max Upper is 80.

 

Cloud draw is 83 miles period.    Here is what 3 layers of clouds with my settings looks like from the surface.   Looks pretty real to me without hogging VAS.

 

 

I have been using your cloud settings for a couple of weeks now and it looks great. 

[Kuragiman 227]

I have been using your cloud settings for a couple of weeks now and it looks great. 

 

Awesome!  Glad it is working for you!

[onebob 125]

Awesome!  Glad it is working for you!

same here, thanks for sharing.

 

bob

[diajohn 169]

I had very few OOM's with P3D on Windows 8.1.  Now that I have a clean install of Win 10 and P3D I have discovered that handling of VAS seems to be much improved.  During flight and even around busy airports like EGLL, I seldom even hit 4GB of usage with outrageous amounts of AI.

[GSalden 4,706]

I had very few OOM's with P3D on Windows 8.1. Now that I have a clean install of Win 10 and P3D I have discovered that handling of VAS seems to be much improved. During flight and even around busy airports like EGLL, I seldom even hit 4GB of usage with outrageous amounts of AI.

Very good to read you do not have VAS issues anymore.

However this has nothing to do with W10, as P3D still uses VAS in the same way....

It is the way how P3D has been programmed that is causing OOM errors.

[Fi5kuS 57]

I had very few OOM's with P3D on Windows 8.1.  Now that I have a clean install of Win 10 and P3D I have discovered that handling of VAS seems to be much improved.  During flight and even around busy airports like EGLL, I seldom even hit 4GB of usage with outrageous amounts of AI.

 

I think I clean install gives you the impression of both improved VAS and performance, simply because you haven't installed all add ons yet (my guess). 

[Bobsk8 12,889]

As I have said before I don't have an OOMs problem. If I did  however. and I did do a clean install, I am certain that each time I ran P3D after installing it, I would carefully monitor the VAS usage after I added each add on, one at a time. All I would have to do is determine where the jump in VAS occurs, when installing an add on, and then simply not use that add on. Simple...

[twharrell 38]

I compress and mip all FSDT airports and textures look just fine. I just don't do it to certain textures like night textures. The buildings look just fine to me. Honestly I can't tell a huge difference except I can now land the NGX at KLAX with cloudy weather and have VAS to spare when I get to the gate. Early FSDT airports not well optimized. The newer sceneries are a lot better.

[diajohn 169]

Very good to read you do not have VAS issues anymore.

However this has nothing to do with W10, as P3D still uses VAS in the same way....

It is the way how P3D has been programmed that is causing OOM errors.

I don't agree as I found the same with a Windows 10 upgrade.  My setup including software and addons is the same.  I believe Windows 10 is simply a more effective memory user.

[ErichB 3,651]

Update:  

 

Well I've implemented all suggestions gathered and am no longer having immediate OOM's.  777, UK2000 EGLL, moderate scenery settings, FTX Global, with all 3rd party addon airports other than EGLL disabled.  FSUIPC clocks 1.2 Gb remaining when at the gate.  I can probably depart and get to ToC before reloading the flight but good progress so far..

 

But now my EZDOK has stopped working.   Crashes at startup.  Honestly, ...

[downscc 1,327]

I just ran into an interesting OOM event.  PMDG 777 KORD-EDDF consistently draining VAS about 1 hr into flight over Canada in between YVV and YRI. There's very little to look at scenery-wise.

 

First trial had an OOM crash.  Second event same setup I caught the VAS rapidly disappearing and did a save/reload.  After the reload, I watched closely and VAS remaining just didn't look normal so I started looking around for what has changed.

 

I found that I had adjusted Texture Resolution and Mesh Resolution to 7cm and 5m respectfully following Orbx recommendations for regional scenery and I was overflying NCA and CRM on a B739 flight to/from KSFO.  It was okay in the PMDG 739 but it was killing the 777.  I reset to 15cm/10m, where I normally keep these settings and it made a really big difference.  Didn't happen instantly but after a few minutes the VAS remaining started looking normal again.(~1.2GB remaining).

 

Interesting.

[G-YMML1 591]

Thanks Dan,

 

My texres and meshres are both at extreme right. Perhaps I would need to move it slightly to the left. 

[isaiah 1]

I just upgraded to WIN10. Yesterday I flew BHX-SPC (UK2000 and Aerosoft) and got an OOM on final. Today I did the same flight over after upgrading. No fresh install of Win nor Prepar3d and I got a new sound while entering the STAR. It was the sound of OOM. I saved my approach and continued and the sound stopped. I actually finished the flight..... I have no tweaks in my cfg anymore and not limited my frames and it somehow worked this time.... I still need to fine tune it but it looks like WIN does manage memory more efficient, or is it psychological???

[downscc 1,327]

 

 

I still need to fine tune it but it looks like WIN does manage memory more efficient, or is it psychological???

 

Placebo effect.  There's a lot going on under the hood with memory managment and the OS does have a role BUT it's up to the executable to dispose of stuff no longer required, the OS cannot be the judge of what needs thrown away and what to keep.  Microsoft just didn't put a priority on it and by the time 64b caught on mainstream they didn't have the resources to go back and fix it.