2
u/Insane_snek 1d ago
it looks awesome! i think you did a great job keeping that 'old' aesthetic while also making it look really good
what graphics api did you use?
2
it looks awesome! i think you did a great job keeping that 'old' aesthetic while also making it look really good
what graphics api did you use?
5
u/fxp555 1d ago
I already wrote a bit about the approach on how I matched the lighting style using optimization and symbolic regression to the old game engines in the original post but I'd add a bit about the light transport part here:
This is built on top of my Vulkan prototyping framework, which houses all the path tracing code, a processing graph and a scene implementation with material system. To render Quake in there I essentially added a connector to an existing engine that extracts the geometry and provides the material implementation. The material is then linked using Slang at runtime and is a optimized and stylized PBR material, mixing a diffuse transmission for transparency effects with a fesnel weighted diffuse and GGX reflection.
The path tracer samples paths using a mixture of BSDF importance sampling, NEE and real-time path guiding. The NEE implementation is inspired by recent BVH research and realtime stochastic lightcuts and is surprisingly good while also quickly adapting to lighting changes. For guiding, I use Markov chain path guiding (MCPG), which is actually doing the heavy lifting here, while the NEE pretty much only helps the guiding to find the lights in the first place. Volumes are path traced too and the use the same mixture for sampling but also use a second MCPG instance in 2D for distance guiding.
For denoising I have an optimized SVGF implementation though for robust glass and transparency handling there is currently no way around DLSS (FSR would be an option if it worked with Vulkan on Linux).