My question is how come FS:SE can fly PMDG777 / 737 with many add-ons,  with out any OOM.

 

I think this is your post ? http://forum.avsim.net/topic/458521-the-most-intense-vasoom-testing-you-have-ever-seen-videos/?p=3142995  anyway, didn't take me long to find plenty of threads about OOMs in FSX-SE.

 

The answer is pretty simple FSX-SE:

 

1.  Doesn't have cloud shadows

2.  Doesn't have tessellation 

3.  Doesn't have HDR 

4.  Doesn't have volumetric fog

5.  Doesn't have some additional reflections 

6.  Doesn't have 3D water/waves

7.  Doesn't have several other shadow settings including distance settings

8.  LOD system is not the same

9.  Doesn't support DX11

 

A lot of features FSX-SE doesn't implement that helps it reduce it's VAS footprint.  But I think you'll find plenty of P3D users not having OOM issues with PMDG 777/737 with many add-ons under P3D.

 

Cheers, Rob.

Rob, ever thought of an avatar called, Solomon, like in King? Wise words indeed.

Rob,

Last December 2014 I experienced some OOM with FSX:SE. After 5 months LATER, in   recent two weeks, I began to test FSX:SE   and amazingly I found they are on right track for improvements.  

Lets hope if they can reduce the OOM, maybe they will solve other  problems too. 

 

I am   very thankful to small and  big Flight SIM developers and for their marvelous  gifts s of Airplanes, scenery and many addons  , to give me the  Dream of Flight  in my small room.

 

 

... Did not disable FTX EU:England, again will do ...

 

Rick,

 

I wanted to reply yesterday, but got distracted. I caught your mentioning of  ORBX EU England on page 2 of this thread and thought "That's it!" I would de-activate it and see ...

 

And just to make the point that it is perfectly possible to avoid OOMs in P3D, here's what I did on Monday:

 

EGLL - KDEN, B772, 10h32m

 

using the following:

 

P3D v2.5

PMDG 772

FSUIPC

ASN

FTX Global

FTX OpenLC EU

FTX Trees HD

GSX

EZ Camera

Aerosoft EGLL Mega Airport London Heathrow Xtended

Flightbeam KDEN

 

I pulled up at gate A37 with about 800k of VAS still available. My settings are more or less as Rob recommends with one curious difference/mistake. I normally keep TML at 1024, but after the flight I realised that the KDEN installler had changed it to 4096. It did tell me, but I forgot to revert the setting before starting the flight...

 

I have only bought P3D last week, but I am already in the process of dismantling my trusted FSX installation. Keep digging, you'll find the culprit sooner or later.

Your settings for LOD and autogen are rather high at EGLL and the 777 reload the airport and select it's lowest settings from the installer. Then turn autogen to NORMAL and LOD down ONE or TWO notches. Or, turn them to the left completely and report back the MOST important thing with EGLL is to use the UK2000 configuration tool and turn off everything and select the lowest settings. Turn off ORBX EU and if you have ORBX vector turn off all the secondary roads etc. I notice you have cloud shadows turned on also, worth checking just to test.

 

A week or two back I had forgotten that I'd left the Aerosoft night lighting enabled and at EGLL I couldn't even look round and got OOM within 30seconds on the ground in a default plane. I had escaped the wife for a little while and thought I'd go for a quick spin round and of course it all ended in ding dong OOM Llying in bed that night it suddenly dawned on me what had changed.

DarkstarF16

 

Is that LOD setting you recommend the same as 'Level of Detail Radius'?

 

Don't have ORBX Vector.

 

Will look into the rest of your recommendations later.

 

Thanks.

To all who made the suggestions, specially you, DarkstarF16, in post #50...................................................Wo-ho!

 

At last, following your tips, I actually managed to get up in the air and as I write am en route to EDFH. Touch wood, so far, no OOMs. Not certain if I'll get one into the flight.

 

I've sure learned a lot in this thread. Revelation.

 

