01eff3ea93
8 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
JMS55
|
56710df934
|
bevy_solari ReSTIR DI (#19790)
# Objective - Add temporal and spatial resampling to bevy_solari. # Showcase ReSTIR:  Previous RIS:  |
||
|
atlv
|
b62b14c293
|
Add UVec to_extents helper method (#19807)
# Objective - Simplify common usecase ## Solution - Helper trait |
||
|
charlotte 🌸
|
96dcbc5f8c
|
Ugrade to wgpu version 25.0 (#19563)
# Objective Upgrade to `wgpu` version `25.0`. Depends on https://github.com/bevyengine/naga_oil/pull/121 ## Solution ### Problem The biggest issue we face upgrading is the following requirement: > To facilitate this change, there was an additional validation rule put in place: if there is a binding array in a bind group, you may not use dynamic offset buffers or uniform buffers in that bind group. This requirement comes from vulkan rules on UpdateAfterBind descriptors. This is a major difficulty for us, as there are a number of binding arrays that are used in the view bind group. Note, this requirement does not affect merely uniform buffors that use dynamic offset but the use of *any* uniform in a bind group that also has a binding array. ### Attempted fixes The easiest fix would be to change uniforms to be storage buffers whenever binding arrays are in use: ```wgsl #ifdef BINDING_ARRAYS_ARE_USED @group(0) @binding(0) var<uniform> view: View; @group(0) @binding(1) var<uniform> lights: types::Lights; #else @group(0) @binding(0) var<storage> view: array<View>; @group(0) @binding(1) var<storage> lights: array<types::Lights>; #endif ``` This requires passing the view index to the shader so that we know where to index into the buffer: ```wgsl struct PushConstants { view_index: u32, } var<push_constant> push_constants: PushConstants; ``` Using push constants is no problem because binding arrays are only usable on native anyway. However, this greatly complicates the ability to access `view` in shaders. For example: ```wgsl #ifdef BINDING_ARRAYS_ARE_USED mesh_view_bindings::view.view_from_world[0].z #else mesh_view_bindings::view[mesh_view_bindings::view_index].view_from_world[0].z #endif ``` Using this approach would work but would have the effect of polluting our shaders with ifdef spam basically *everywhere*. Why not use a function? Unfortunately, the following is not valid wgsl as it returns a binding directly from a function in the uniform path. ```wgsl fn get_view() -> View { #if BINDING_ARRAYS_ARE_USED let view_index = push_constants.view_index; let view = views[view_index]; #endif return view; } ``` This also poses problems for things like lights where we want to return a ptr to the light data. Returning ptrs from wgsl functions isn't allowed even if both bindings were buffers. The next attempt was to simply use indexed buffers everywhere, in both the binding array and non binding array path. This would be viable if push constants were available everywhere to pass the view index, but unfortunately they are not available on webgpu. This means either passing the view index in a storage buffer (not ideal for such a small amount of state) or using push constants sometimes and uniform buffers only on webgpu. However, this kind of conditional layout infects absolutely everything. Even if we were to accept just using storage buffer for the view index, there's also the additional problem that some dynamic offsets aren't actually per-view but per-use of a setting on a camera, which would require passing that uniform data on *every* camera regardless of whether that rendering feature is being used, which is also gross. As such, although it's gross, the simplest solution just to bump binding arrays into `@group(1)` and all other bindings up one bind group. This should still bring us under the device limit of 4 for most users. ### Next steps / looking towards the future I'd like to avoid needing split our view bind group into multiple parts. In the future, if `wgpu` were to add `@builtin(draw_index)`, we could build a list of draw state in gpu processing and avoid the need for any kind of state change at all (see https://github.com/gfx-rs/wgpu/issues/6823). This would also provide significantly more flexibility to handle things like offsets into other arrays that may not be per-view. ### Testing Tested a number of examples, there are probably more that are still broken. --------- Co-authored-by: François Mockers <mockersf@gmail.com> Co-authored-by: Elabajaba <Elabajaba@users.noreply.github.com> |
||
|
dependabot[bot]
|
c7b5bc93c3
|
Update derive_more requirement from 1 to 2 (#19671)
Updates the requirements on [derive_more](https://github.com/JelteF/derive_more) to permit the latest version. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/JelteF/derive_more/releases">derive_more's releases</a>.</em></p> <blockquote> <h2>2.0.1</h2> <p><a href="https://docs.rs/derive_more/2.0.1">API docs</a> <a href="https://github.com/JelteF/derive_more/blob/v2.0.1/CHANGELOG.md#201---2025-02-03">Changelog</a></p> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/JelteF/derive_more/blob/master/CHANGELOG.md">derive_more's changelog</a>.</em></p> <blockquote> <h2>2.0.1 - 2025-02-03</h2> <h3>Added</h3> <ul> <li>Add crate metadata for the Rust Playground. This makes sure that the Rust Playground will have all <code>derive_more</code> features available once <a href="https://docs.rs/selectors/latest/selectors"><code>selectors</code></a> crate updates its <code>derive_more</code> version. (<a href="https://redirect.github.com/JelteF/derive_more/pull/445">#445</a>)</li> </ul> <h2>2.0.0 - 2025-02-03</h2> <h3>Breaking changes</h3> <ul> <li><code>use derive_more::SomeTrait</code> now imports macro only. Importing macro with its trait along is possible now via <code>use derive_more::with_trait::SomeTrait</code>. (<a href="https://redirect.github.com/JelteF/derive_more/pull/406">#406</a>)</li> <li>Top-level <code>#[display("...")]</code> attribute on an enum now has defaulting behavior instead of replacing when no wrapping is possible (no <code>_variant</code> placeholder). (<a href="https://redirect.github.com/JelteF/derive_more/pull/395">#395</a>)</li> </ul> <h3>Fixed</h3> <ul> <li>Associated types of type parameters not being treated as generics in <code>Debug</code> and <code>Display</code> expansions. (<a href="https://redirect.github.com/JelteF/derive_more/pull/399">#399</a>)</li> <li><code>unreachable_code</code> warnings on generated code when <code>!</code> (never type) is used. (<a href="https://redirect.github.com/JelteF/derive_more/pull/404">#404</a>)</li> <li>Ambiguous associated item error when deriving <code>TryFrom</code>, <code>TryInto</code> or <code>FromStr</code> with an associated item called <code>Error</code> or <code>Err</code> respectively. (<a href="https://redirect.github.com/JelteF/derive_more/pull/410">#410</a>)</li> <li>Top-level <code>#[display("...")]</code> attribute on an enum being incorrectly treated as transparent or wrapping. (<a href="https://redirect.github.com/JelteF/derive_more/pull/395">#395</a>)</li> <li>Omitted raw identifiers in <code>Debug</code> and <code>Display</code> expansions. (<a href="https://redirect.github.com/JelteF/derive_more/pull/431">#431</a>)</li> <li>Incorrect rendering of raw identifiers as field names in <code>Debug</code> expansions. (<a href="https://redirect.github.com/JelteF/derive_more/pull/431">#431</a>)</li> <li>Top-level <code>#[display("...")]</code> attribute on an enum not working transparently for directly specified fields. (<a href="https://redirect.github.com/JelteF/derive_more/pull/438">#438</a>)</li> <li>Incorrect dereferencing of unsized fields in <code>Debug</code> and <code>Display</code> expansions. (<a href="https://redirect.github.com/JelteF/derive_more/pull/440">#440</a>)</li> </ul> <h2>0.99.19 - 2025-02-03</h2> <ul> <li>Add crate metadata for the Rust Playground.</li> </ul> <h2>1.0.0 - 2024-08-07</h2> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href=" |
||
|
JMS55
|
0518eda2ad
|
bevy_solari: RIS for Direct Lighting (#19620)
# Objective - Start the realtime direct lighting work for bevy solari ## Solution - Setup all the CPU-side code for the realtime lighting path (minus some parts for the temporal reuse I haven't written yet) - Implement RIS with 32 samples to choose a good random light - Don't sample a disk for the directional light, just treat it as a single point. This is faster and not much worse quality. ## Future - Spatiotemporal reuse (ReSTIR DI) - Denoiser (DLSS-RR) - Light tile optimization for faster light selection - Indirect lighting (ReSTIR GI) ## Testing - Run the solari example to see realtime - Run the solari example with `-- --pathtracer` to see the existing pathtracer --- ## Showcase 1 frame direct lighting:  Accumulated pathtracer output:  --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com> |
||
|
github-actions[bot]
|
a466084167
|
Bump Version after Release (#19774)
Bump version after release This PR has been auto-generated Fixes #19766 --------- Co-authored-by: Bevy Auto Releaser <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: François Mockers <francois.mockers@vleue.com> Co-authored-by: François Mockers <mockersf@gmail.com> |
||
|
atlv
|
2915a3b903
|
rename GlobalTransform::compute_matrix to to_matrix (#19643)
# Objective - compute_matrix doesn't compute anything, it just puts an Affine3A into a Mat4. the name is inaccurate ## Solution - rename it to conform with to_isometry (which, ironically, does compute a decomposition which is rather expensive) ## Testing - Its a rename. If it compiles, its good to go --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com> |
||
|
JMS55
|
bab31e3777
|
Initial raytraced lighting progress (bevy_solari) (#19058)
# Bevy Solari <img src="https://github.com/user-attachments/assets/94061fc8-01cf-4208-b72a-8eecad610d76" width="100" /> ## 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. --------- Co-authored-by: atlv <email@atlasdostal.com> Co-authored-by: IceSentry <IceSentry@users.noreply.github.com> Co-authored-by: Carter Anderson <mcanders1@gmail.com> |