Initial raytraced lighting progress (bevy_solari)

[JMS55]

Bevy Solari

Preface

• See release notes.
• Please talk to me in #rendering-dev on discord or open a github discussion if you have questions about the long term plan, and keep discussion in this PR limited to the contents of the PR :)

Connections

• Works towards #639, #16408.
• Spawned https://github.com/bevyengine/bevy/issues/18993.
• Need to fix RT stuff in naga_oil first https://github.com/bevyengine/naga_oil/pull/116.

This PR

After nearly two years, I've revived the raytraced lighting effort I first started in https://github.com/bevyengine/bevy/pull/10000.

Unlike that PR, which has realtime techniques, I've limited this PR to:

• RaytracingScenePlugin - BLAS and TLAS building, geometry and texture binding, sampling functions.
• PathtracingPlugin - A non-realtime path tracer intended to serve as a testbed and reference.

What's implemented?

• BLAS building on mesh load
• Emissive lights
• Directional lights with soft shadows
• Diffuse (lambert, not Bevy's diffuse BRDF) and emissive materials
• A reference path tracer with:
  • Antialiasing
  • Direct light sampling (next event estimation) with 0/1 MIS weights
  • Importance-sampled BRDF bounces
  • Russian roulette

What's not implemented?

• Anything realtime, including a real-time denoiser
• Integration with Bevy's rasterized gbuffer
• Specular materials
• Non-opaque geometry
• Any sort of CPU or GPU optimizations
  • BLAS compaction, proper bindless, and further RT APIs are things that we need wgpu to add
• PointLights, SpotLights, or skyboxes / environment lighting
• Support for materials other than StandardMaterial (and only a subset of properties are supported)
• Skinned/morphed or otherwise animating/deformed meshes
• Mipmaps
• Adaptive self-intersection ray bias
• A good way for developers to detect whether the user's GPU supports RT or not, and fallback to baked lighting.
• Documentation and actual finalized APIs (literally everything is subject to change)

End-user Usage

• Have a GPU that supports RT with inline ray queries
• Add SolariPlugin to your app
• Ensure any Mesh asset you want to use for raytracing has enable_raytracing: true (defaults to true), and that it uses the standard uncompressed position/normal/uv_0/tangent vertex attribute set, triangle list topology, and 32-bit indices.
  • If you don't want to build a BLAS and use the mesh for RT, set enable_raytracing to false.
• Add the RaytracingMesh3d component to your entity (separate from Mesh3d or MeshletMesh3d).

Testing

• Did you test these changes? If so, how?
  • Ran the solari example.
• Are there any parts that need more testing?
  • Other test scenes probably. Normal mapping would be good to test.
• How can other people (reviewers) test your changes? Is there anything specific they need to know?
  • See the solari.rs example for how to setup raytracing.
• If relevant, what platforms did you test these changes on, and are there any important ones you can't test?
  • Windows 11, NVIDIA RTX 3080.

[alice-i-cecile]

@JMS55 now that we have one review, I'd like to start wrangling a second for you. Can you get CI green for us?

[JMS55]

Everything is fixed now, just need to wait for https://github.com/bevyengine/naga_oil/pull/119 to be merged and a new naga_oil release.

[JMS55]

I've changed this PR a little in the previous commit. The monolithic sample light function has been split up into 3 separate functions:

1. Generate random light sample (pick light, pick point on light)
2. Calculate unshadowed light contribution (given light sample and point, calculate radiance from light at point, don't trace rays to test visibility)
3. Test light visibility (trace ray from given point to given light sample)

These APIs are what I've settled on based on prototyping the realtime/ReSTIR shaders.

I've also modified GpuDirectionalLight a little to move some of the calculations for solid angle / PDF from the GPU to the CPU.

[JMS55]

I think we might want to consider naming this SolariScenePlugin actually. I like having a bit of branding here. It can be done in a future PR though. It's not a blocker.

I wanted to differentiate between "raytracing infrastructure anyone can use, that's intended for external developers" (RaytracingScenePlugin) and "the specific realtime lighting stuff I'm working on" (SolariPlugin).

[alice-i-cecile]

@cart, what would you like the final crate name to be? I know that you've pushed back on fun branded names in the past for clarity purposes.

[JMS55]

The initial simplicity is appreciated.

It's going to get so much more complicated soon :)

Still simpler than virtual geometry though, by a long shot.