CS:O 2 (2018) Lightmaps

[snake-biscuits]

2018 Counter-Strike: Online 2 introduces a new LIGHTING format, 4 lightmaps per face

pre-2018 CS:O 2 used the same system as other Source Engine branches (LDR & HDR)
post-2018 is exclusively HDR

There's some similarities to the Titanfall Engine's lightmaps
Could be because Nexon stopped working on Titanfall: Online in 2018, and they copied Respawn's tech.

Related:

• Titanfall Engine lightmaps #89

[snake-biscuits]

Source Engine Format

Source Engine's Lighting lump is very similar to Quake / Quake 2's

Rather than a full image, LIGHTING lumps pack a series of texels for each Face w/ offsets & sizes
Lightmap Pages can be assembled at runtime to save on video memory

TODO: Source Engine console commands for showing lightmaps & pages

The Orange Box introduced HDR lighting
Dynamic Range is achieved by storing an "Exponent" value in the Alpha channel of each RGBA lightmap texel
The lightmap page appears to be modified at runtime to match the current exponent

NOTE: https://github.com/magcius/noclip.website seems to show HDR pretty well
It's probably some complex system based on leaves & tonemap_controller entities

Examples

Taken from cso2_2017.de_inferno.bsp.HDR.tga:

For this image, I multiplied the Alpha against the RGB channels
Banding occurs where the Exponent changes, you can see this even without multiplying the Alpha

[snake-biscuits]

Lightmap Pages can be assembled at runtime to save on video memory

The Source Engine isn't great at assembling these pages
No consideration is taken for texture bleed
Bleed can be made even worse by large lightmap scales however

VRAD appears to only sample the center of each lightmap texel, leading to poor quality

Sample

Lightmap bleed on a ramp in cp_sapphire:

Lightmap texture filtering is off, and another console command is showing the Lightmap Page in the top left
White outlines surround faces that are currently visible / close to the crosshair

[snake-biscuits]

Misc

• Each face includes a single texel (4 bytes) before each "texture"
  • Seems to be the average colour (including exponent)
  • In cso2_2018 this texel is always 00 00 00 00
  • Haven't confirmed if faces without lightmaps generate these
• Lightmap UVs have a boundary of half a texel
  • To extract the image for a given face, you have to add 1 to the size of each axis
  • Does VRAD sample this texel, instead of bleeding the rest of the lightmap?

[snake-biscuits]

For the TF2 screenshot I used the following console commands:

• mat_filterlightmaps 0 to pixelate lightmaps
• mat_showlightmappage 1 to show the runtime assembled lightmap page

[snake-biscuits]

HDR.A & HDR.B

It looks like Nexon increased the potential Dynamic Range by splitting the original Lightmap into 2 ranges
Would explain why early attempts to port face lightmaps resulted in visible banding in-game

These early attempts were done by Organnerx & other CSO:2 modders
Building on the CS:S -> CS:O 2 conversion tool: ~leite/cso2-bsp-converter

Examples

cso2_2018.de_dust2.bsp.HDR.A.tga w/ multiplied alpha:

cso2_2018.de_dust2.bsp.HDR.B.tga w/ multiplied alpha:

B is mostly dark, but has some areas which are brighter than A
There's also some "holes" of black at what seems to be the brightest points in A
In the top row there's a prominent one where there seems to be a bright spot in A filling the "hole"

[SomaZ]

It's potentially a direct light and an ambient light lightmap. Makes sense so the engine can use ambient occlusion to only occlude the ambient (indirect) light. Just a guess.

[snake-biscuits]

HDR.C

This is where the similarities with the Titanfall Engine begin
Looks like a normal map, though it's not a 1:1 copy of the surface normal
Just like w/ Titanfall's SKY.B, I assume this is for bounced lighting (Global Illumination)

Doesn't look like the Alpha channel is used for Exponent, but I could be wrong

Examples