Now, going to try and inject a bit of weather via ASN. Fingers crossed.

What surprises me is that people have reported OOMs by using FTX Global only and LM does not experience it...

 

Of coarse disabling bgl files, setting sliders to the left will help , but imho the question is : why is v2.5 suffering from many OOMs and v2.4 not..

I had to disable autogen buildings and trees completely icw resized airport and cloud textures to solve my OOM issue.

With v2.4 I did not need to do that.

 

The only issue I had with v2.4 is the weird colors from Night Environment..

That has been fixed in v2.5 and is looking way better.

A vanilla P3D might not give an OOM, but even LM shows P3D on their site with Orbx and Palm Spring addons.

 

LM has helpeld the US Airforce with a 3 screen Multi-Function Training Aid.

So 3 screens...

I am curious if it is completely without addons.

 

http://www.prepar3d.com/case-studies/multi-function-training-aid/

Now, now, Gerard, that is a very interesting introspective.

 

v2.4 better at handling OOMs than v 2.5. And v2.5 with Orbx on their site too, yet as seen here in this thread, I've had to turn FTX EU; England off to stop OOMs.

Rick, on my pc v2.5 "feels" smoother than v2.4.

 

Regarding VAS : when having loaded the same scenery I have about 300-400 mb more free VAS with v2.5 than with v2.4.

However, when flying free VAS is dropping quicker in v2.5 than in v2.4, especially at approach...

As far as I can see it that is always when 3rd party objects are near.

 

Like I wrote, I have solved my OOM issues, but at a sacrifice I did not had to do with v 2.4.

But Adam wrote that they are working on it, so we"ll have to wait...

 

It might be just a week or it might even be months.

I only hope that eventually v2 will be a good flightsim before they completely switch over to v3...

Gerard

 

You have more or less stated the aspirations of most of us P3D users, that we will one day be able to use this platform within reason, efficiently, not having to make compromises and adjustments for every different scenario. That would ebb away the joy of simming,

LOL...

Okay, with a bit of tweaking.....

 

This morning I was doing a sightseeing flight above the Netherlands and I set my cloud density back to ultra, because there is an overcast here.

Compared to high the difference at startup is about 100 mb, but when flying free VAS dropped in 20 min from 1.7 to 873...

 

Just 1 airport active and my photoscenery for the Netherlands.

No 3d objects...

 

With clouds at high it would be at leadt 250 mb higher...

But then there would be no full overcast...

The start of the issue is the way FSX / P3D is built in C++.

Objects that stay in the memory and use VAS , even if you have passed them .

 

I am not a programmer but if all objects could be released from the VAS that would solve a lot.

Perhaps this is not possible.

The only way now is Saving the flight, shut down Fs, restart and load the Saved Flight.

 

Unfortunately that doesn't work for me as I have a real size home cockpit.

Reload Scenery does not help either ( command from the menu )

 

Maybe Vic or Rob can tell more about that.

Maybe Vic or Rob can tell more about that

 

It is more complicated than that ... I did provide a rather long blurb about resource allocation/release about a year or so ago.  To start you'll need to read about what a Quadtree is:  http://en.wikipedia.org/wiki/Quadtree.  FSX, P3D, XP10, Outerra all use some form of a quadtree design because it "fits" the global (world) type simulations (but by NO means limited to).

 

You can read more about FSX quadtree implementation here: https://www.microsoft.com/Products/Games/FSInsider/developers/Pages/GlobalTerrain.aspx

 

Some key items in the second link that I'll quote:

 

 

Subdividing the Surface of the Earth

To help organize and manage the terrain data at run time, we subdivide the surface of the Earth into cells organized into a quad tree.  There are several schools of thought concerning how best to do this.  One of the simplest is to subdivide the globe along geographic lines of latitude and longitude.  However, because the lines of longitude converge at the poles, the scale of the cells varies with latitude.  Polyhedral subdivisions of the globe can reduce the scale variation, but at the cost of added complexity [2, 3, 4]. 

 

   Figure 2: Geographic subdivisions of the globe Figure 3: Polyhedral [6] subdivisions of the globe

 

