So... limitations of your hardware being taken into account and performance being important. A choice by L-M to reduce the negative impact of cloud shadow rendering for clouds that are not visible is being described as a bug by users? Seriously?

 

Here is what a bug is: When software code does or does not do what is expected. Based on L-M statement(s), this code appears to be doing exactly what it was intended to do, thus it is not a bug. While you may not like their decision... I an willing to bet had they left it alone and your performance tanked because your system can't handle the rendering requirements... you would be even more bent out of shape.

Do you have to see the cloud that is casting the shadow when you go outside? No you don't, of course you don't. You see shadows of things you don't see all the time. It is called reality lol. So yeah, when you are flying along and you look to the side and shadows that are still in your line of vision disappear, that is a bug.

 

My system can handle anything. And I am not bent out of shape. Just asked a question, got an answer and provided some info to the answerer.  Sorry if that offended you.

 

 

 
My settings: http://www.robainscough.com/P3D_V2.php

 

Rob,

I noticed your resolution has changed from 2560x1600 to 3840x2160 ? Is that two monitors in portrait mode ?

 

I am currently running 2560x1600 on an HPZR30w, and am seriously considering multi-monitor setup for P3D.

 

 

I noticed your resolution has changed from 2560x1600 to 3840x2160 ? Is that two monitors in portrait mode ?

 

No, I've moved up to a single 4K monitor (49" Sony XBR) with a resolution of 3840 x 2160.  That's why I no longer record my flights at 1600p -- I don't have anything that can handle recording 2160p so I settle on 1080p for my videos.

 

Cheers, Rob.

The latest issue, especially in NYC area for me is now not so much a fps one.. i've tweaked it about as well is its going... as it is out of memory errors.. seems i cant go for a long period of time.. varies depending on aircraft.. faster to OOM with jets for instance..

 

I'm going to try turning down the AG sliders.. unsure if having excessive scenery addons checked out in the scenery.cfg could also lead to this issue or not.. i was under the impression it was mostly graphic settings.. my LOD is at 5.5 as well.

 

EDIT: double checking.. i guess too many scenery areas can contribute as well.. in my last test i basically unchecked the world outside of the USA (scenery config editor) and just left north america activated.. this is probably overkill.

 

I run with 4096 runways (and 2048 in the settings though).. i guess perhaps i should lower these to 1024  in REX 4 (there is no 2048 option).. what does everyone else tend to go with if using Rex 4 for runways/taxiways?

This is what I was referencing. I really noticed it while flying the Orbx Squamish scenery, probably because the shadows are easy to see on the mountain sides.

 

Ah ok, gotcha ... in the world of software development we call this a "by design" compromise ... so when you said "bug" I didn't really understand you.  You'll find many "by design" compromises in flight simulators regardless of platform ... take a look at Autogen Buildings for example.

 

Very simple 6 sided models repeated frequently ... not representative of what we see real world but done simply to work within the confines of computing performance.  Could autogen buildings be better and more varied and more detailed, absolutely they can.  But a "by design" decision was made to keep them very simple in order to keep performance reasonable.  

 

If you want a good hint of how more detailed and unique buildings will severely impact performance (and VAS), load up Drzewiecki Design New York City X.  Wonderfully detailed buildings but extremely difficult on performance and consumes considerable VAS.  Obviously we'd love to see that kind of detail across the globe but it would just be impracticable for today's hardware.  But fortunately flight simulators (P3D and XP10) continue to evolve and who knows, maybe over time these "by design" restrictions will be removed.

 

Cheers, Rob.

 

 

I run with 4096 runways (and 2048 in the settings though).. i guess perhaps i should lower these to 1024  in REX 4 (there is no 2048 option).. what does everyone else tend to go with if using Rex 4 for runways/taxiways?

 

1024 for me ... I gave up on 4096 and 2048 a long time ago (going back to my FSX days) ... just not enough of a visual difference to justify the VAS and performance difference that 2048 and 4096 induce.

 

Cheers, Rob.

In NYC, does one see CPU maxed & GPU maxed when these dismal frame rates are occurring?

 

 

load up Drzewiecki Design New York City X

 

I have that, and it is not a pleasant experience  :rolleyes: . But the Aerosoft NYC runs sooo well in FSX that I wish it did the same in P3D.

