derpius / gmod-dxr

Garry's Mod rendered using DirectX Raytracing

Garry's Mod DXR On

Binary module that renders the GMod environment almost entirely directly using DirectX Raytracing via NVIDIA's Falcor framework.

Uses PNG textures placed in GarrysMod/bin/win64/Data/Overrides/materials with matching paths to the relative ones in an entity's VMT file (currently $basetexture and $bumpmap), and will hopefully eventually load texture data on the fly from mounted VPKs, GMAs, and filesystem addons (with the overrides folder being used for selective texture replacement, which would mainly be used for PBR textures like occlusion, metalness, and roughness).

The iterative path tracer currently handles diffuse and specular lobes of the Falcor BSDF, as well as direct lighting using analytic lights and emissives and envmap sampling with MIS (multiple importance sampling).

The accumulator and tonemapper shaders are modified versions of those found in Falcor's accumulation and tonemapping render passes, using compensated accumulation, and ACES tonemapping with auto exposure and toggleable white balance adjustment.

PBR textures are made by me using Quixel Mixer and GIMP, you can get them here.

Map surfaces will be broken until I implement loading BSPs myself, as GMod's SurfaceInfo classes are missing key faces (although unlikely, this may be due to some SurfaceInfos being present on entities other than world, which I have yet to test).

gmod-dxr's Issues

Hasn't been updated in months, outdated pre-compile.

Self-explanatory.

[feature] Name the materials to make them easier to find in the list

Describe the solution you'd like
Use the texture's filename, possibly coupled with entity ID like [57] bricks.png.

Additional context
A more long term solution would be to make a TOOL that allows assigning material properties to entities in GMod, which are then read by GModDXR.

[feature] Use a GBuffer pass instead of rays for initial hits

Describe the solution you'd like
Currently, for simplicity, initial hit positions from the camera are computed by tracing camera rays, this allows for more accurate thin lens depth of field, however doing DoF as a post processing step is far more efficient.
Given that not being able to simulate DoF directly is fine, the current method of tracing camera rays could be replaced with a far more efficient rasterised GBuffer pass, although just how much of a performance increase that would give is debateable given most of the performance hit comes from subsequent rays.

[feature] Nested transparent objects

Describe the solution you'd like
Use a stack to store the current mediums we’ve entered, then when we enter a medium, use the value at the top of the stack as the current medium, and the hit medium for refraction calcs, then push the hit medium to the stack.
When we exit a medium, pop from the stack (ie the medium we’re exiting), use the hit medium as the current medium (hit will be a backface of the thing we’re inside for exiting), and the new top of the stack as the medium we’re entering.

The only problem with this is that it assumes we start in whatever our default medium is (for most cases this will be air, or more likely vacuum), even if the camera is placed inside another medium in the scene, however allowing the user to set the default medium would mitigate this issue for most use cases, for instance an underwater render.

[feature] OptiX AI denoising?

Describe the solution you'd like
Couple the OptiX AI denoiser with the Falcor renderer, which will require conversion between Falcor textures and whatever the OptiX denoiser takes in and spits out.

Describe alternatives you've considered
Using a simple box blur with thresholds would work for direct anything and indirect diffuse surfaces, however completely ineffective for anything exhibiting indirect specular.

Additional context
https://raytracing-docs.nvidia.com/optix7/guide/index.html#ai_denoiser#nvidia-ai-denoiser

[feature] Antialiasing

Describe the solution you'd like
Implement an antialiasing pass

[feature] Migrate to Falcor 4.4

https://github.com/NVIDIAGameWorks/Falcor/releases/tag/4.4

Falcor version 4.4 has been released, and with it has come major changes that will completely break a lot of my current code, however it fixes a bunch of stuff and adds even more so the hassle of migrating is well worth it.

Only issue is I'm still mid way through implementing BDPT, so I'll probably need to wait to migrate until after that's all working.

[feature] Colour Grading LUTs

Describe the solution you'd like
Add support for the image based LUTs.

Describe alternatives you've considered
A more difficult but higher fidelity option would be to implement LUT file formats, however I doubt the visual quality increase will be distinctly better than the texture version.

Additional context
https://defold.com/tutorials/grading/
https://wwwimages2.adobe.com/content/dam/acom/en/products/speedgrade/cc/pdfs/cube-lut-specification-1.0.pdf

[feature] Bidirectional path tracing

Is your feature request related to a problem? Please describe.
While diffuse lighting already has barely any noise, indirect diffuse lighting and more importantly caustics are poor, and in the case of caustics they’re not effected by direct light.

Describe the solution you'd like
BDPT is an unbiased method for drastically reducing the variance created by these light interactions, compared to the arguably simpler to implement but biased photon mapping.

Unlike with backwards path tracing, there’s no simple step by step guides that explain the logic (e.g. scratchapixel), however after reading a paper and a few articles on it, it doesn’t seem entirely out of my reach, and wouldn’t take "much" more to upgrade to metropolis light transport.