Devsh-Graphics-Programming
Path Tracer V2
Description
This one is really hard to start because there's a lot of required moving parts.
Goals
Integrate Denoiser and Post Processing into the Sample
Probably need an ext::BasicDenoiser:
- must be able to process an image in tiles or as multiple images (for 256 Megapixel renders)
- use Dependency Injection to allow different denoisers
- use Dependency Injection to allow different blooms (FFT, Box Blur)
- use Dependency Injection to allow different autoexposers
- use Dependency Injection to allow different tonemappers
Need to allow for overridable store/load of image data as OptiX is weird and only does Buffers for pixels, not images.
Write small wrappers to adapt existing extensions to new interfaces.
Factor out raytraceCommon.glsl into an ext::PathTracer
Obviously a compute shader megakernel, but make it easy to replace with an impl based off KHR_raytracing_pipeline.
Be agnostic of (have separate GLSL modules provide):
- random number generator and per pixel sequences
- ray generation
- acceleration structure traversal
- materials
- path guiding
- nee implementation
- accumulation of samples
Being agnostic of raygen and accumulation lets us be oblivious to adaptive sampling.
Need to be able to handle:
- setting up new viewports
- rendering different/new rectangles in the image
- suspension of rendering (rendering by time [adaptive] , not spp)
- choice of AoV output for denoiser
Gradually evolve towards:
- Covariance Tracing for BxDF functions
- Material Compiler refactor of functions
Do a semi rewrite of existing example 22
Port what can be ported, backfill anything that can't with a "test harness".
Application Framework
Start by using ex 42 as a starting base. Backport the refactor and rewrite ex 42 to use the ext.
AS traversal harness
Use ex 42 ball traversal.
Material harness
Use ex 42 material impl and table, then use material compiler again.
NEE harness
Use ex 42 light modes, then just use a function that always fails to pick a light.
Path Guiding harness
Use our envmap RIS.
Features
Toggleable Post Processing stack
Disable/Enable denoiser, tonemap and bloom.
Scene Reload
While saving sensor ID and transformation.
GUI
For adjusting denoiser, RWMC, and tonemap+bloom.
Scene Edit
Instances, Textures and Materials need to have string names and UUIDs.
Serialization
We need to come up with our own way of serializing the scene and reloading it which is not Mitsuba.
Material Edit
In order to be able to support runtime edit, Material Compiler backends should defer optimization of the VM (make it optional).
Live Edit
A little Node Based Editor for our Material IR in GUI.
Add
Could support reading Mitsuba XML files of just materials.
Remove
By clicking a dropdown list in GUI.
Texture Edit
Requires our virtual texturing or descriptor indexing to be able to add/remove textures at runtime.
Replace
This would be hard on the VT as the page table alloc/handle would change.
Add
Relatively straight forward.
Delete
Would need to go through material compiler's output and safely neuter any references to the texture.
Instance Edit
Picking
Being able to pick the geometry on screen or a searchable list.
Also support multi-pick.
Warning: The geometry could be diced up into multiple parts thanks for BVH rethreading.
Delete
Remove from scene.
Transformation
First via GUI, then add gimbals.
For multi-pick compute the compound transform as the transform of the OBB.
Clone
Add a copy of the picked items.
Add
File Open dialog for the model and drop-down list of materials to pick.
Related
https://github.com/Devsh-Graphics-Programming/Nabla/issues/297 https://github.com/Devsh-Graphics-Programming/Nabla/issues/310