bevyengine
Solari tracking issue
This is the tentative roadmap/list of missing features/general ideas for Solari raytraced lighting.
Performance:
- Half-resolution GI
- Upper limit on number of world cache cells updated per frame to prevent expensive world cache update step for larger scenes
Specular GI quality:
- Specular motion vectors (https://github.com/JMS55/bevy/tree/solar6-specular-mv)
- Retry VNDF sampling when pointing towards self(?)
- Try ReSTIR for specular (either same pass as diffuse, or separate)
GI Quality:
- Screen-space traces
- Use ambient occlusion to modulate GI spatial resampling (https://blog.traverseresearch.nl/dynamic-diffuse-global-illumination-b56dc0525a0a, https://research.nvidia.com/labs/rtr/publication/zeng2025restirpg)
- Or near-far field split https://github.com/EmbarkStudios/kajiya/blob/main/docs/gi-overview.md#micro-detail
DI Quality:
- GPU-based light builder, assigning weights to each triangle/mesh relative to total emission
- LTC light sampling/shading
- Megalights-style light list, but world-space
Features:
- Transparent and alpha masked materials
- Custom materials
- Skinned and morphed meshes
- PointLight, SpotLight, Skybox/EnviornmentMapLight/Atmosphere lighting
Misc:
- Docs
- Disocclusion boost
- Mipmap support (use highest mip for GI)
- Better MIS algorithms for DI and GI resampling
- Try splitting up world_cache_update direct/indirect into two passes and see if it improves perf
- Add tracy GPU timestamps to TLAS/BLAS builds and compaction
- F16 BLAS's
- Don't regenerate the scene bindings every frame (requires better bindless support in wgpu)
- Shader execution reordering (requires wgpu support)
- AMD/Intel/macOS compatible denoisers (either a NRD-like fallback, or wait until they release a DLSS-RR like feature)
- Build/compact BLAS's on async compute (requires wgpu support for async compute)
- Compute temporal variance estimate, pass to DLSS-RR as confidence factor?
- DLSS-RR seems to randomly stop working well and have blurry/noisy results at very specific camera positions. Moving slightly tends to fix it.
- ReSTIR GI validation frames
- Firefly filter(?) (not sure if needed with DLSS-RR)
- Give users more control over Solari
- Initial DI sample count
- Temporal history length
- Neighbor/temporal rejection heuristics
- Mixing Solari GI with rasterized DI
- Using Solari DI only for local lights, and having a dedicated ray for a directional light
I am not familiar with the difficulty of doing so, but I would strongly prefer if GI lighting could be an option --- perhaps at very low quality --- without dedicated hardware. (I recall seeing someone implement single-bounce DDGI without raytracing hardware, for instance)
There are certain genres of games that are basically impossible to build without some form of approximate GI (e.g. basebuilding games that don't want interior spaces to have drastically different lighting for low graphics (no GI) and high graphics (yes GI) settings)
I am not familiar with the difficulty of doing so, but I would strongly prefer if GI lighting could be an option --- perhaps at very low quality --- without dedicated hardware. (I recall seeing someone implement single-bounce DDGI without raytracing hardware, for instance)
Not necessarily hard when something like https://github.com/DGriffin91/obvhs exists for building the BVH, but it would take a lot of effort to add. Someone else is welcome to implement it, but it's not something I'm planning on doing myself.
I'm also designing the SolariLighting plugin around hardware RT capabilities. Something like pure DDGI, or stochastic light sampling like Tiny Glade did, is probably much more appropriate for software-based RT. The ReSTIR-based algorithms I'm implementing are likely too expensive for software-based RT.
To make skinned and morphed meshes work with Solari the skinning and morphs have to be computed in advance (before building BLAS) via a compute pre-pass instead of being calculated in-time in very raster pass (which is the current implementation). So I mention #7502 here for reference and dependency.
