The logical "trick" is to always use the cloud-sizes EXACTLY the same as defined in P3D as the TEXTURE_MAX_LOAD=xxxx value.

(If one uses 2048 as max texture size but has a lot of 4096 textures - either scenery or anything else - those bitmaps need to be down-sampled by the video-card at runtime).

Soft-clouds are 512x512 in size so they need to be up-sampled if a higher max value is used.

 

Whereas up-sampling (in some special cases) usually does not cause any performance hit, down-sampling a lot of bitmaps will definitely have its affect, as larger bitmaps take video-memory and good amounts of cycles for the sampling process.

That's why it is the best to always stick with the same cloud sizes as the max texture size value being defined.

 

So basically I shouldn't have problems with soft clouds when my textures are set to 2048 in P3D and 1024 in REX since they are only 512? I also tried with 1024 in both programs (as P3D doesn't have the option for 512x512) and clouds are still a killer.

Just wondering if anyone has already had a chance to test 1080 in P3D environment.

 

Upgraded yesterday from a GTX 970 Strix: first flight with unchanged settings, (ASN live) moderate cloud coverage with a PMDG 737, I could see an average increase of +10 FPS, smooth, 45-55 FPS at touchdown in (stock) LIRF.

Pretty happy indeed, despite the fact that now  I can clearly hear GPU fan running (GPU temp during the session around 72-75 Celsius), and this wasn't the case with the former card, but hey. The card cools-down pretty rapidly when I close the session anynway, back to 40 Celsius in a couple of min.

 

Cheers,

 

 

Upgraded yesterday from a GTX 970 Strix: first flight with unchanged settings, (ASN live) moderate cloud coverage with a PMDG 737, I could see an average increase of +10 FPS, smooth, 45-55 FPS at touchdown in (stock) LIRF

 

at which res ?

at which res ?

 

Ciao Jerome,

 

2560x1440 @144Hz/Gsync, Vsync off, unlimited FPS with no external limiter.

 

Cheers,

Upgraded yesterday from a GTX 970 Strix: first flight with unchanged settings, (ASN live) moderate cloud coverage with a PMDG 737, I could see an average increase of +10 FPS, smooth, 45-55 FPS at touchdown in (stock) LIRF.

Pretty happy indeed, despite the fact that now  I can clearly hear GPU fan running (GPU temp during the session around 72-75 Celsius), and this wasn't the case with the former card, but hey. The card cools-down pretty rapidly when I close the session anynway, back to 40 Celsius in a couple of min.

 

Cheers,

 

Thanks Massimo. Do you run 2x or 4x SGSGAA with NVI? 

I'd suggest a water cooled system with temps pushing 75C.

Thanks Massimo. Do you run 2x or 4x SGSGAA with NVI? 

 

I'm afraid I don't use NVI anymore since I moved to P3D.

 

Cheers,

I'd suggest a water cooled system with temps pushing 75C.

That's drastic and expensive. You could also just ramp up the fan speed or wait for the driver update from Nvidia...

 

That custom water cool option set me back over $1,500. Just saying....

The logical "trick" is to always use the cloud-sizes EXACTLY the same as defined in P3D as the TEXTURE_MAX_LOAD=xxxx value.

(If one uses 2048 as max texture size but has a lot of 4096 textures - either scenery or anything else - those bitmaps need to be down-sampled by the video-card at runtime).

Soft-clouds are 512x512 in size so they need to be up-sampled if a higher max value is used.

 

Whereas up-sampling (in some special cases) usually does not cause any performance hit, down-sampling a lot of bitmaps will definitely have its affect, as larger bitmaps take video-memory and good amounts of cycles for the sampling process.

That's why it is the best to always stick with the same cloud sizes as the max texture size value being defined.

 

This is the first time I have heard of textures being automatically up-sampled.

Where did you get this information from?

 

gb.

I don't know what this means either?  BMPs don't have mipmaps and will just scale/stretch, they are not re-sampled up or down.  Default clouds are all BMPs (512 x 512 32bpp BGR).

 

Cheers, Rob.

I don't know what this means either?  BMPs don't have mipmaps and will just scale/stretch, they are not re-sampled up or down.  Default clouds are all BMPs (512 x 512 32bpp BGR).

 

Cheers, Rob.

BMP files can be mipmapped. Open cumulus01.bmp in Imagetool.exe from the P3d SDK and have a look.

Hi Jay,

 

