Engine icon indicating copy to clipboard operation
Engine copied to clipboard

Bug: Vrad generates extreme noise when compiling with low luxels scale

Open Unusuario2 opened this issue 10 months ago • 10 comments

Describe the bug

(vrad command line -StaticPropLighting -StaticPropPolys -PortalTraversalLighting -PortalTraversalAO -LargeDispSampleRadius -StaticPropLightingFinal -StaticPropBounce 16 -aoscale 0.2 -aosamples 256 -ldr -hdr -staticpropsamplescale 0.9):

Image

Note: disabling AO doesn't change anything

To Reproduce

  1. Download the map example.
  2. Compile & run the map.
  3. See the noise that should not be generated.

Issue Map

enginetest.zip

Expected Behavior

See the noise that vrad generates. (this should not happen)

Operating System

No response

Unusuario2 avatar Jan 31 '25 00:01 Unusuario2

What happens when you increase the sky samples with -extrasky N? (where N is some number) -final is the same as -extrasky 16

JJL772 avatar Jan 31 '25 00:01 JJL772

Stills is an issue in low luxels enviroments: (having large extrasky values like 32/64 makes it worst) -extrasky 16:

Image

-extrasky 32: Image

Unusuario2 avatar Jan 31 '25 01:01 Unusuario2

also seems that the lightmaps have some kind of compression which is very obvious in game, i dont know if that is the case or some weird vrad effect.

Unusuario2 avatar Jan 31 '25 01:01 Unusuario2

lightmaps in Source are stored in RGBExp32 format, so there can be quite a lot of data loss. https://github.com/ValveSoftware/source-sdk-2013/blob/master/mp/src/public/mathlib/mathlib.h#L1018-L1024 The banding becomes really obvious when using flat grey/white textures. Ideally we'd be storing lightmaps as float BC6H or something, but that's easier said than done...

JJL772 avatar Jan 31 '25 01:01 JJL772

maybe i could try changing the RGBExp32 format to B6H in the source sdk 2013 and then you guys use it as reference what so ever. Ideally the best thing would be to add a command like -format_lightmap_RGBExp32, -format_lightmap_B6H because not all the users will notice these issues (also B6H for example is larger than RBGExp32 so that could increase the weight file.)

Unusuario2 avatar Jan 31 '25 01:01 Unusuario2

Switching from RGBE to BC6H will likely more than double the file size of lightmaps, 4 bytes per pixel to 128 bytes for 16 pixel block, and also would pad every lightmap size to be multiple of 4.

SCell555 avatar Jan 31 '25 05:01 SCell555

It should compress size, BC6H is 128 bits, not bytes (16 bytes) per 4x4, so it should be 1/4 of the size

Smaedd avatar Jan 31 '25 05:01 Smaedd

The lightmaps generated by vrad are always in the same format (.vhv) besides the compresion method no? For example in the mp branch if you have lightmapped props those will be in RGBA8888 but with a custom vrad that format could be changed and everything will be fine, does this behaviour also apply to .vhv?

In source 2, valve for compressing lightmaps uses BC7 and BC6H

Image

Docs: https://learn.microsoft.com/es-es/windows/win32/direct3d11/bc6h-format
https://learn.microsoft.com/es-es/windows/win32/direct3d11/bc7-format

Also should i make a new issue about this topic?

Unusuario2 avatar Jan 31 '25 15:01 Unusuario2

vhv files are for prop vertex lighting, they are not lightmaps

ppl files are prop lightmaps and are stored differently and separately from bsp lightmaps, they are also RGB8 by default not RGBA8

craftablescience avatar Jan 31 '25 16:01 craftablescience

A workaround could be to port the bicubic filter into the shaders. Since it blurs the RGB values of the lightmaps, this would make the compression artifacts less noticeable.

Unusuario2 avatar Mar 04 '25 23:03 Unusuario2