P3D "Out of Memory"

[Noel 4,507]

 

 

But even at my new AutoGen = Dense (building and vegetation) I can still trigger OOM if I use 3 cloud layers (at only 90mi draw distance) ... which is going to be a problem when/if FSGRW comes out for P3DV2.  Sadly, I have to keep reducing and reducing and reducing visual quality ... I'll admit, not a great situation.  But lets see if the patch address any of these VAS issues ... at least there is going to be a patch.

 

Rob,

I have cloud density at max and distance at 100m, and I'm using 2048 cloud textures, BUT, I'm using REX3's weather which isn't half bad at all but doesn't give you control over the number of layers.  I know I have some awesome looking weather even w/ that weather engine.  For me, it's not the number of objects that makes/breaks the visual quality improvements in V2, it's primarily the lighting effects.  I find Dense for autogen and Normal for vegetation is plenty realistic in fact much more than that can look almost too busy, and as I say I have yet to get an OOM.

[mgh 89]

 

 

Just data in a file, how the application deals with the data it reads is entirely up to the developer -- no need to change the data layout or structure of those files be it a 32bit or 64bit process and any legacy elements in the data can just be ignored.

 

That's possible  provided, as you say, there's no need to change the data layout or structure of those  files when they'll remain  as legacy versions. I'd like to see some improvement significant improvements. For example, these could include  flight dynamics that are limited by the constraints of the .air file.

[Guest]

For example, these could include  flight dynamics that are limited by the constraints of the .air file.

 

It would make more sense to separate out all the data in these files to their respective class object structures ... it seems that some files in FSX/P3D became a dumping ground and much was tossed into a single file.  Why reference a huge file looking for a data value that is burried in with a lot of other non-revelant data -- slower performance.  Files should be 'normalized' to match class object structures.

 

 

 

 I find Dense for autogen and Normal for vegetation is plenty realistic in fact much more than that can look almost too busy, and as I say I have yet to get an OOM.

 

Your display settings are lower than mine -- however, even with my reduction is settings (I keep reducing and reducing) I'm still hitting OOMs (and/or other bugs) whenever I load 3rd party aircraft (A2A C-172, QW BAe-146, Twin Otter Extended, B1900) -- I think it's time for me to fire up my XP10 64bit again, I've been neglecting it.  Maybe when LM release their patch, I'll return to P3DV2 and give it another round of testing ... but as of right now P3DV2 is just a little too rough around the edges even for me to endure.

[mgh 89]

. However,

It would make more sense to separate out all the data in these files to their respective class object structures ... it seems that some files in FSX/P3D became a dumping ground and much was tossed into a single file. Why reference a huge file looking for a data value that is burried in with a lot of other non-revelant data -- slower performance. Files should be 'normalized' to match class object structures.

 

There are a number of different ways to achieve that. However, they all involve breaking backwards compatibility - my original point.

[Manny 1,293]

Hey Rob,

 

Thank you for that autogen reduction to "Dense". That helped a lot with OOM issue.. I could not use P3Dv2 for more than 5 minutes...but when I changed it to Dense it seems reasonable. For photosceneries I have it doesn';t make much difference to autogen per se but it still helps with OOMs.

 

I am yet to see how bad the autogen is going to be in non photoscnery areas.

[Noel 4,507]

 

 

Your display settings are lower than mine -- however, even with my reduction is settings (I keep reducing and reducing) I'm still hitting OOMs (and/or other bugs) whenever I load 3rd party aircraft (A2A C-172, QW BAe-146, Twin Otter Extended, B1900) -- I think it's time for me to fire up my XP10 64bit again, I've been neglecting it.  Maybe when LM release their patch, I'll return to P3DV2 and give it another round of testing ... but as of right now P3DV2 is just a little too rough around the edges even for me to endure.

 

I don't blame you if OOMs are routine.  Your monitor resolution is higher so maybe that somehow contributes as well.   I installed the XP 64 demo and didn't stay with it long as it seemed worse graphically and performance wise than V2.   What's your take on that comparison?

[jabloomf1230 2,445]

I installed the XP 64 demo and didn't stay with it long as it seemed worse graphically and performance wise than V2.   What's your take on that comparison?

 

 

I know that your question wasn't directed at me, but I'd can share my experience with XP10. I bought the full version of XP10 before I even had P3d 1.x. What I found was that I could max out all the XP10 image quality settings on my present computer with no problem. On the other hand, my investment in FSX add-ons and the relative paucity of decent XP10 add-ons led me to use XP10 less and less to the point where when P3d2 was released, I decided to make a clean break. 

 

My thought is that if XP10 had comparable add-ons to FSX (and now P3d2) it would be not only a viable competitor, but it would be the premier flight sim app. But at some point, one has to realize that one's bank account is finite. I really can't see investing in XP10 add-ons, while also doing the same with P3d2.

 

I'm quite happy with P3d2. I don't get any CTDs or OOMs, but then I followed NickN's FSX "de-tuning" approach to setting up P3d2. This is when I discovered that the autogen setting is a real performance killer in P3d2. By pushing those two sliders back to dense or even normal, I can crank up the rest of the eye candy settings without any problems.