In NYC, does one see CPU maxed & GPU maxed when these dismal frame rates are occurring?

 

surprisingly my gpu doesnt max.. cpu is spread across cores.. I run  Drzewiecki Design NYCx.. its what i referenced with my fps numbers in the first post of this thread.. you have to disable the center section of NYC via the NY_low.bgl and kill the agn files to get even reasonable frames.. though they are still sluggish.. without killing the agn textures i hit the 22 fps or so in the initial pause screen then 13-15 fps close up.. with killing them i start at 28 fps then average a more decent 18 going towards the center.. sometimes 21 fps.. this with the fair weather theme (clouds).

 

At night i think i start with 23 fps and it goes downward, maybe 15 fps..

 

 

 

1024 for me ... I gave up on 4096 and 2048 a long time ago (going back to my FSX days) ... just not enough of a visual difference to justify the VAS and performance difference that 2048 and 4096 induce.

 

Cheers, Rob.

 

Ill start here with the VAS issue.. maybe drop from 2048 to 1024 see how long i can go in a slower plane (or shorter in a fast one).. as well as reduce the scenery area..  

 

Curious.. i wonder.. if Rex 4 is set to 4096 and P3d is set to 1024.. does it still suck up "4096" style resources.. i'd think the setting in P3D is all that matters but maybe not?

 

I just ran another NYCX test in a simple p92 eaglet.. i ran for about 3 minutes.. slow craft.. mind you still on 2048 and other higher mesh settings.. but i limited the area to basically the NE tristate region covering NYC.. turned off the entire other world.. and boom.. Computer has run out of available memory.. this was after a fresh load from the desktop.. strangely i've gone a lot longer in this area in the past without a fast memory error..

surprisingly my gpu doesnt max.. cpu is spread across cores.. I run  Drzewiecki Design NYCx.. its what i referenced with my fps numbers in the first post of this thread.. you have to disable the center section of NYC via the NY_low.bgl and kill the agn files to get even reasonable frames.. though they are still sluggish.. without killing the agn textures i hit the 22 fps or so in the initial pause screen then 13-15 fps close up.. with killing them i start at 28 fps then average a more decent 18 going towards the center.. sometimes 21 fps.. this with the fair weather theme (clouds).

 

At night i think i start with 23 fps and it goes downward, maybe 15 fps..

 

Ill start here with the VAS issue.. maybe drop from 2048 to 1024 see how long i can go in a slower plane (or shorter in a fast one).. as well as reduce the scenery area..  

 

Curious.. i wonder.. if Rex 4 is set to 4096 and P3d is set to 1024.. does it still suck up "4096" style resources.. i'd think the setting in P3D is all that matters but maybe not?

 

I just ran another NYCX test in a simple p92 eaglet.. i ran for about 3 minutes.. slow craft.. mind you still on 2048 and other higher mesh settings.. but i limited the area to basically the NE tristate region covering NYC.. turned off the entire other world.. and boom.. Computer has run out of available memory.. this was after a fresh load from the desktop.. strangely i've gone a lot longer in this area in the past without a fast memory error..

 

update: just ran another test with DDNYCX.. turned it to 1024.. after a mere 30 seconds i got an out of memory crash.. i had fsuipc monitoring vas in the title bar with the 024c code.. it last showed 1429672.. this is far from the limit .. something else is amiss with my case i think.  This wasnt the case a few days ago, so something is a miss.

 

I just also ran my taskkill.bat file that i created, which basically kills every task associated with prepar3d.exe and similar dll's after a crash or to clean things up.. seems that this has helped with a few fresh tests, but time will tell.  (update minutes later.. nope, still out of memory)  Again its odd.. the vas is not at its limits yet the pop up box appears (nor is there a beep from FSUIPC).. or so i think.. My next step will be to rule out DDNYCX by disabling it and trying the same with defaults, then again with aerosoft NYC.

 

I disabled DDNYCx.. same exact message box after 30 seconds.. it could be another NY state area addon causing a conflict maybe. (the test basically just lets it fly on its own.. which in the case of the way it was saved was an arch which takes it pretty close to the ground or just before impact then the error)..   Another test just done.. no NY State freeware/addons enabled.. the test succeeds each time, without a memory message box.. culprit found.. so far .. 

 

 