The biggest disadvantage of polyhedral subdivision from our perspective is that it's simply too difficult for content producers to author tiling textures that fit the often triangular or parallelogram shaped cells.  The geographic subdivision method, in spite of the convergence issues at the poles, simply wins on the basis of simplicity and familiarity.  Besides, while Flight Simulator allows trans-polar flight, most of the action still occurs at the middle latitudes where the majority of the world's population is concentrated.

To minimize scale distortion where most of our customers live and fly, we designed our quad tree so the ratio of north-south to east-west extent of the cells is nearly 1:1 at +/- 45 degrees of latitude.  This was done by designating six root cells, three north of the equator and three south of it.  Each root cell covers 90 degrees of latitude and 120 degrees of longitude.

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.  This type of implicit quad tree design is sometimes called a linear quad tree [13].

 

 

Regarding Threads, Fibers, and Multi-core Architectures

Many of the tasks performed by the terrain engine, including the ones described in this paper, cannot be started and run to completion in the interval between consecutive rendered frames.

Some of them would take several seconds to run even if 100% of the processor time was devoted to them.  What's the best way to execute these tasks without negatively impacting the frame rate or its stability?

One possible solution is to run them on threads separate from the main render loop.  In practice, however, threads alone may not be the best solution.  The main reason is because the terrain engine's tasks are processor intensive and they can easily starve the game's main loop of processing time.  Worse yet, the terrain tasks come and go intermittently which would cause the frame rate to fluctuate.

In theory, lowering the priority of the terrain threads should prevent the main game thread from being starved.  However, the game thread is also pretty busy so that would increase the risk of starving the lower priority terrain threads.

A better solution, based on our experience, is to run most of the terrain engine tasks on Win32 fibers.  Fibers are similar to threads in that they each have their own context (i.e. register state and call stack).  However, the scheduling of fibers is entirely up to the application using them.

With fibers, Flight Simulator can schedule the terrain tasks to run in the interval between iterations of the main game loop and not during rendering or other time critical operations.

Fibers do have their down side, however.  Flight Simulator's fiber scheduler is cooperative, which means the fiber tasks must periodically call back into the scheduler to see if it's time to yield.

While this takes some getting used to when writing code, it does simplify the job of synchronizing data between fibers and the main game loop because all of the possible points of preemption are known.

Recognizing the increased availability of dual-core processors, we plan to execute some fibers in a single thread on the second core.  Fiber tasks that exchange data only with other fibers on the same core can still lightweight synchronization, but any data exchange with the main game loop or other fibers running on the primary core must be fully synchronized obviously.

 

These two links will give a MUCH better understanding of how FSX/P3D work.  This is why I sorta have a chuckle whenever anyone claims it's old crappy code ... quadtree is used in so many simulations/games including new releases and will continue to be used in the future.

 

 

 

but if all objects could be released from the VAS that would solve a lot.

 

With the above pre-cursor, we can now start to get to answer your actual question ... the objects don't always line themselves up in the Quadtree ... meaning a branch of the tree a few levels down has the required object that needs to be rendered, but in order to get it you have keep several other structures (objects or collection of objects) alive (in memory) as you can't just orphan the entire structure even if most of it is not needed to render the scene.

 

In the perfect (for LM) P3D no add-on world this works well, but when you start adding 3rd party the quad tree starts to look more like a giant octopus with tentacles far and wide ... the quad tree gets a lot bigger as finding resources to build the scene increases.  So even though the objects you no longer need to "see" they occupy a tentacle to get to an object you do need to see (in the render frame) so that tentacle stays alive.

 

Quad tree is resource hungry, but it's also the fastest way to simulate a virtual wold with this much complexity.  

 

Cheers, Rob.