Base lights.rad/valve.rad from worldcraft v2.0 or HLSDK (thx Valve).
Base c1a0.rad and c1a0d.rad from HLSDK (thx Valve).
Some texture name get from hl_lights.rad by Hezus (thx Hezus and SNMetamorph for file).
Others was mined by me manually through bspguy and etc.
File structure and formatting redesigned.
Some numbers have been rounded for convenience.
Added splitting by WAD files (for the present only for lights.rad).
See README.txt for codestyle.
New Vulkan SDK (1.2.189.2) has a new validation check that verifies that AS build scratch buffer has been created with VK_BUFFER_USAGE_STORAGE_BUFFER_BIT.
The core of the issue is that there are backfacing interpolated normals, NdotL and/or NdotV end up being negative for them.
Things we tried:
1. Explicitly using geometry normals for some things. Doesn't really work that well.
2. Clamping NdotX to some small value instead of just ignoring light contribution. Works better, but there are still some artifacts.
1. I suspect that we don't actually need to compute emissive contribution even for specular. Except when doing direct lighting.
2. Using emissive color as is looks orders of magnitude too bright. It should be scaled by something. But by what? Try to use to-metric mapping similar to direct lighting for testing.
It was missing msurface_t reference which is (unnecessarily) required for light clusters computation
Also add more verbose debug names for dynamic models.
how: we do not need to add emissive when doing diffuse gi bounce, as contribution from these lights will be computed in computeLighting.
They only need to be sampled for specular bounce.
The rest of the acne should be mitigated by denoiser i think.
Fix#51
1. Probabilistically let ray through material or reflect it based on
transparency probability (which is essentially just alpha for now).
2. Introduce opaque flag to be able to treat transparent objects as not
casting shadows. This is not very realistic, but oh well.
Remove arbitrary lightness fudge in favor of proper distance scaling.
According to TEH INTERNETS one unit is one inch. So there are 39.37 units per meter.
Scale distances to meters for lighting calculations.
now vulkan can do screenshots too. however, it depends on blits being
available between swapchain and rgba8 formats, so if it's not the case
for some reason, the resulting image will have mixed components.
after we've updated how brush index buffer references vertices to allow
for draw call coalescing ray tracing broke on amd.
this is because amd cards expect a correct value in
VkAccelerationStructureGeometryTrianglesDataKHR::maxVertex. make sure we
fill a correct value there.
make all geoms share the same constant vertex offset so that continuous indices can be exploited to generate only a single draw call for a group of geometries with the same texture
from: Mark Jarzynski and Marc Olano, Hash Functions for GPU Rendering, Journal of Computer Graphics Techniques (JCGT), vol. 9, no. 3, 21-38, 2020
http://www.jcgt.org/published/0009/03/02/
this is mostly copied from ray tracing gems 2 chapter 7 (Texture Coordinate Gradients Estimation for Ray Cones, by Wessam Bahnassi).
There's a weird bit about radians vs degrees. We'll figure it out later when the book becomes available.
this is very proof-of-concept quality. it should be definitely done some other way
e.g. we should control reflectivity and transparency differently (and not together)
and they should be based on texture ids, not on render_mode
it's also unfortunate that transparency required a lot of bounces. we should probably control transparency bounces separately from light bounces.
alternatively, transparency effects (beams, sprites) should be done with custom intersection shaders and not based on transparent geometry
We used to dispatch rays anyway even if there was no models to render and tlas wasn't built (which is the case for the first few frames).
This ended up crashing AMD gpu when using some (but not all) variants of rgen shaders.
With this change we'll check for whether there are any models to render, and if there are none, then we'll just clear frame to black.
This change also refactors ray tracing a bit.
for some reason amd will lose device whenever the first rendered frame has multiple push-constant-depndent bounces and break on line 138 in rgen.
when both break is commented out and bounces are compile-time constant, it will work just fine.
moreover, if we start xash with the workaround shader, get it to draw a few frames, and only then bring back both break and pc-bounces, recompile and reload shader, it will run just fine. not losing device and all.
wtf
- use non-uniform indexing because AMD requires it (which is technically correct by spec, it's just nvidia that supports it transparently)
- disable immutable samplers, as that breaks filtering on amd for some reason (TODO)
on amd gpus it won't draw anything at all unless you have the entire ray tracing pipeline set up fully and correctly:
- have at least rgen, rmiss and rchit shaders
- set up shader groups to reference them
- set up sbt to reference shader groups
it is not enough to just have a single rgen shader operating like a compute shader. amd will have a shader preamble that checks for something and exit early w/o actually running any shader code you wrote
meh
An incorrect range of used vertices was pased into `VkAccelerationStructureGeometryTrianglesDataKHR`.
`maxVertex` was being set to a count of vertices per geometry, not a maximum used vertex number.
The fix is to track `vertex_offset` of the first used vertex, which makes `maxVertex` correct.
track brush models movement and update lights grid clusters with model transform and stuff
also implement animated textures for rtx
and also increase per-cluster lights limits
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.
we were mixing up row vs column major matrices
now RTX ray generation is fixes, and traditional rasterizer rendering
should also be projecting similar to gl render
this basically checks that acceleration structurs are building without
any vulkan errors (we still don't know whether they are bulding with
correct geometry though).
we also have compute shader pipeline ready for ray tracing (yay)
but it doesn't do any raytracing yet
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
RI.drawMode affects how time is interpreted for models, so make sure it
uses the correct time
implement indexing for model rendering -- this fixes weird holes
Lightstyles remain fixed for the entire map duration. Need to implement either texture reupload in VK, or devise some other scheme of updating ligtmaps w/o texture reupload (lightstylevalues uniform buffers?).
We were missing this, and as a result entities list got filled up within
a few frames, which resulted in:
- too many draw calls per frame, same entities were drawn many times
over
- missing entities: if an entity didn't get to that list within a few
first frames, then it wouldn't be rendered ever
This extension allows adding labels to vulkan objects and insert string
labels into command buffers. This is visible in tools like RenderDoc and
helps with debugging a lot.
When running with -vkdebug:
- mark all texture VkImages and VkImageViews with corresponding names
- label brush model draw calls accordingly
1. Improve performance by coalescing multiple surfaces/draw calls with
the same textures (within a single brush model).
2. Add lightmaps. We don't support lightstyles yet, though, so they seem
a bit wrong at times. Also gamma handling is not great.
Oh well.
it's now *very slow* because every surface (which is just a few polys)
gets its own draw call and descriptor bind. F
we also had to make default sampler repeating, so now 2d textures in
menu have weird edge artifacts. also F
making progress i guess
