Suggestion to E.D. and 3rd parties devs - size and formats of DDS

[LucShep]

Hello,

I've been intrigued by the absurd consumption of VRAM even if at 1080P screen resolution (over 8GB of VRAM even on Free Flight missions!).
I took a look at the textures on, well, pretty much everything....
I see there's a common pattern where, I guess for the sake of the ultimate precision, many textures are being used with the kind of detail that the end user won't really notice at all, therefore very important (and necessary) resources are being wasted.

For example...

Bump maps (*NORM*.DDS) and Specular maps (*ROUGHMET*.DDS) at 4096 pixels and even 8142 pixels base size! ......why?
Even worse, saved in DXT5 format when there are no transparencies whatsoever(?!?). 

My suggestion:

• If you save these textures at half size, you get four times less file size (1/4 !!) and the difference in image when in-game is pretty much none, zero.
• If you then save those that do not use transparency as DXT1 (no alpha), then the saving in file size is another half (1/2) over that!

....Which means that we're now at eight times less (1/8) final size in texture!

This can also be applied for (inside) cockpit textures. On top of what is suggested, and for those that are bigger, if so anal about details, then just set the smallest MipMap at, say, 512 or even 1024 pixels to force a determined minimum of detail.

Also, missiles, vehicles, so many other objects that will hardly, if rarely, be at close view, are also making use of 4096 pixels for the Diffuse (main texture), Bump (Norm) and Specular (Roughmet) .DDS textures on every component.

.......why?? 

These can be safely downsized to 1/2 size, and even 1/4 size for Bump and Specular tex.

Cubemaps, they too can suffer from same issue - can be half sized and saved with no alpha (again, 1/8, or 8 times smaller), ingame there's no visual difference.

Lastly, and just as troublesome, 32 bit textures(?!?). This is completely unrequired and really problematic with so many textures loaded... 
8 bit textures should be the norm, always, no exceptions. It's a gargantuan difference for size of textures, with zero difference for in-game image quality. 
(EDIT: see here)

In the end it, such changes will save huge ammounts of precious VRAM resources, with no real impact visually in-game. 
Honestly, I dare any user to notice the visual differences if they're not told (yes, I already tested in my own installation).
It's a very big difference in performance impact when you put all the hundreds (thousands?) of textures in the game, again, with no real impact visually. 

Not only you decrease the loading times, disc space and its usage, and smaller downloads size/time, but most of all you substancially decrease the VRAM usage on the GPU.
The difference between a stuttering mess and a far smoother experience.
Precious resources are saved, and in more than one front. Everybody wins (IMO).

Anyway, just some criticism with suggestions for solution, because I think it's better to present it as such.
Keep up the good work please.

Cheers!

Edited October 19, 2023 by LucShep

[reece146]

I wonder as an experiment one could walk the directory tree of all these files with ImageMagick and convert in place, see what kind of difference it makes in practice... Not sure if it'll handle DDS files.

[Taz1004]

I wonder as an experiment one could walk the directory tree of all these files with ImageMagick and convert in place, see what kind of difference it makes in practice... Not sure if it'll handle DDS files.

 

You can't do that to all textures as many of them are compiled as onlay array and has to be specific size defined by code.

 

And I agree with LucShep. Saving VRAM will not always result in more fps. VRAM will not make the GPU core or CPU run faster. But it will allow for more graphic options. More frame buffer headroom for MSAA or higher texture setting perhaps.

 

I've been working on trees for last few weeks so obviously that'll be my example. On default Caucasus map, single tree has...

• 1024 x 1024 branch texture
  
• 1024 x 1024 branch normal texture
  
• 512 x 2048 bark texture
  
• 512 x 2048 bark normal texture.
  
• 1024 x 1024 billboard texture.
  
• 1024 x 1024 billboard normal texture.
  

 

When the whole town ground texture that tree is sitting on is only 1024 x 1024.

And there are 9 tree types so multiply above by 9 just for trees.

Edited August 20, 2020 by Taz1004

[BaD CrC]

Also, missiles, vehicles, and many other objects that will hardly, if rarely, be at close view, are also making use of 4096 pixels for the Diffuse (main texture), Bump (Norm) and Specular (Roughmet) .DDS textures on every component.

 

Sounds all like pretty interesting and valid suggestions LucShep. Now regarding the ground objects, remember that not every DCS pilot is waging virtual wars comfortably sitting at 10000 ft, head down playing with their fancy displays and dropping GPS guided bombs at a very safe distance. Helicopter pilots are getting really close (sometimes too close) to those vehicles and a nice definition of the textures is appreciated (granted, maybe not as much as 4096x4096) to avoid friendly fire.

