update_lightmap.comp packing code

[Novum]

@temx I have a hard time understanding this change to update_lightmap.comp:

vkQuake/Shaders/update_lightmap.comp

Line 176 in 9b51cae

const uint s_mod = (packed_light_st >> 24) & 0xFF;

Why are there modulos on the invocation ID and then after the subtract?

[temx]

The ones over gl_GlobalInvocationID are not needed, but while AMD generates the same code, Nvidia regresses for some reason if they're removed (Register Count: 37; Binary Size: 4992 --> Register Count: 39; Binary Size: 6016). Not sure what's that about.

[Novum]

What I also don't understand is that the light_s/light_t values are clearly sometimes over 255, so how does the packing work?

[temx]

The code needs the offsets (s & t) within the surf slice / "lightmap piece". Originally this was done by storing the top-left corner and subtracting the current coordinate (took 32x2 bits, could be packed to 10x2 for lightmaps <= 1024 in size). Since the slices are small (usually <= 18, and currently we reject >126, but the code supports < 256) and we only care about the difference, we can store just the last 8 bits of each coord and do a modular subtraction, getting the total down to 8x2 bits for any total lightmap size.

In other words, it's turning a-b into (a - (b % 256)) % 256, which is true if (a-b) < 256, in order to store b using 8 bits.

Unrelated to the change, the fact that it measures distance using texels means dynamic light radiuses depend on texel density (it's like that in the original Quake).

[Novum]

As far as I know the lightmap texel density is uniform, so that should be ok.

I'm just worried that someone at some point will produce a map where this doesn't hold true with newer map tools?

[Novum]

b40a682

I realized we can remove texturemins, so now we have more bits available.

[temx]

Lightmap texel density is tied to texture density, and some maps do adjust it, either for artistic considerations or to save on texture/lightmap space. Example from shib3_drake. This is a single dlight hitting these surfaces. It has always been like this, though engines that do per-pixel dlights avoid this problem. Another related issue is bmodels are lit according to their original position, so when they move (doors, platforms) dlights appear in the wrong places (again, it has always been like this).

I'm just worried that someone at some point will produce a map where this doesn't hold true

GlQuake supported 18x18 at the max, and most maps stick to that (vkQuake 1.20 would print an error if you tried to exceed that, and nobody complained). Anything QuakeSpasm-derived will outright reject >126.

now we have more bits available

This could be used to raise the indirect vertex limit above 16M, but it's hard to imagine a Quake level hitting it.