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 Ray tracing support? #639, UE5 Megalights-like #16408.
• Spawned StandardMaterial::emissive units not documented #18993.
• Need to fix RT stuff in naga_oil first Hardcode fix for RT naga_oil#116.

This PR

After nearly two years, I've revived the raytraced lighting effort I first started in #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.

[cart]

This is exciting! The initial simplicity is appreciated.

[cart]

This seems fine for demo purposes. I'd prefer it if ultimately raytracing could reuse the existing Mesh3d by default (as the component-swapping UX isn't great). Solvable problem / Im pretty sure I understand why you went for this in the short term (removing Mesh3d opts out of the normal rendering flow).

[JMS55]

Did you read the docs on RaytracingMesh3d? It was an intentional choice to allow using lower-resolution proxy meshes for RT (and to allow using proxy meshes for MeshletMeshes).

We could make reusing Mesh3d the default I suppose, and RaytracingMesh3d opt-in, but I'm not sure how I feel about that. I'll give it some more thought, it's not a bad idea.

[cart]

Yup! An opt-in override component makes way more sense to me from a UX perspective.

[JMS55]

Also yes removing Mesh3d here for the pathtracer is to opt-out of the normal rendering path.

The realtime stuff won't do that.

[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.