LM found main cause of vegetation-related OOMs

[Noel 4,486]

 

 

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

 

Probably at this moment in time w/ common hardware/software configurations that is generally true, but I'm imagining in the 32-bit address space it will still be able to crowd that space no matter how optimized the engine is, at least it seems this way to me.  From jabloomf's comment it does seem like there must be room for more optimization, and maybe the 'more aggressive' unloading of veggie tiles things will improve in this regard.

[denali 74]

 

 

Probably at this moment in time w/ common hardware/software configurations that is generally true

 

This is the case for even bleeding edge hardware.  I used to do some coding, weather modeling related, which would push several CPUs to 100% in a parallel configuration.  Its just about the hardest thing you can do when it comes to threading and LM has their hands full of it.  The learning curve is very steep and every program is the master, they don't teach Parallel processing in skool.  The thing about bottlenecks is they really do work as bottlenecks, just a little bit of one, at the speeds multicore systems are today, means that a bottleneck becomes very very large very quickly, not, as you would think, smaller and easier to manage because of the added speed.  The faster it goes the messier it gets.  They have their hands full threading these multicore systems. 

What we used to do was have one defined path which ran for production, and another one which ran for testing, which had an even spread set of clock "counters" and measurements spread in dozens and dozens of places in the code, like every open and close of a thread or memory loop.   That way you actually watch individual threads for a few lines before others changed what they were doing (released) and hid problems.  You can track something like a 1k packet from proc to proc easier that way.  (A simulation of the simulation).

[denali 74]

Just another thought.  I would love to be on their team right now.  They are having so much fun, in the middle of all this "frustration".  Because they're doing work for passionate users.  Nothing better than that.

[Noel 4,486]

 

 

This is the case for even bleeding edge hardware.

 

Sure.  When I said, 'common software/hardware, I was talking about this context, right here:  simmers w/ some level of enthusiasm to warrant the bleeding edge stuff.   My point was that at some point the 32-bit address space IS the absolute limiting factor.  Your comment maybe was that currently this is not yet the case, and hopefully that's true, but I sense that truly is the unknown here, at least w/ P3D V2.x.  Maybe an Outerra or some other approach to 3D rendering might exploit the 32-bit address space significantly better than P3D v2 or XPlane 64.   I tell you though I'm OTW from O89 to P40 in NCA and it's freaking gorgeous!  Great weather rendering thru REX4 w/ E+ weather engine, in the lovely RA T Duke, and she's locked at 60 frames w/ fabulous image quality.   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.  

[denali 74]

 

 

My point was that at some point the 32-bit address space IS the absolute limiting factor

 

But not now.  The P3D team is investing it's time wisely on optimizing the 32bit code before moving to 64bit because the most gain will come out of it.  VRAM is what it is.  More is not physically possible now.  A dozen or so months from now it may be.  For the foreseeable hardware future, within the next dozen, maybe two dozen months, the free-up of bottlenecks, not RAM, is the greatest resource available.

[DocBird 79]

... The P3D team is investing it's time wisely on optimizing the 32bit code before moving to 64bit because the most gain will come out of it. ...

I am sorry, Denali, but I disagree!

 

I still think it would have been best to not bother with the old FSX code but to start a new 64bit sim from scratch!

 