cso2_2018.de_dust2.HDR.C.tga w/ multiplied alpha:

[SomaZ]

Looks like id tech 3 deluxemaps to me. (The term is kind of weird imo. Sourceports only material ofc.) It's bascially storing the average light incident vector, so one can use normal mapping on lightmapped surfaces. Judging from the colors the vector is stored in worldspace not in tangentspace.

The other possibility is it's a bent normal map, which is indeed used often for GI implementations. This would basically tell the game where to sample from from a lighting volume like an spherical harmonics lightgrid.

From a quick glance though I'd guess its a "deluxemap". Lightspots (from the lightmaps above) create this sphere shape in this one, which is typical for this kind of map.

[snake-biscuits]

HDR.D

Alpha is almost binary, seems to be for Sun shadows
The RGB channels are bright & don't use exponent

Examples

cso2_2018.de_dust2.bsp.HDR.D.tga RGB channels only:

cso2_2018.de_dust2.bsp.HDR.D.tga Aplha channel only:

[snake-biscuits]

Titanfall used RTL's alpha channel to mask sun shadows too
Which appears to be tied to ShadowMeshes

My current theory is the sun mask clips real-time shadows
I have yet to confirm this in-game

[snake-biscuits]

3D Visualiser

Over the past few months I've been building towards remapping lightmap uvs to a Lightmap Page
Today, I have succeeded: bsp_tool_examples/valve/source_lightmap_pages.py

NOTE: At time of writing, there are a few bugs:

• Faces w/ T-junctions have broken uvs
• Lots of manual cleanup is required (separate toolsblockshadow, use Lightmap material etc.)

I'm using a similar setup to what I did with mp_corporate.gltf
Using Shader AOVs in Blender to examine each lightmap
Though this time I'm using a single shader for the whole map
Should make it easy to composite the lightmaps together in 3D too

Couldn't get away with this on a Titanfall Engine map since there's multiple of each lightmap
Blending lightmaps with .vmt shaders & comparing that to in-game will still be useful tho

2017 de_inferno

top-down view of de_inferno

using a shader to scale RGB by Exponent
it's definitely not accurate, but it's reduced banding for this screenshot

2018 de_inferno

top-down view of de_inferno (HDR.C.rgb)

selecting Shader AOV passes in the viewport to get a quick view of each lightmap

[mm535915265-png]

May I ask if you have completely resolved this issue? It has been troubling me for a very, very long time.Thank you for all you have done for everyone so far.

[snake-biscuits]

Not sure I know what you're talking about, could you be more specific?
I haven't touched this script in over a year.
Didn't realise anyone had a use for it beyond a rough data visualisation.

[mm535915265-png]

Not sure I know what you're talking about, could you be more specific? I haven't touched this script in over a year. Didn't realise anyone had a use for it beyond a rough data visualisation.

I'm referring to the 'visible banding' issue with CSO2 mentioned in this case. It's almost driving me crazy – the Lighting effect I created in CS:S has turned into a complete mess.😭

[snake-biscuits]

Spent today trying to make a visualiser to get my head around the banding:
cs02_2018_lightmap_viewer.py

Unfortunately it's ended up not being very useful
It's still a lot of work just to look at the lightmaps
Doesn't seem like it'll be easy to work out the math for the banding either

If it wasn't the middle of December I'd poke at it a little more
But currently I have a lot going on and can't spend many days on this

[mm535915265-png]

Spent today trying to make a visualiser to get my head around the banding: cs02_2018_lightmap_viewer.py

Unfortunately it's ended up not being very useful It's still a lot of work just to look at the lightmaps Doesn't seem like it'll be easy to work out the math for the banding either

If it wasn't the middle of December I'd poke at it a little more But currently I have a lot going on and can't spend many days on this

No worries, man. Thanks for your efforts anyway. I did come across someone who had fixed this issue, but the solution files were encrypted, which left me with no clue where to start. I really hope to get this sorted out soon.🥲