Convert normal maps to RGTC?

[duzenko]

Now that we have upgraded the renderer to GL3.1 it makes sense to convert normal map tga's to DDS's.

Not only RGTC is better than DXT in quality per compressed megabyte of VRAM but being pre-compressed it will also load faster at map start.

I think we can automate conversion using the integrated DDS writer.

 

[peter_spy]

Artist would rather have full control over how normalmaps are compressed. IIUC, this is ditching the blue channel, right?

[duzenko]

Yes, red and gree stored, blue calculated.

[peter_spy]

Would like to see how it looks on unwrapped models with baked averaged normals. AFAIK, you need blue channel in those for proper interpolation between model topology (faces normals) and baked normalmap to fake smooth edges.

[duzenko]

You're unlikely to see any difference

You can force RGTC already in 2.07 with image_useNormalCompression 2

I'm talking about converting the existing bump maps in TDM assets on the file level

[peter_spy]

I don't think it works, as the video memory use is the same with image_useNormalCompression set to 0 or 2.

[HMart]

I only tested on the 2.08 exes that Duzenko made available to test, and on those it works, I see no visual difference (with one exception, see below...) nor performance difference with normal map compression 1 or 2, what I see is a huge reduction in GPU memory usage, with it off the scene I was on was using 1389 MB of VRAM with with on either on 1 or 2 it fall down to 878 MB, that's the difference between a older 1GB GPU being able to play the game well or not, on mine GPU that has 8GB of VRAM I could, right now, very well play with compression off.

... with RGTC enabled the water in Volta 2, at the beginning, looks even more broken, now it shows a reflection with the colors totally messed up, man that water shader does need to be reworked.

p.s I tested on 2.07 now and it worked, what i did was start Volta 2 went in-game and only there change the svar, on the menu I saw no difference, I assume that most be because the menu does not use any normal maps. 

Edited October 7, 2019 by HMart

[peter_spy]

Oh, it seems like it needs to be coupled with image_useCompression 1. I think previously those two worked independently.

[duzenko]

3 hours ago, HMart said:

p.s I tested on 2.07 now and it worked, what i did was start Volta 2 went in-game and only there change the svar, on the menu I saw no difference, I assume that most be because the menu does not use any normal maps. 

Sorry about that. I plan to fix other things first. Worst case it might have to wait till the beta phase

[VanishedOne]

Just to check: will image functions like addNormals() still work on the compressed normal maps? (They don't work on DDS images.)

[duzenko]

15 hours ago, VanishedOne said:

Just to check: will image functions like addNormals() still work on the compressed normal maps? (They don't work on DDS images.)

Right, no load-time processing for pre-compressed images

I guess we could exclude textures used by addNormals, etc from conversion

[duzenko]

6 hours ago, duzenko said:

Right, no load-time processing for pre-compressed images

I guess we could exclude textures used by addNormals, etc from conversion

Or better off, bake those functions into a new texture and save it as a DDS

[stgatilov]

Since DXT5 format with custom channels swizzling is used by default in TDM for ages, why are normal maps still in TGAs? I mean, why they were not converted to DDS when DXT5 compression was supported?

 

[nbohr1more]

I believe there were two main reasons:

1) Multiple team members complained about compression artifacts in pre-compressed normal maps

and opted to not use them. This also had the benefit of faster mission loading.

2) Pre-Compressed Normal maps cannot use image program functions like addnormals and heightmap so

they were seen as potential stumbling blocks for material re-use workflows which were the main source of

asset variation early in the mod

[peter_spy]

Point 1 is still valid today. DXT5 makes normalmaps look more blurry and there are artifacts both for simple flat surfaces and more complex patterns. And the DXT5nm mode looks wrong and is unusable.

Edited November 17, 2019 by peter_spy

[duzenko]

I suppose for this we need to convert existing materials and generate new dds's for each use of image function

I understand this is not trivial but it would be a feel-good thing to do.

Not only it would save on VRAM but also on load speed (pk4 decompression and mipmap generation)

Moreover, textures can be loaded in parallel via PBO + background CPU thread.

[stgatilov]

19 hours ago, nbohr1more said:

1) Multiple team members complained about compression artifacts in pre-compressed normal maps and opted to not use them.

But now normal maps are compressed with some DXT5 variation when they are uploaded to OpenGL. Does it mean that most of the players see those exact artifacts right now?

[peter_spy]

Only if they have in-engine normal compression set to 1, which is the default, IIRC. Turning it off is more useful for content authoring purposes IMO.

Edited November 17, 2019 by peter_spy

[nbohr1more]

Right. There was a great deal of FUD around normal map compression early in the mod development.

There are threads where devs and players mistook the lowest quality normal map compression with the highest.

There are threads where devs and players found their drivers didn't support one or another normal map compression form.

I think it wasn't until 3yrs ago that we became aware that our "image_useNormalCompression" is forcing conversion to normal map compression

rather than optionally using pre-compressed normal maps when available.

RGTC will improve image quality and lower texture memory consumption.

[duzenko]

19 hours ago, stgatilov said:

But now normal maps are compressed with some DXT5 variation when they are uploaded to OpenGL. Does it mean that most of the players see those exact artifacts right now?

Since image_useNormalCompression is currently 1 then the new players will likely have their normal maps compressed to DXT5 (or whatever format we use) in runtime on map load.

I'm not sure what was the default value for image_useNormalCompression historically and what might be saved to local .cfg's for older installations.

[peter_spy]

Btw. Not sure if you ever contacted Justin, but I remember he's been working on a "virtual texture" solution which basically a texture streaming thing. That should speed up loading time immensely, whether with DDS normalmaps or TGA.

 

Edited November 18, 2019 by peter_spy

[duzenko]

36 minutes ago, peter_spy said:

Btw. Not sure if you ever contacted Justin, but I remember he's been working on a "virtual texture" solution which basically a texture streaming thing. That should speed up loading time immensely, whether with DDS normalmaps or TGA.

 

The only thing missing there is the source code

[stgatilov]

I think it would be great if artists could check how RGTC compression affects normal maps and write down the worst cases.

The RGTC compression should be somewhat better that hacked-DXT5 which TDM uses now, and significantly better than standard DXT5. Recall that RGTC is enabled by image_useNormalCompression 2.

[peter_spy]

At first glance, normals on models look fine, even if you substitute diffuse texture with solid color. And the memory use is significantly lower. But when you use showprimitives, there is this warning that says R_BitsForInternalFormat: bad internalFormat: 36285

Another thing is that something changes with how cubemap reflections are rendered. I have a cubemap overlaid on top of my frobabble models, and before it looked like this:

And now it looks like this:

[duzenko]

2 hours ago, peter_spy said:

Another thing is that something changes with how cubemap reflections are rendered. I have a cubemap overlaid on top of my frobabble models, and before it looked like this:

 

It's easy to fix the cubemap shader to support RGTC