Light artifacts on face corners (regression?)

[RaZeR-RBI]

Greetings!
A somewhat recent commit introduced kind of 'pointy' artifact on my lightmaps, which have size of one luxel and it seems to me that they appear on corners of each faces' lightmaps (though I haven't checked wireframe yet). I'm compiling my maps for Quake 2.

Unfortunately I haven't fixed building from source on my machine yet (I'm running Debian), so I've used CI builds from workflows to investigate. From what I've found issue doesn't appear on commit 0a8aa6e, and starts to appear on 51def32.

Here's how it looks on the sample map - notice the small round light points equally spaced like they're on a grid:

Sample map:

// Game: Quake 2
// Format: Quake2
// entity 0
{
"classname" "worldspawn"
"_tb_textures" "textures/e1u1"
"_sunlight_color" "0.141176 0.0509804 0.286275"
"_sunlight" "100"
"sky" "unit1_"
"skyrotate" "1"
// brush 0
{
( -768 -64 -16 ) ( -768 -63 -16 ) ( -768 -64 -15 ) e1u1/florr2_8 0 0 0 1 1
( -64 -768 -16 ) ( -64 -768 -15 ) ( -63 -768 -16 ) e1u1/florr2_8 0 0 0 1 1
( -64 -64 -16 ) ( -63 -64 -16 ) ( -64 -63 -16 ) e1u1/florr2_8 0 0 0 1 1
( 64 64 16 ) ( 64 65 16 ) ( 65 64 16 ) e1u1/florr2_8 0 0 0 1 1
( 64 768 16 ) ( 65 768 16 ) ( 64 768 17 ) e1u1/florr2_8 0 0 0 1 1
( 768 64 16 ) ( 768 64 17 ) ( 768 65 16 ) e1u1/florr2_8 0 0 0 1 1
}
// brush 1
{
( -768 -768 0 ) ( -768 -767 0 ) ( -768 -768 1 ) e1u1/florr2_8 0 0 0 1 1
( -768 -768 0 ) ( -768 -768 1 ) ( -767 -768 0 ) e1u1/florr2_8 0 0 0 1 1
( -768 -768 0 ) ( -767 -768 0 ) ( -768 -767 0 ) e1u1/florr2_8 0 0 0 1 1
( 768 -736 512 ) ( 768 -735 512 ) ( 769 -736 512 ) e1u1/florr2_8 0 0 0 1 1
( 768 -736 32 ) ( 769 -736 32 ) ( 768 -736 33 ) e1u1/florr2_8 0 0 0 1 1
( 768 -736 32 ) ( 768 -736 33 ) ( 768 -735 32 ) e1u1/florr2_8 0 0 0 1 1
}
// brush 2
{
( -768 736 32 ) ( -768 736 33 ) ( -768 735 32 ) e1u1/florr2_8 0 0 0 1 1
( -768 736 32 ) ( -769 736 32 ) ( -768 736 33 ) e1u1/florr2_8 0 0 0 1 1
( 768 768 0 ) ( 767 768 0 ) ( 768 767 0 ) e1u1/florr2_8 0 0 0 1 1
( -768 736 512 ) ( -768 735 512 ) ( -769 736 512 ) e1u1/florr2_8 0 0 0 1 1
( 768 768 0 ) ( 768 768 1 ) ( 767 768 0 ) e1u1/florr2_8 0 0 0 1 1
( 768 768 0 ) ( 768 767 0 ) ( 768 768 1 ) e1u1/florr2_8 0 0 0 1 1
}
// brush 3
{
( 736 768 32 ) ( 736 769 32 ) ( 736 768 33 ) e1u1/florr2_8 0 0 0 1 1
( 768 -768 0 ) ( 767 -768 0 ) ( 768 -768 1 ) e1u1/florr2_8 0 0 0 1 1
( 768 -768 0 ) ( 768 -767 0 ) ( 767 -768 0 ) e1u1/florr2_8 0 0 0 1 1
( 736 768 512 ) ( 735 768 512 ) ( 736 769 512 ) e1u1/florr2_8 0 0 0 1 1
( 736 768 32 ) ( 736 768 33 ) ( 735 768 32 ) e1u1/florr2_8 0 0 0 1 1
( 768 -768 0 ) ( 768 -768 1 ) ( 768 -767 0 ) e1u1/florr2_8 0 0 0 1 1
}
// brush 4
{
( -768 768 0 ) ( -768 768 1 ) ( -768 767 0 ) e1u1/florr2_8 0 0 0 1 1
( -736 -768 32 ) ( -736 -768 33 ) ( -735 -768 32 ) e1u1/florr2_8 0 0 0 1 1
( -768 768 0 ) ( -768 767 0 ) ( -767 768 0 ) e1u1/florr2_8 0 0 0 1 1
( -736 -768 512 ) ( -735 -768 512 ) ( -736 -769 512 ) e1u1/florr2_8 0 0 0 1 1
( -768 768 0 ) ( -767 768 0 ) ( -768 768 1 ) e1u1/florr2_8 0 0 0 1 1
( -736 -768 32 ) ( -736 -769 32 ) ( -736 -768 33 ) e1u1/florr2_8 0 0 0 1 1
}
// brush 5
{
( -768 -64 512 ) ( -768 -63 512 ) ( -768 -64 513 ) e1u1/sky1 0 0 0 1 1 0 4 0
( -64 -768 512 ) ( -64 -768 513 ) ( -63 -768 512 ) e1u1/sky1 0 0 0 1 1 0 4 0
( -64 -64 512 ) ( -63 -64 512 ) ( -64 -63 512 ) e1u1/sky1 0 0 0 1 1 0 4 0
( 64 64 544 ) ( 64 65 544 ) ( 65 64 544 ) e1u1/sky1 0 0 0 1 1 0 4 0
( 64 768 544 ) ( 65 768 544 ) ( 64 768 545 ) e1u1/sky1 0 0 0 1 1 0 4 0
( 768 64 544 ) ( 768 64 545 ) ( 768 65 544 ) e1u1/sky1 0 0 0 1 1 0 4 0
}
}
// entity 1
{
"classname" "info_player_start"
"origin" "0 0 40"
}

All compilation settings on command line are default (only gamedir is specified).

Skimming through diff between those commits I see that fastbounce was replaced by new emissivequality parameter, which, I guess, could be a starting point for investigation.

Thank you very much for making these tools available for Quake 2 :)

[Paril]

Surface lights use single point emissions by default now, which is to help with execution speed. Bounce lighting is the same code as surface lighting, so they both end up only emitting from one point in the center of the polygon, which is where that hotspot is coming from.

Eric is working on fixing the hotspotting in a separate branch - it requires reworking a bunch of stuff so it probably won't be done any time soon. For now, -emissivequality high will use points spread across the entire face and should look like the older commits.

[RaZeR-RBI]

Surface lights use single point emissions by default now, which is to help with execution speed. Bounce lighting is the same code as surface lighting, so they both end up only emitting from one point in the center of the polygon, which is where that hotspot is coming from.

Thanks for the explanation, everything is clear to me now :)

Eric is working on fixing the hotspotting in a separate branch - it requires reworking a bunch of stuff so it probably won't be done any time soon. For now, -emissivequality high will use points spread across the entire face and should look like the older commits.

Great to hear!

Ain't the end of the world to be honest, since these mostly noticeable on weird color combinations - that's why example map is so weird colored - it's to exagerrate them.
When the map is filled with stuff and lighting is set up these artifacts start to blend with their surroundings (at least for me).

Thanks again!