update: just ran another test with DDNYCX.

 

FYI -- DD NYCX is not listed at compatible with P3DV2 ... only P3DV1 ... according to DD's web site.

 

 

Curious.. i wonder.. if Rex 4 is set to 4096 and P3d is set to 1024.. does it still suck up "4096" style resources.. i'd think the setting in P3D is all that matters but maybe not?

 

I did limited testing on this, but my results indicated that if 4096 textures are there they will be loaded as 4096 texture regardless of the P3D setting.  I don't know if this is a bug or something unrelated when it comes to 3rd party texture files.  Same with aircraft textures.   As a result I've always tried to match 3rd party settings to what I want ... aka 1024.

 

Cheers, Rob.

 

 

 

 

1024 for me ... I gave up on 4096 and 2048 a long time ago (going back to my FSX days) ... just not enough of a visual difference to justify the VAS and performance difference that 2048 and 4096 induce.

 

Cheers, Rob.

 

 

When using FSDT,Flightbeam there is a huge difference with TML=1024 vs TML=2048 . At least on my system

 

Michael

 

 

you have to disable the center section of NYC via the NY_low.bgl and kill the agn files to get even reasonable frames..

 

 

Can you please advise on how to do this ?

No, I've moved up to a single 4K monitor (49" Sony XBR) with a resolution of 3840 x 2160.  That's why I no longer record my flights at 1600p -- I don't have anything that can handle recording 2160p so I settle on 1080p for my videos.

 

Cheers, Rob.

 

Really a side thread question, but Rob I'm curious.. when you record videos.. are you using fraps or maybe the P3D recorder (unsure if there is a way to export those recordings).. if fraps what setting do you use.. I'm assuming you change the display resolution 1920x1080p and then record?  Fsrecorder was nice because you could script out a recording (i believe its how it was) and then use different camera angles along the way.. But it doesn't work in P3D thus far.  I was switching to 1080p and using fraps myself in the past.

 

 

Really a side thread question, but Rob I'm curious.. when you record videos.. are you using fraps or maybe the P3D recorder (unsure if there is a way to export those recordings).. if fraps what setting do you use.. I'm assuming you change the display resolution 1920x1080p and then record?

 

I've stopped using FRAPS and use ShadowPlay exclusively now ... it's just easier on performance.  ShadowPlay output isn't as good as FRAPS as it seems to compress much more than FRAPS ... most noticeable at night and/or close gradients ... but it's a compromise I can live with.

 

I don't use FSRecorder (I never had much success with it even in FSX) ... I use P3D built in "Instant Replay" and then change views and record the replay.  P3D also has an extensive camera system that one can setup and play with to get that "perfect" shot ... but I don't use it much.  Or, I record a flight using the built in recorder ... I usually only do this route when I'm trying to exactly duplicate a flight and testing time frames and/or performance using various settings.

 

I don't put a lot of time into my videos (just don't have the time), but in some ways I think that is good, because it's more representative oh "what you see is what you get" and nothing is "adjusted".

 

Cheers, Rob.

I've stopped using FRAPS and use ShadowPlay exclusively now ... it's just easier on performance.  ShadowPlay output isn't as good as FRAPS as it seems to compress much more than FRAPS ... most noticeable at night and/or close gradients ... but it's a compromise I can live with.

 

I don't use FSRecorder (I never had much success with it even in FSX) ... I use P3D built in "Instant Replay" and then change views and record the replay.  P3D also has an extensive camera system that one can setup and play with to get that "perfect" shot ... but I don't use it much.  Or, I record a flight using the built in recorder ... I usually only do this route when I'm trying to exactly duplicate a flight and testing time frames and/or performance using various settings.

 

I don't put a lot of time into my videos (just don't have the time), but in some ways I think that is good, because it's more representative oh "what you see is what you get" and nothing is "adjusted".

 

Cheers, Rob.

 

Ah very nice thanks.. i hadnt realized the instant replay was even there, though perhaps the built in recorder could be useful if you need to do the recording later after closing the program.. I'm assuming you still need to shrink the resolution down to 1080p (1920x1080) to do the shadowplay recording though?  I'll give this a test later tonight..but so far i did find you need to check off the box that says "allow desktop capture" to recognize the p3d window for recording (so far).