Bug: Vrad generates extreme noise when compiling with low luxels scale
Describe the bug
(vrad command line -StaticPropLighting -StaticPropPolys -PortalTraversalLighting -PortalTraversalAO -LargeDispSampleRadius -StaticPropLightingFinal -StaticPropBounce 16 -aoscale 0.2 -aosamples 256 -ldr -hdr -staticpropsamplescale 0.9):
Note: disabling AO doesn't change anything
To Reproduce
- Download the map example.
- Compile & run the map.
- See the noise that should not be generated.
Issue Map
Expected Behavior
See the noise that vrad generates. (this should not happen)
Operating System
No response
What happens when you increase the sky samples with -extrasky N? (where N is some number)
-final is the same as -extrasky 16
Stills is an issue in low luxels enviroments: (having large extrasky values like 32/64 makes it worst) -extrasky 16:
-extrasky 32:
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.
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...
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.)
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.
It should compress size, BC6H is 128 bits, not bytes (16 bytes) per 4x4, so it should be 1/4 of the size
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
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?
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
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.