 |
This probably broke when we switched to forcing RGTC compression in 2.09. There is no blue channel to invert. Using "forceHighQuality" in the material def should prevent this conversion but it doesn't seem to work? |
 |
scale(models/darkmod/props/textures/curtain01_local, 1, 1, 0, 1) It does not invert anything, it simply removes blue component. That's not a good thing to do, because normal map is no longer normalized, and it is up to receiver to decide how to treat it. That's what is usually described as "undefined/unspecified behavior". One can either ignore blue channel (that's the most natural thing to do for RGTC compressor) so that the scaling has no effect. Or one can normalize all pixels (by Euclidean norm) and obtain normal map with all normals parallel to surface. Even in the latter case, nothing is inverted, instead surfaces are bent to set maximum slope (90 degrees) of every surface fragment while saving its direction. Doom 3 engine originally used DXT5nm normal maps compression, and probably DXT5nm compressors treated unnormalized normal maps in yet another way, but that was dependent on OpenGL driver. Anyway, I am against restoring or guaranteeing any specific behavior for unnormalized normal maps. But if someone knows exact math, we can add a new image program function that would normalize normal map as desired. UPDATE: Here I forgot that [0..1] color is remapped to [-1..1] vector coordinate. So setting blue to 0 means changing vector (x, y, z) to (x, y, -1) Given that z is usually very close to 1, (x, y, -1) is very close to (x, y, -z), which means mirroring bumpmap by surface's plane. |
|
|
See the "Back Lighting Example" on this Polycount wiki: http://wiki.polycount.com/wiki/Normal_map That wiki claims that inverting the blue channel would be the desired design. Rich_is_Bored implemented this in Doom 3 via the scale changes above: https://forums.thedarkmod.com/index.php?/topic/11515-real-translucency-anyone/ https://www.youtube.com/watch?v=KOZdTo1EmOY I suppose another way to accomplish this is to simple create another normal map image and point the material def at both. The scale hack was to reduce the number of textures needed. |
 |
Can't you simply slap an ambient light there? |
|
|
Unfortunately, we cannot inverse blue channel. RGTC compression assumes that Z is always positive, there is no way to put sign to Z coordinate of normal. I'm afraid back-face lighting has to be achieved by some other means. UPDATE: on the other hand, there is no reason for it not to work with forceHighQuality. |
|
|
I think we need to determine whether the forceHighQuality keyword is broken or whether vertex blending no longer works for normal maps ( issue 5718 )... the latter being a much larger issue. |
|
|
I found that forceHighQuality indeed does not work in the perfect way. Our current code always treats bumpmap as saved in RGTC format (even if it has plain RGB8 format), and thus shaders compute Z as sqrt(1 - x*x - z*z). I have found a way to fix it for old backend right now. Another issue is that old backend shaders take normal vector from AGB colors instead of RGB for non-RGTC inputs (new backend shaders does not even have such a case). Second problem which blocks back-lighting is the fix I introduced in 0004825 (it can be disabled by r_useBumpmapLightTogglingFix). It is the one which gradually reduced NdotL term as the angle between light rays and mesh interpolated normal gets closer to 90 degrees. When light is on the other side of the surface, it zeros NdotL term. I think the solution would be to use this hack only for single-sided surfaces, and to not use it for double-sided ones. |
|
|
Fixed in the following revisions: r9776. Support uncompressed normal maps in old backend. r9777. Disable useBumpmapLightTogglingFix for two-sided materials (also old backend). r9778. Fixed non-RGTC textures and bumpmap-toggling fix on new backend too. Basically, I restored non-RGTC (uncompressed) bumpmaps, along with the natural way of normalizing vectors. Then I disabled "bumpmapping light toggling fix" for surfaces with two-sided material. |
|
|
I have confirmed that adding "forceHighQuality" to the material in the test map fixes the issue. "Real translucency" works again! Thank you! translucent.mtr (775 bytes) |
|
|
Regression in 2.13 Dev Build 10890 Last known working build 10869 Under investigation... 10874 works 10883 broken Regression happened in 10875 |
|
|
Reverting the single line 37 in interaction.shadowmap.fs.glsl fixes it: old (working): vec3 worldNormal = mat3(u_modelMatrix) * (var_TangentBitangentNormalMatrix * props.localN); new (broken) vec3 worldNormal = mat3(u_modelMatrix) * var_TangentBitangentNormalMatrix[2]; maybe we need a branch for non-POM materials here? |
|
|
I added copying of the sign from bumpmap normal in svn rev 10901. Works fine now. Thank you! |
- Anonymous