There is no allocation/specification for mipmaps in BMP file format specification ... cumulus01.bmp does not follow the BMP specification, you can verify this by trying to open the file in Paint, or Photoshop or Visual Studio - they will all fail to load.  ImageTool and/or other custom tools can operate on this file which is not a true BMP (that's just the extension being used) ... BMP doesn't support DXT5 compression which is what ImageTool reports for the cumulus01.bmp.

 

As a test, you can rename Cumulus01.bmp to Cumulus01.dds - start P3D, and you'll see that P3D cumulus clouds will still look identical in those weather themes that have them present, also no errors in the Content*.logs.  So this tells me that P3D is not operating on this file as a standard BMP ... DDS does support mipmap and DXT compression.

 

As a control test to verify that Cumulus01.bmp and/or Cumulous02.bmp is being used in P3D weather theme, move the 2 files Cumulous01.bmp and Cumulous02.bmp to some other directory outside of P3D, then start P3D "Major Thunderstorms" and you'll see no cumulous clouds present.

 

Cheers, Rob.

This isn't anything new. It's not been possible to open FSX or P3d BMP filers with Photoshop or any other "standard" image app for a long time (years). That's why the FS SDKs supply imagetool.exe. Since the default files are named BMP, all the texture addons (FEX, REX TD 4 SC and now ASCA) have stuck with BMP rather than DDS.

 

 

This isn't anything new. It's not been possible to open FSX or P3d BMP filers with Photoshop or any other "standard" image app for a long time (years).

 

Sure you can, try it on these files, you should have no problem opening them because they are true BMP format.

 

cirrus_*.bmp (16 files)

cld*.bmp (20 files)

cumulonimbus*.bmp (8 files)

cumulus_*.bmp (8 files)

 

Any many many more ... I haven't tried them all, but I would say with my sampling the majority are standard BMP format.

 

What I didn't understand from Potroh was:

 

 

 

Soft-clouds are 512x512 in size so they need to be up-sampled if a higher max value is used.

 

I don't understand what is meant by "up-sampled"?  mipmaps at their lowest level are what they are i.e. 512 x 512, there is nothing higher than mip 1 (or 0 pending your base reference) ... so if you apply a 512 x 512 texture (lets assume square geometry) to a primitive square that is 1024 x 1024 the texture is scaled/stretched.  

 

So for example if I'm facing a 512 x 512 cloud texture and that texture moves closer to my viewpoint as it exceeds 512 x 512 it will start to look more and more pixelated as my actual resolution exceeds the textures size ... so 1 texture pixel is being display over 4x4 actual pixels, closer my view gets that becomes 1 texture pixel 8x8 actual pixels and so on and so on.

 

Cheers, Rob.

 

 

I don't understand what is meant by "up-sampled"? mipmaps at their lowest level are what they are i.e. 512 x 512, there is nothing higher than mip 1 (or 0 pending your base reference) ... so if you apply a 512 x 512 texture (lets assume square geometry) to a primitive square that is 1024 x 1024 the texture is scaled/stretched.

 

First the .dds is the Direct Draw Surface format that DirectX uses. The compressed .bmp is the exact same thing (regardless its header and if you can open them in different programs), they can be dxt-5. They are an inheritance from FS2004. You could make those dxt5 it was just FS9 that couldn't read them.

 

One can read a lot of stuff on how textures are 'pumped' to the video-card, and what the shaders do there by 'clamping' the UV coordinates of the texture. There are two methods, 'sampling' or 'loading' a texture, etc.

When there are no mipmaps (as in case of many "advanced" aircraft's external textures) no sampling is done and the full texture is loaded to the pipeline. (That is why un-mipmaped bitmaps - either aircraft or scenery related - can be a serious performance hog in FSX or P3D).

 

When the textures are rightly mipmaped, a 512x512 dxt5 texture takes roughly 0.35 MBs of video memory, whereas a 4096x4096 takes 21 MBs. The 21 MB texture is getting loaded to the board, even if finally either a mipmapped or down-sampled version is displayed (rendered). So filling up the video-memory with 4096 textures is very easy.

 

 Upsampling? Usually three up-sampling methods are used: Multi-scale joint bilateral upsampling, accelerated joint bilateral filter and Detail aware texture optimization, but there are more. Whenever you use AA, MSAA, SSAA or SGSAA, etc. textures are getting up-sampled in the pipeline...

 

If you restrict the max texture size defined in P3D, say you employ 1024 as max, but you still have some 4096 textures on the plane or scenery, they automatically get down-sampled to the max size, but ANY usage of the common anti-aliasing methods means up-sampling - at the same time.

 

Potroh