[LucShep]

Vehicles at near-ground altitute are mentioned.... I also fly helicopters here and then and, believe me, you won't notice any difference with diffuse at 2048px and bump + spec at 1024px on the vehicles.

You'd need to be "on" the vehicle to notice where the differences are (and even then I suspect some wouldn't notice).

 

Seriously, I love al the details as the next fellow simmer (nerdgazms gallore), but when it gets to a point of obvious diminishing returns (at HUGE cost of VRAM and RAM), and a GPU with 8GB VRAM is having dedicated memory nearly maxxed at 1080P (unheard in any other sim/game in "stock" state, in my experience), then I think it's time to pedal back things, no?

 

Imagine that you can cut in 1/2, if not 1/4 and even 1/8 of file size in, say, 2/3 of the total textures of DCS, by doing it only on the BUMP (Norm) and SPEC (Roughmet) .DDS textures, and by correcting the Diffuse textures that are wrongly making use of transparency formats when themselves have none at all (there's so many in such state!)....
 

...I think you can guess that, yes, we're talking various Gigabytes in size, and increasing further and further the more modules and terrains you have.

Again, a much lighter installation on disc size, faster loading times, more resources available on GPU and RAM, and less chance for stuttering issues to occur as well.

These are tremendous benefits considering there's close to none loss of image quality (if at all). Major benefits also for online, where things usually get even worse.

 

E.D would also save on (now smaller) file sizes when hosting and their respective download times.

Not to mention less issues at hand, trying to deal with continuous reports on "bad optimization" even for those owning "NASA-like" computers (who'd now get their GPUs a little more relaxed).

My guess is that, with batch resizing + conversion, this can be done within days (very tedious job, but worth it).

 

....You'd "kill two birds with one stone".

 

Edited August 8, 2021 by LucShep
....spelling(?)

[Taz1004]

Also want to point out that reducing 256 x 256 texture to 128 x 128 may have minimal benefit. But difference between 4096 x 4096 and 2048 x 2048 is HUGE. In terms of size.

[LucShep]

Also want to point out that reducing 256 x 256 texture to 128 x 128 may have minimal benefit. But difference between 4096 x 4096 and 2048 x 2048 is HUGE. In terms of size.

 

Yep!

 

For instances, I was looking at one aircraft that has bump (NRM) and specular (Roughmet) textures with no alpha-channel saved at 4096 px, DXT5 format.

Each of these textures is 21.846 KB (22 MB) in file size.

If 1/2 sized to 2048 px, and at DXT1 format, then it's 2.731 KB (2 MB)... that's a LOT smaller then.

You'd notice no difference in image once in-game, but have all benefits as result to the lighter format.

 

This is an issue that can be multiplied just for one aircraft (each has dozens and dozens of such textures), and there's dozens and dozens of other aircrafts, and same applies for vehicles, and boats, and etc, etc, etc.

Same is happening in the Caucasus map.

A waste of resources.

 

...and I only have a few modules and that one map. :noexpression:

Edited August 20, 2020 by LucShep

[twistking]

bump

[Mars Exulte]

In general I agree with much of the sentiment here, but you guys are forgetting one very important factor :

 

GPU VRAM is likely to double or triple over the next gen or two, which will largely resolve this issue. No, that doesn't do any good for folks running older hardware right now, but in 5 years, when even low end cards are likely to have 10+ gb it will be a non-issue.

 

While some of it seems a bit odd (the trees) it is mostly future proofing (aren't people already griping about ''dated'' models that are 150k polys and near photorealistic?). Furthermore, the plan for some time has been to greatly expand Combined Arms, although we have yet to see any fruit from that, the ground game will eventually be built on.

[Dragon1-1]

That you have 16GB of RAM is no reason to waste every single bit of it. :) Yes, in a few years it might not be such a problem, and for high end systems it isn't now, but some things like normal maps and such do not need to be that big.

 

I'd suggest keeping the "master" high-res files stored somewhere, should the need for them arrive, but for now, there's some real easy optimization to be done. And, unlike most others, it'd be trivial to implement.

[stormrider]

That you have 16GB of RAM is no reason to waste every single bit of it. :) Yes, in a few years it might not be such a problem, and for high end systems it isn't now, but some things like normal maps and such do not need to be that big.

 

 

Exactly.

[Taz1004]

Even in the future, any additional VRAM should be used for other things. Frame buffer for higher AA. Higher PD. Reflections. Rain and weather effects. Larger LOD sphere. Better shadows. More and better smoke and explosions. Ambient Occlusion... Rather than filling up the inefficiencies.

 

And the things we're asking for doesn't require huge amount of work. Opening and saving takes 5 minutes. Actually, it can even be automated.

Edited October 18, 2020 by Taz1004

[Fri13]

This topic is more about optimization and having "master files" for the future, than it is about the visual quality or flight experience.

 

As those data values are proportionally way over the required levels.

 

Does the DCS perform any kind automatic scaling down based the settings? As that is what I would really understand that one stores highest possible quality and then the client will itself convert them to fitting size by the game settings?

[Taz1004]

Does the DCS perform any kind automatic scaling down based the settings? As that is what I would really understand that one stores highest possible quality and then the client will itself convert them to fitting size by the game settings?

 

Your assumption is correct. DirectX will automatically adjust Mip level. Basically downscaling information. But the full file will be loaded into VRAM and if not enough, will be stored in swap files.

 

If you're flying FA-18 in multiplayer and someone joins with F-14, 5.7GB of his textures will be loaded on your system. Another 3.1GB if F-16 joins. They will be swapping but full texture versions will be loaded if they get in range or if you spectate. As far as I can tell, there is no lighter version of textures for AI and other players.

[RealDCSpilot]

Just to add more info to the topic: https://forums.eagle.ru/showpost.php?p=4528333&postcount=78

[SharpeXB]

I’d rather see ED work on more productive things than reducing graphics quality. :music_whistling:

[RealDCSpilot]

Oh no, they don't need to reduce the quality. Just more efficient usage of textures (resolution) and better memory management will be enough.

[SharpeXB]

Oh no, they don't need to reduce the quality. Just more efficient usage of textures (resolution) and better memory management will be enough.

There’s already a Textures graphic setting in the game.

[Dragon1-1]

Except it also affects the diffuse maps, which should stay 4K. There's no separate setting for normal maps, which are the ones that need changing. It also wouldn't affect the size on disk. Depending on how it's implemented, it could also not affect memory use, either, just the rendering itself.

 

BTW, it's not really that much "work" for them. A good batch utility will do that in minutes (maybe more if working off PSD masters), and then they'd need a day or two to check for any artifacts that might've cropped up during conversion.

[Arikaj]

+1

[SharpeXB]

deleted

Edited February 21, 2021 by SharpeXB

[ACME_WIdgets]

F-16 Cockpit:
FIrst, I'm no graphic designer, but I can work Photoshop pretty well.
Second, my system is the slowest of any, around 12fps on MP (GS) - it's an older Dell e6430 laptop, running 1280x768 w/1GB VRAM.
 

So, I'm trying to figure out how to make the F-16 cockpit fps faster.  I see others have done it with FC3 planes.  I got the DDS add on for Photoshop.

As @LucShep poinits out, many of the DDS files are 2k x 2k and some for the F-16 are 4k x 4k.
Using Photoshop's batch processing I did the following on the F-16 Cockpit Textures ZIP files (after many trial and errors):

   - resized all DDS to 1024 x 1024
   - saved only 3 mipmaps (so I think 1024, 512 and 256)

  - saved DDS Output to "Performance" vs default high quality setting
Results:   F-16 Cockpit Textures.zip went from 374k to 32k size file!

                 2-3fps faster in ME and MP

                 but cockpit lettering is terrible on all panels (I know what the switches do anyway)
                 a few artifacts, rotating button tops, some things too dark etc,  MDF reflections become big dots
    I'm not saying this is playable, or a solution - just a data point or two for other experts.

 

Note: I guess due to my low resolution 1280 x 768, even with the stock Cockpit Textures the DCS Settings Cockpit Resolutions all look the same at 1024, 512 and 256.

[LucShep]

*bumpity bump*

Please ED, give a look into this.
Another year has passed, with no real intervention on the subject. The problems remain.

There is also another thread where Taz1004 aproached the subject with greater detail and "proof":

FWIW, Taz1004 already has done the bulk of the work with a mod (popular with the community, but creates issues online on servers with "pure textures" enabled).
 It's just a matter of adopting it and further develop it (for more maps and modules):

ED please do consider it for the sake of all. We really need it.

Edited February 22 by LucShep