I believe that all the hard work LM did and still do would have been better invested to set up a really up-to-date sim without all the legacy issues they have to deal with now. (Don't get me wrong: I like P3D2 since it is the best thing we have at the moment). I am no programmer, though, but from what I read a sim that would be started today would be completely different set up.

 

A smart combination of the best features from FSX and X-Plane (look at its water and lighting!), the nice artwork of some talented game developers for the look of it and hundreds of programmers from India, Vietnam or China to do the load of manual work would have been a smart move.

[xplanery 250]

 

 

I still think it would have been best to not bother with the old FSX code but to start a new 64bit sim from scratch!

 

So then we would have another sim like X plane 10 that would force FSX users to rebuy all the scenery & aircraft due to absolute lack of backward compatibility. 

 

X Plane offers that already, I don't see the point. Backward compatibility is a major strength for Prepar3d. 

[Simmertyp 0]

So then we would have another sim like X plane 10 that would force FSX users to rebuy all the scenery & aircraft due to absolute lack of backward compatibility. 

 

X Plane offers that already, I don't see the point. Backward compatibility is a major strength for Prepar3d. 

 

and at the sime time the major weakness...

 

this whole backward compatibility issue just holds back development.

[denali 74]

Having no users because there are no addons would hold back development too.  

[Guest]

Backward compatibility is a blessing and a curse at the same time and it will always stay that way.

[DocBird 79]

So then we would have another sim like X plane 10 that would force FSX users to rebuy all the scenery & aircraft due to absolute lack of backward compatibility. 

 

X Plane offers that already, I don't see the point. Backward compatibility is a major strength for Prepar3d.

Yes but also the major block of concrete around its neck!  

 

Having no users because there are no addons would hold back development too.

Well I think that after 8 years with FSX most users would be wiling to invest in the next generation of simulation. We would see the existing add-on developers jumping on the train but also new talents. Yes it would cost us time and money but we would eventually be up-to-date.

 

And depending on the technology maybe even a tool could be developed to convert older addons.

[geolpilot 88]

Great news indeed!

 

This news came in just as I was about to make my very detailed VAS/OOM test report available on these forums. At first I thought "Oh well, there goes weeks of work!"

 

But then the same refrains started comming up in this thread, that have been surfacing in many others, examples;

 

 

 

it would have been best to not bother with the old FSX code but to start a new 64bit sim from scratch!

 

 and

 

 

 

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

 

Others are sounding some "sensible" notes of caution;

 

 

 

I'm imagining in the 32-bit address space it will still be able to crowd that space no matter how optimized the engine is, at least it seems this way to me

 

 and

 

 

 

My point was that at some point the 32-bit address space IS the absolute limiting factor. Your comment maybe was that currently this is not yet the case, and hopefully that's true, but I sense that truly is the unknown here

 

All made me realise that my test report, and the articles I wrote to explain VAS and "efficient" use of VAS, the difference between building and vegetation autogen, and an important factor that gets owverlooked by many, the effect of Vector Landclass in controlling the amount of autogen (all linked to in that report), is still very current.

 

In this testing I also test the effect of ORBX trees, using FTXG Base textures, the difference between using pop free autogen and having it off, the important effect of location on the potentail for OOMs, and a few other things, so my report will still be of interest, even after this fix becomes available.

 

For those who really feel that the ESP engine is clunky, and memory management is really bad in P3D v2.1 please take the time to read my report and especially the linked article on Vector Landclass - How it Controls Autogen Density, Where Vector Landclass comes from, and Why Landclass Detail varies from one part of the world to another.

 

One of the main conclusions of my report is that addon Landclass can be a big help in saving one from OOMs (but not always ), which bodes well for products like ORBX's openLC (and by extension the use of addon sceneries like this do not cause OOM's per se).

 

Location and Flight Path play a significant role in determining if you will get into OOM territory, particularly at DENSE and VERY DENSE settings.

 

Now, the fix will relieve some of that pressure on VAS, but I have a hunch that when the fix is released, and users happily push those sliders way to the right again we are still going to see reports of OOMs, and others chiming in to say "Its your Setup; I am now fine!" Location, Location, Loaction is all I am prepared to say here!

 

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

 

The report is available  at

 

https://dl.dropboxusercontent.com/u/53775997/P3D2.1_VAS_TESTING_REPORT.zip

 

I have carefully virus-tested all the files, so you are safe!

 

Rob

[3-2-1-Now 126]

Er, how do Microsoft and FSX factor into this discussion of Lockheed-Martin and Prepar3D v2.1?  :wacko:

 

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

 

Best regards,

Robin.

[n4gix 4,947]

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

 

Best regards,

Robin.

Thank you for stating the obvious, Robin. However in the context of the post to which I posed this rhetorical question, it was indeed out of place in this thread...  :He He:

[Howellerman 104]

 

 

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

 

Will do, Rob - looks like quite a project!