TLAS creation pattern ended up allocating memory in a temporary region. It was later reused for BLAS data, and subsequently corrupted by TLAS rebuild.
Also fixed memory leak, added freeze-models command, added model debug code into shaders, etc.
Unfortunately Xash3D doesn't allow us to destroy models properly.
It doesn't call Mod_ProcessRenderData for all brush models (only map).
And by the time we get into R_Shutdown all models are already gone, so
we can't enumerate and destroy them properly.
Toilet contained brush model with presumably water surfaces which
were not loaded due to how we treat surface flags. That ended up
creating a model with no geometries, which is just rude.
We don't try to render those kind of models now.
use bsp/pvs-based visibility data for acceleration:
+ fps 5 -> 60
- correctness: some areas have too many lights, which ends up culling visible ones too
also fix shadow artefacts
This is a massive hack, because we hardcoded some valve/lights.rad file
right into vk_rtx.c, and this is most certainly is not correct data. We
expect maps to have more custom rad file entries.
TODO: consult https://github.com/MaestroFenix/Half-Life-Resized-Maps
Also, emissive surfaces are no importance sampled, so it's noise fest.
This was an attempt to add map lighting w/o lightmaps. Unfortunately
there are just not enought of them to explain all light in maps. We're
missing something else. A lot of it.
Now each geometry is first allocated a slot with VK_RenderBufferAlloc,
and then VK_RenderBufferLock/Unlock are used to upload buffer contents.
This allow for two things:
1. Uploading buffer data to GPU memory on/after Unlock.
2. (Re)building BLAS for RTX on/after Unlock.
These buffers are now directly referenced by render_draw_t, which also
will be helpful in the future for both renderers.
Disable depth test and set dst blend factor to 1 for kRenderGlow mode.
Sprites are occluded in software.
(does this break any other code depending on Glow mode? who knows)
Now rendering submodules specify their colors and matrices using
VK_RenderState global stat api. This is a trade-off between making all
submodules track their state on their own, or managing that state
centrally.
not all beam types are supported yet
also changes studio api init sequence, fixes missing cvars
vertex type struct is no longer names as brush-specific
uniform buffer allocation is now in vk_render
blending issues still remain