32 bit normal maps in Caucasus

[Taz1004]

There are two 170 MB 32 bit normal maps in /vfstextures/VectorDataAsset.zip. Appears to be for road markings. I've never seen 32 bit normal map for games let alone for road markings. All other normal maps in DCS are 8 bit which they should be.

 

I'm not sure if this is just reference file or actually being used in game but if they are being loaded, please re-save them as 8 bit. I believe it should reduce VRAM load by 300 MB.

 

Not as large but there are 6 more 32 bit normal maps in other VectorDataAsset files for each seasons. Also appears to be road markings.

 

assets_cauc_roads_uvsrdb.png.dds

assets_cauc_roads_uvsroad.png.dds

 

 

Open Beta Build 2.5.6.52437

All mods uninstalled

Edited August 7, 2020 by Taz1004

[reece146]

Sweet catch.

[silverdevil]

i am guessing that per the graphics settings for LOW vs HIGH, the better textures load for HIGH settings.

[Taz1004]

i am guessing that per the graphics settings for LOW vs HIGH, the better textures load for HIGH settings.

 

You don't need 170 MB 32bit normal map even for EXTREME setting. Especially for something like below. Even at that close up, you have to enlarge it full size to see it.

 

 

It appears those files are loaded in the game and its usefulness... doubtful. I don't even use normal map on road markings on Vray architectural renderings.

 

And red channel seems to be flipped on this one too. If anything, those should be raised. They look depressed. I'm beginning to wonder if all red channels on normal maps are flipped on Caucasus.

[javelina1]

thanks Taz, sure hope someone from DCS is looking at your finds...

[Worrazen]

Well, eventually when monitors with Rec. 2100 gamut or higher start getting on the market, with WCG and HDR finally taking off, this will be needed! It's great to see some hint they're preparing for that early, I said this a few years ago that they can be ready for this if they build stuff with higher bits now and work with higher source material, so that the transition to HDR/WCG doesn't force them to rebuild every texture from scratch more or less. That said I'm not the expert on texturing.

 

On the other hand, I could just be a 100% mistake with the output mode that file was saved.

[Taz1004]

Well, eventually when monitors with Rec. 2100 gamut or higher start getting on the market, with WCG and HDR finally taking off, this will be needed!

 

No. 32 bit will help diffuse textures but 32 bit normal map will look exactly same as 8 bit.

 

This is very likely that someone had wrong save setting in Photoshop. Which can happen. Just needs to be corrected. It's just opening and saving. It should take less time than reading this comment.

[will-]

Okay ur saying 32 will look better but you want them saved as 8 bit b/c they look the same to you?

[Taz1004]

Okay ur saying 32 will look better but you want them saved as 8 bit b/c they look the same to you?

 

I don't think you understand the difference between diffuse and normal.

[will-]

I don't think you understand the difference between diffuse and normal.

 

It’s why I’m asking a question.

[Leaderface]

Maybe those textures need alpha blending and that´s the format DCS admits the textures with alpha channel.

Maybe they could improve that or is needed as is.

[Taz1004]

It’s why I’m asking a question.

 

Didn't mean to offend you if I sounded that way. I wasn't sure.

 

Diffuse map is basically color. And bit depth basically determines how many layers of color there are. So 32 bit will have far more color than 8 bit. 8 bit diffuse map (color) will sometimes show banding in shading. 32 bit will eliminate this so that's why I said 32 bit will help diffuse. But diffuse is not the problem I'm reporting was about.

 

Normal map is basically bump map in 3 axis. Long time ago, bump map was just black and white image that offset the surface in 1 dimension based on greyscale. Some smart guy figured out that there are 3 channels to RGB image and we can use those 3 channels to simulate XYZ coordinate. So storing bump in 3 axis in an image file. But there's only so much you can bump with an image that these are mostly used for things like gravels, rivets, carpet, windows, cracks.... with very convincing results. But you can't raise a building from a ground with a normal map. And today's graphic cards are far better at handling polygons than processing large image files that some even see normal maps disappearing in the future. Latest Unreal Engine 5 tech demo showed this.

 

So having 32 bit of depth on such small bumps will not be beneficial. You will not be able to distinguish between a bump from 32 bit and bump from 8 bit. It will only take up VRAM for no good reason. 340MB in this case which is almost 4.25% of 8GB most graphic cards have. For that bump on the road lines.

 

Which is also why I said this has to be an oversight. Not done on purpose.

Edited August 8, 2020 by Taz1004

[will-]