[Noel 4,507]

 

 

This is when I discovered that the autogen setting is a real performance killer in P3d2. By pushing those two sliders back to dense or even normal, I can crank up the rest of the eye candy settings without any problems.

 

Me too, no OOMs and I keep those two sliders a dense or normal, however when not in the most high-demand areas I still can set autogen to Very High or Extreme and have no OOMs, and that is w/ the add ons I'm using w/ V2 which are QW757, RA Turbine Duke & CS Super MD80 Pro.  If you're not using that plane and want to try something ultra easy on performance but with quite a robust systems implementation the Super MD80 is quite good.

 

One thing I do miss from FSX, besides FSPax and I'm hoping SImAIr might replace that, is very high quality AA that I enjoyed in FSX and absolutely don't have anymore in V2 ;o(  I can't see that this is being targeted either by LM in their comments about upcoming patches.   They have referred to 'working w/ nVidia' on this but other titles I understand solve AA within game, like V2 does already w/ FXAA which is so inferior to what is available in FSX DX9 I won't use it, but with many more AA options ala Assassin's Creed 4 (don't use it but was mentioned as an example of a title that has many more AA modes w/in game).  

 

I can afford to pick up XP 10 but I really don't like the lack of comprehensive solutions to high grade seasonal scenery & lack of airport buildings, and ATC.  Those areas will keep me away from XP 10 I think, but nice to know graphically it should run well so maybe when those areas are addressed I'll make the jump.

 

Thanks for your comments!

[Guest]

However, they all involve breaking backwards compatibility - my original point.

 

I'm not sure you are understanding my point ... the backwards compatibility is really a matter of does the development team want to spend the time and energy to provide a tool or tools that would convert existing legacy files into a more modern file structure?  Backwards compatibility can be retained IF the development team wants to build conversion tools ... where new values don't exist for legacy data, intelligent selection of defaults values are made.  The tool would be a "compatibility" compiler/converter ... it could convert legacy graphics file formats also, however if an Alpha channel is needed and there isn't one, that could result in odd visuals (just as we see in DX10 and FSX).

 

On the graphics file format front, there are tools to automatically convert those to another format also -- in fact nVidia provide a DLL in their SDK that will ... end results may not be perfect but they will be compatible.

 

BUT again, if there is a 32bit path and a 64bit path (single source code base) then it permits the migration of old to new over time.  If you look at most modern 3D games (and simulations) out on the market today, they all have both 32bit and 64bit executables, some 64bit exclusively.  If you want HDR and all the hi resolution textures they provide for those games, they are only available for the 64bit version ... even iRacing which is just an Auto racing simulation is 64bit as they ran into the same limits on 32bit (and that's just a racing simulation in a small restricted world of about 10 mile radius).

 

The key to implementing this compatibility process is development resources ... I have no idea the size of the development staff working on P3DV2 ... so far I've counted up 5 names/references (there could be more).

 

Typically what happens is there just aren't enough resources so the end results are:

 

1.  Break compatibility and force 3rd party to adjust and end users to wait for 3rd party support (those making money from being a content provider will eventually even if condemning the move privately or in public)

2.  Don't break compatibility and try to live within the restrictions (ultimately a dead end road, I don't think the FS community will tolerate another 8 years of this)

 

Does this sound familiar?

 

