deluxemap overflow

[illwieckz]

Reported there before: UnvanquishedAssets/map-station15_src.dpkdir#3

I'm now sure it's an engine issue, and I now know the line causing this:

	lightColor /= clamp(dot(normalize(var_Normal), lightDir), 0.004, 1.0);

There:

Daemon/src/engine/renderer/glsl_source/lightMapping_fp.glsl

Lines 91 to 92 in 42e408a

	// divide by cosine term to restore original light color
	lightColor /= clamp(dot(normalize(var_Normal), lightDir), 0.004, 1.0);

We can find trace of this code in first commit of the repository:

Daemon/main/glsl/lightMapping_fp.glsl

Line 165 in eb73a11

float NdotLnobump = clamp(dot(normalize(var_Normal.xyz), L), 0.004, 1.0);

It was removed in 0bb3550 (Add tiled light-index renderer) and re-added in 0949fda (Lightmapping fixes) by @gimhael.

I don't know what this code is for, it looks like there is less issues by not using this code than using it.

[illwieckz]

If I comment out this code, the artifacts disappear:

Before / after:

Before / after:

Before / after:

Before / after:

[illwieckz]

I discovered the faulty line by working on a merge of lightmap world / vertex world / vertex entity code. Once the glsl shaders were merged and it became possible to render normal maps on lightmapped maps without deluxemaps using lightgrid instead of deluxemap to compute light direction, the bug surfaced again.

[slipher]

I don't understand why this line is needed, but if there are artifacts, maybe they could be caused by bad values in the normalmap, for example if all components were 0. Or if it's doing the normal map reconstruction here, it could be getting an invalid z value when x^2 + y^2 > 1 (the bug causing black areas with r_showNormalMaps).

[gimhael]

The reason why this line exists, is because the lightmaps generated by q3map2 don't store the raw light value, but they store light premultiplied with the dot product of the light direction and surface normal.

The line is just an attempt to reverse that and get the original light values.

The lightmap stores the light in this way because for the diffuse lighting formula the outgoing light is equal to the incoming light multiplied by the above dot product multiplied by the surface albedo (which is the texture map of the surface). So this premultiplication means that the diffuse lighting value can be calculated with a single multiply operation.

But specular lighting and/or normal mapping formulas are more complex, and so you need the true light value to get correct lighting.

Obviously the data is not good enough to recover the original color in all cases. The 0.004 lower bound was an arbitrary chose factor to prevent too small divisors resulting in too bright lights. Increasing the value should reduce these artifacts.

[slipher]

The concept of a light direction for something other than a point source is pretty mathematically bogus (I mean, even more so than most rendering math 🙂 ). So maybe it would be good to use a pretty large value like 0.1, since there could be a lot of big errors.

[illwieckz]

Using .1 is not enough:

This looks better, but it's not enough.

[illwieckz]

Vega is ok with .2 but station15 requires at least .3.

With .3, it's possible recognize a slight artifact on chasm, but that's hard to notice without looking purposedly for it, and it's not pure white. In fact, even .5 is not enough on chasm, a sharp eye looking for the bug can still recognize the issue.

So, unless there is a strong argument against it, I will set it to .3, the remaining artifacts are very rare and when they happen, they are rare to notice and are not pure white.