Normalmap artefacts with image_useNormalCompression 1

[Dragofer]

I've noticed that some textures with normalmaps now have a blotchy appearance in 2.09 if viewed from a sharp angle:

The problem disappears if I either:

• comment out the normalmap in the material definition
• set image_useNormalCompression 0
• revert to TDM 2.08

It affects for example textures/darkmod/wood/boards/polished_01, but not textures/darkmod/stone/brick/blocks_large_sandstone.

This is on a PC with Intel UHD 630, Intel i5-9400F. Got a console log here: 209_splotchy.txt

[stgatilov]

How does it look on a different machine (e.g. with NVIDIA GPU) ?

Most likely this is the artefact of RGTC compression.
If this problem does not happen on other GPUs, then it is a problem of how Intel driver compresses to RGTC.

It is hard to see on a screenshot how bad the problem is, especially when "good" screenshot is not provided.

The most important question is: will we have to live with such problem if we compress all normal textures to RGTC, as we plan to do for 2.10 ?
To answer this question, you have to take some offline tool (most likely Compressonator) and convert this normal map to DDS. Then ensure this DDS is loaded in game (I'm not sure whether engine already loads DDS automatically or not) and check how it looks.
 

[Dragofer]

17 hours ago, stgatilov said:

To answer this question, you have to take some offline tool (most likely Compressonator) and convert this normal map to DDS. Then ensure this DDS is loaded in game (I'm not sure whether engine already loads DDS automatically or not) and check how it looks.

Converting that normal map to .dds with DXT1 and mipmaps with GIMP has resolved the issue:

To confirm that the engine does in fact load .dds normalmaps, I also converted, renamed and assigned some very noticeable curtain normalmaps to this wood floor and saw no difference compared to the original .tga curtain normalmaps. The paintings are untouched and still have the splotchiness.

Also, I noticed that current SVN (ca. rev 9216) doesn't have this issue.

 

18 hours ago, stgatilov said:

How does it look on a different machine (e.g. with NVIDIA GPU) ?

Will have to see when I get a chance. But there's definitely something fishy with intel GPUs, map loading times are really long in 2.09 with this GPU and they're shortened to one quarter by disabling that normal map compression cvar.

[stgatilov]

2 hours ago, Dragofer said:

Converting that normal map to .dds with DXT1 and mipmaps with GIMP has resolved the issue:

Well done.
Although I have a feeling that DXT1 and RGTC are different compression formats.

I think RGTC is also called BC5U.

UDPATE: I guess it is either BC5 or ATI2N_XY...
Damn this stupid nomenclature!

[Dragofer]

7 hours ago, stgatilov said:

Well done.
Although I have a feeling that DXT1 and RGTC are different compression formats.

I think RGTC is also called BC5U.

UDPATE: I guess it is either BC5 or ATI2N_XY...
Damn this stupid nomenclature!

BC5/ATI2 (3Dc) unfortunately doesn't seem to work regardless of whether I generate mipmaps. The normalmap is missing ingame (flat appearance) and the console writes "Failed to get bindless texture handle:".

If I set r_useBindlessTextures 0 the texture becomes dark except for where a light source lights it up (no ambient light illumination). I've seen that before when the normalmap can't be loaded.

 

These are the DDS export options in GIMP:

The appearance with r_useBindlessTextures 1 is as in the previous message, and this below is what it looks like when I set r_useBindlessTextures 0:

Btw, I found that increasing anisotropy filtering in graphics settings makes the artefacts less severe (as can be seen on the ceiling in this shot).

[nbohr1more]

Oof.. Is the new backend not RGTC capable?

@cabalistic ?

Quote

Also, I noticed that current SVN (ca. rev 9216) doesn't have this issue.

Is this true if you copy the glprogs directory from tdm_src to your SVN darkmod directory?

[nbohr1more]

@Dragofer  can I get a test map? I have never seen this artifact in 2.09 or SVN and I always have normalmap compression enabled.

[OGDA]

That map is my testmap from this thread:

 

I didn't make any changes to the wood textures.

For the paitings: the diffuse maps of the paintings where exported with the photoshop nvidia dds plugin with setting BC1 (which equals to DXT1 as stated by the plugin) with production quality. The normal maps where as far as I remember exported with BC3 (equaling to DXT4/DXT5 as stated by the plugin).

If something is wrong with that export method, please let me know so I can fix the paintings. But I hope that's not the case, as the problem also shows on the wood texture.

 

[Dragofer]

1 hour ago, nbohr1more said:

Is this true if you copy the glprogs directory from tdm_src to your SVN darkmod directory?

Copying the glprogs folder from darkmod_src to my 2.09 release build made no difference, still splotchy. But on darkmod_svn (assets) there's no problem.

1 hour ago, nbohr1more said:

@Dragofer  can I get a test map? I have never seen this artifact in 2.09 or SVN and I always have normalmap compression enabled.

Sure, as OGDA said it's his paintings demo map. I've already reuploaded my own version because the original version had a small mistake in the folder structure (there's one top level of folders too many) that prevented it from being possible to treat like an FM: https://drive.google.com/file/d/1G4WJY9G5T6hyIn9pM2KINOHD503b9sxS/view?usp=sharing

@OGDA I don't think there's any need for action from your side, to me it looks like it's a problem with a 2.09 change to how TDM handles normalmaps, which seems to break on Intel GPUs.

[nbohr1more]

@Dragofer does the RGTC \ BC5 encoded texture work if you put it into the standard textures path rather than the "dds/textures" path?