Thx for the explanation. Would this have to do with increased polygon counts they are referring to? Sorry for all the q’s

[Worrazen]

Didn't mean to offend you if I sounded that way. I wasn't sure.

 

Diffuse map is basically color. And bit depth basically determines how many layers of color there are. So 32 bit will have far more color than 8 bit. 8 bit diffuse map (color) will sometimes show banding in shading. 32 bit will eliminate this so that's why I said 32 bit will help diffuse. But diffuse is not the problem I'm reporting was about.

 

Normal map is basically bump map in 3 axis. Long time ago, bump map was just black and white image that offset the surface in 1 dimension based on greyscale. Some smart guy figured out that there are 3 channels to RGB image and we can use those 3 channels to simulate XYZ coordinate. So storing bump in 3 axis in an image file. But there's only so much you can bump with an image that these are mostly used for things like gravels, rivets, carpet, windows, cracks.... with very convincing results. But you can't raise a building from a ground with a normal map. And today's graphic cards are far better at handling polygons than processing large image files that some even see normal maps disappearing in the future. Latest Unreal Engine 5 tech demo showed this.

 

So having 32 bit of depth on such small bumps will not be beneficial. You will not be able to distinguish between a bump from 32 bit and bump from 8 bit. It will only take up VRAM for no good reason. 340MB in this case which is almost 4.25% of 8GB most graphic cards have. For that bump on the road lines.

 

Which is also why I said this has to be an oversight. Not done on purpose.

 

Oh ofcourse, normal mapping is bump mapping! :doh:

 

Right so my answers aren't valid for this, but for the color we see.

[stormrider]

You don't need 170 MB 32bit normal map even for EXTREME setting. Especially for something like below. Even at that close up, you have to enlarge it full size to see it.

 

 

It appears those files are loaded in the game and its usefulness... doubtful. I don't even use normal map on road markings on Vray architectural renderings.

 

And red channel seems to be flipped on this one too. If anything, those should be raised. They look depressed. I'm beginning to wonder if all red channels on normal maps are flipped on Caucasus.

 

Im starting to think you're right, all normal maps seem to be flipped.

[Worrazen]

This looks like a bit of a false alarm, unfortunately or fortunately actually, the OP is correct they're not 8 bit, but I've dug into this and they're not 32-bit per channel either, they are 16-bit per channel with alpha.

 

The color parent is BC3_UNORM or DXT5 as expected

But the "uvs" is R16G16B16A16_UNORM

 

But what's more is that these assets don't seem to be used on Caucasus as of OB right now, I got to test for a few hours as I got access to another PC with Win7 with both DCS versions on there.

After failing an initial search as I've never seen such roads before, I've edited the color parent files and colored them differently to stand out for highlighting purpose, then I flew around for 30 minutes and looked 15 minutes around all the major cities in mission editor's SAT view mode and didn't found any sign of these files being used right now.

 

So I guess it's not taking any VRAM/RAM probably right now, just some dev files that are left or misplaced there.

 

 

 

Another person I asked had no idea what these 16-bit files are, they don't seem to be Normals/Bump nor UVs to him (even tho the filenames include an "uvs" suffix). It may be something custom, for some special vector stuff probably the way textures are applied onto the splines or something.

 

There may actually be a reason to use 16-bit per channel because of more space for more data that may be useful when storing things not usually in color that you can see nor intended as texture data, in that case it may not be a bug and may be intended (correct).

 

This is an unusual format so that's why most image programs will not show what the image actually looks like (nor IrfanView, only DXT formats), so only performance and debugging tools will work.

 

Red Channel:

 

 

Green Channel:

 

 

Blue Channel:

 

 

Red + Green Channels:

 

 

Red + Blue Channels:

 

 

Green + Blue Channels:

 

 

RGB:

 

 

RGBAlpha:

 

FWIW ^^

If it's some non-texture data these channel combinations and colors in this view don't mean anything, it's just used by some custom shader or something, data in another channel could be for something completely different.

Edited August 12, 2020 by Worrazen

[Worrazen]

So I took the Su-25T in Rockets and Gun Practice mission, which spawns at Kutaisi, I flew for half the way to the targets over at the lake to the east, paused and took a look in the memory with Process Hacker

 

If this even counts, it's suppose to be inspecting RAM and may not actually be valid to what things could be in VRAM. I would assume it's not the full story, but at least in this case it shows low usage, adding to the evidence these files probably aren't loaded into the game, but I don't know the VRAM to RAM relationships enough ... I need a VRAM inspection tool, should have looked for that a long time ago.