I use MSAA 4x to get decent AA in P3DV2.x and w/o clouds, or with lower density clouds, all's well performance-wise.   Load up even medium density clouds near the airplane, 2048x2048 textures for REX HD textures, and here's what happens:

 

MSAA=none:  FPS 48

MSAA=4x:      FPS 28

MSAA=8x:      FPS 18

 

Since clouds are nebulous amorphous structures there seems to be way less to zero reason to have AA effects imparted on cloud textures, but maybe I'm missing something key.  If not, why the heck isn't there a solution to this?  The answer must be that it's cooked into texture structures that P3D has to use for clouds and everything else, yes?  One would hope programmers can flag certain files to NOT respond to AA messages.

 

Rob? You talked about this years ago, but yet here it remains.  Tim Fuchs?  

 

I find it quite disappointing that at this point in time this is still happening.  Up to P3D 2.4, and this remains such that the lovely flight that started at KCIC a few moments ago dropped down into to a stuttering frame rate of 22 shortly after TO and into some dense clouds.  Turn off MSAA--up to the low 40's.   I had cloud shadows disabled too!

 

If these issues are baked into P3D 2.x, I hope to heck LM is starting all over w/ modern programming design.  They certainly have an excellent template to start from.

totally agre with you. However I believe using DSR can help a lot on this performance hit by cloud AA.

^^ Yup - I use 2x DSR with 2x MSAA and have almost no hit in heavy overcast anymore. However, I run 1024 cloud textures (visual preference over the 2048 or 4096 ones).

^^ Yup - I use 2x DSR with 2x MSAA and have almost no hit in heavy overcast anymore. However, I run 1024 cloud textures (visual preference over the 2048 or 4096 ones).

Is this because you are getting higher resolution so need less AA?  I have tried the original method which could harm your display but had no trouble w/ the higher resolutions than my native 1920x1200.   How much perf impact from higher pixel count?  Maybe not much w/ a strong graphics card.  I wasn't having issues w/ cloud density perf impact then for whatever reason.

 

totally agre with you. However I believe using DSR can help a lot on this performance hit by cloud AA.

 

 

Thanks--I will check it out!

The guys at LM do know about the cloud AA issue - I can't for the life of me find the thread but from what I recall it was a technical issue with the rendering engine(?) that didn't allow you to just flag an object for it to have AA or not.

 

If anyone can find it I'd be interested to re-read it.

Since clouds are nebulous amorphous structures there seems to be way less to zero reason to have AA effects imparted on cloud textures

 

For the same reason I really wonder why people use HD textures for clouds.

As DylanM says try the lowest resolution cloud textures in REX (512/1024) and see if there is any improvement in FPS.

 

Considering your system Noel it's surprising MSAA levels are having such a big effect.

Do you have any supersampling or sparse grid AA going on somehow?

 

gb.

 

 

Rob? You talked about this years ago, but yet here it remains.

 

It's to do with the difference between DX9/DX10 and DX11 on how they can process AA and Microsoft's implementation.  In DX9/DX10 you can set the multi-sample flags to disabled and it'll work.  In DX11 this was tightened up and D3D11 API such that the render state setting (multi-sample disabled flag) will only operate on very specific features like (line anti-aliasing).  In order to do multi-sampled depth test if multi-sampled targets are bound regardless of state flag requires something like this:

 

- Resolve the pre-cloud scene to a standard color and depth target

- Bind standard targets for output

- render the clouds 

- Bind MS targets for output and standard targets for input

- Do a full screen quad render of the cloud color target back into the MS target

 

This would be a huge change on how the view renders ... such a change can be done, but in doing so has the potential to break a lot of compatibility and cause other issues for the enter view. 

 

Some of this is direct from Beau Hollis, some of it is my expansion.

 

My personal opinion (this is NOT LM's), I wouldn't make this type of change on a 32bit product and save something as major as this for a 64bit product ... but this is entirely my opinion and only my opinion.

 

Cheers, Rob.

Thanks.  I'm all for abandoning backwards compatibility and moving along w/ 64-bit and start designing for DX12 I guess, rethinking how multicore might be exploited better, perhaps moving bigger components out of the main thread, SLI, etc.  One always gets the sense, despite the amazing stuff you can do w/ P3D v2.x, that we're living underneath some old constraints.  Surely there is upside in a wholesale re-engineer of the simulator engine to get around some of these things.   This, of course is must my fantasy musing, but seems intuitively possible at some significant level.

You can disable it for clouds with the DX10 fixer in FSX. Why do I have the feeling that it is closely tied with the reason we now have annoying spinning clouds that everyone hates too...

 

EDIT: and if you follow other sims I have a feeling that this is why there cloud "puffs" in XPX  instead of hard cloud textures..