Rotating brushes receive light from dynamic lights near (0, 0, 0)

[maikmerten]

Describe the bug
In the "mg1"-campaign (Dimension of the Machine) rotating bmodels receive dynamic lights originating near (0, 0, 0). This is very visible in the "hub"-map, as that map contains a decorative lava pool with lava balls that emit dynamic lights. The light emitted there affect all rotating brushes in the map. Also dlights (e.g. muzzle flashes) originating near the rotating brushes don't affect these brushes.

To Reproduce
Start vkQuake with "-game mg1 +map hub". Observe the various spinning bmodels.

Expected behavior
Rotating brushes should only receive dynamic lights from sources near their actual position. Instead they receive dynamic lights from near (0,0,0).

Screenshots
A video of rotating bmodels receiving dynamic lights from near-(0,0,0)

Desktop (please complete the following information):

• OS: Ubuntu Linux, 22.04 LTS
• AMD Radeon Vega Graphics (integrated GPU)
• Mesa 22.2.5

Mod
Dimension of the Machine (mg1)

Additional context
bmodels in Quake usually have an initial origin at (0,0,0), with QuakeC then moving things around.

This is the QuakeC-code that handles rotating brushes in mg1: https://github.com/id-Software/quake-rerelease-qc/blob/main/quakec_mg1/rotate.qc

[Novum]

I think I know what this is and I don't think it's an easy fix. This probably originated from moving the lightmap calculations to world space instead of texel space.

Thanks for the detailed bug report, that will help.

[temx]

This probably originated from moving the lightmap calculations to world space instead of texel space.

I don't think that's related, this is an original Quake limitation where surfs are lit according to their original position. This also affects trains/lifts and doors, but is more visible with rotators since the map compiler places their pivot at 0,0,0 instead of being close to their expected locations.

Options include:

• disable dlights for them (like c870c04 - but guessing which ones are rotators ahead of time is hacky)
• store model index in every surf, upload transform matrices for every model and use them. May be slow, complicates culling, and assumes only one instance per submodel (which is usually true)
• per-pixel lightning. Slow and looks different unless you jump through hoops that would make it even slower

[Novum]

Interesting, I assumed this was a new bug.

I would probably go for option 2 (transform matrices etc.)