Personally I don't think it's a risk to break backwards compatibility (and I didn't think it was a risk 8 years ago) ... sure we'll loose some (users with huge investments in legacy and some 3rd party) but I'm certain those lost users/3rd party will likely come back once they see the advantages.  Most will endure because they love the hobby and realize it's the only way forward.  

 

I've seen many posts suggesting some "magical" optimization in code that is going to mysteriously free up VAS and make the product work in a 32bit address space ... that's simply unrealistic (confirmed by LM).  I'm certain there might be some room for improvement of VAS usage, but I'm almost 100% sure it wouldn't improve the situation by GBs but more like <100MB ... frankly, a 100MB optimization isn't going to make that much of a difference.

 

If I were a developer working on P3DV2, I think I'd rather tackle the job of converting to 64bit than trying to figure out how to further optimize VAS usage because the 64bit conversion process will be far less time consuming and easier.  I've done performance tuning process before, on a threaded environment and it is positively difficult!  The only real way to identity optimization problems is to run the executable standalone and NOT in a debug environment like Visual Studio because Visual Studio can and will introduce false results.  Heck, even the process of logging output to file in the stand alone executable can in itself produce unrealistic results because it affects the threads scheduling/timing and VAS.  Performance optimization/tuning is an EXTREMELY difficult road to go down and make reliable improvements for all situations -- far more difficult that converting to 64bit.

 

I'm pretty sure the lack of 64bit conversion isn't from it being too big a task to take on, it's more about concern for compatibility.  Hence, why I'd suggest 32bit and 64bit executables.  Like I've said, it's disappointing to see that there is NO official path for 64bit in LM's release schedule.

 

besides FSPax and I'm hoping SImAIr might replace that, is very high quality AA that I enjoyed in FSX and absolutely don't have anymore in V2

 

DX11 is very capable of high quality AA ... plenty of existing titles that prove that.  You can improve AA in P3DV2 via nVidia Inspect, but at an fps cost ... LM need to get nVidia to support their product at a driver level (I believe they are trying to make that happen).

 

 

I can afford to pick up XP 10 but I really don't like the lack of comprehensive solutions to high grade seasonal scenery & lack of airport buildings, and ATC.  Those areas will keep me away from XP 10 I think, but nice to know graphically it should run well so maybe when those areas are addressed I'll make the jump.

 

Agree, and yes it's expensive to keep multiple platforms going.  But, to be clear, I'm NOT making any jump, just getting back to XP10 64bit and will revisit P3DV2 after it's patched.

 

 

 

By pushing those two sliders back to dense or even normal, I can crank up the rest of the eye candy settings without any problems.

 

Yes, those other settings (shadows, textures sizes, etc.) are applied to objects, the more objects you have (Autogen density) the more work those other settings induce ... however, both are eye candy.  The problem is, 3rd party products use "eye candy" to sell product, without it, their product doesn't sell as well -- so their goals are very much eye candy focused ... so providing a platform that requires end user to dial down the eye candy is counter productive to what 3rd party are trying to achieve.  Sure I can turn down settings even more than I have already to avoid OOMs, and not use the flight planner, and have no weather, and don't use 3rd party airports, and ...  but I'm pretty sure that's not what a 3rd party vendor wants to see/hear from end users (almost certain Orbx don't want that situation).

 

Rob

[Syonco 13]

Does anyone know if SweetFX can be a contributing cause to the OOM problem? With all these sliders turned down to medium, the sim looks rather ugly. Would like to sprite things up abit.

[HiFlyer 9,363]

The thing about the 64bit option is..... Are this community's goals/needs fully compatible with Lm's goals? By that, I mean that even at default, P3D's graphics kick the butt of most commercial simulators.

 

All they really need is great flight models and accurate weather and they're probably pretty good to go.

 

We are the ones trying to also shoehorn Orbx in there (complete with peopleflow, automated baggage handlers and all sorts of other goodies) on top of PMDG quality planes.

 

But is all that really necessary for the business LM is trying to address?

[Guest]

But is all that really necessary for the business LM is trying to address?

 

I can't imagine any business (training or commercial) that would be willing to accept P3DV2 in it's "current state" ... the list of issues is pretty extensive and many have no work arounds other than "don't use that feature or don't do that" and some of the issues are pretty significant.  Imagine if you're the person in charge of installing P3DV2 into a training facility -- it'll be a nightmare!  All the things you'll have to support and tell "students or professionals" NOT to do, like loading a flight plan, keep clicking the main screen in case it loses focus, don't worry about the bouncing vehicles, ignore those clouds showing up in thick fog, non-functional click spots, ATC routing you in some other direction no where near your flight plan, weather issues, no DME sounds, other sound problems ... the list is pretty extensive even for a base install with no add-ons - see here: http://www.prepar3d.com/forum-5/?mingleforumaction=viewtopic&t=4373

 

BUT (and this is important), LM are working on fixes and have fixed many issues.  This product is going to take some time to get sorted out and it's no secret we're paying to be early testers/users (this isn't uncommon, it's done A LOT on Steam with various small development crews) -- I'm ok with that as I got my hands on the product and the more of us finding issues, means the more likely things are going to get fixed (within reason).  LM have been pretty responsive for the most part -- they have been evasive about 64bit support which is a little worrying (deja-vous) for me personally.

 

But with that said, I'm still very pleased to have enjoyed the opportunity to test/use it and will continue to do so.  There is no doubt in my mind it will progress to a point where it would meet the business LM are trying to address (if that is indeed accurate and not just a business justification for staying funded).

[simmerhead 885]

One has to wonder about what went on in the beta testing as many of the bugs are pretty obvious. From a $200 software I expect more. That said, it is clearly the way forward as XP10 doesn't appeal to the majority of simmers, myself included, and the chances of a new sim is up there with winning the lottery.

[HiFlyer 9,363]

The real question within my question is does LM really need 64bit to accomplish its current commercial goals (rather than ours)

 

Keeping in mind that even in its 32 bit incarnation X-plane apparently did well in the professional space.

 

It just occurs to me that 64bit might not be nearly as necessary for what LM wants to do in the short and medium term as it might be for the the way people here want to use the sim.

[captain420 3,099]

I am running P3D v2 with the following add-ons. OpusFSX, REX 4 Direct Textures, FTX Global, FTX Vector, FS Global Ultimate Mesh, FSUIPC, FSDT Airports, Aerosoft Airports and Payware Aircrafts. Running all this on 2560x1600, and it runs pretty well. I have had a few OOM's here and there but they are rare. I'm wondering if its because I'm mostly flying in the Hawaii area that I don't have as much OOM's as some of you guys who may fly in very dense areas such as NYC or LA? 

 

I get around 25-30 FPS most of the time, but at the airport it usually starts off around 11-20 FPS. I have my frames locked to 30fps.