forked from bevyengine/bevy
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cluster light probes #6
Merged
pcwalton
merged 1,004 commits into
pcwalton:cluster-light-probes
from
BenjaminBrienen:cluster-light-probes
Oct 18, 2024
Merged
Cluster light probes #6
pcwalton
merged 1,004 commits into
pcwalton:cluster-light-probes
from
BenjaminBrienen:cluster-light-probes
Oct 18, 2024
+120,305
−49,225
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# Objective Add the following system params: - `QuerySingle<D, F>` - Valid if only one matching entity exists, - `Option<QuerySingle<D, F>>` - Valid if zero or one matching entity exists. As @chescock pointed out, we don't need `Mut` variants. Fixes: bevyengine#15264 ## Solution Implement the type and both variants of system params. Also implement `ReadOnlySystemParam` for readonly queries. Added a new ECS example `fallible_params` which showcases `SingleQuery` usage. In the future we might want to add `NonEmptyQuery`, `NonEmptyEventReader` and `Res` to it (or maybe just stop at mentioning it). ## Testing Tested with the example. There is a lot of warning spam so we might want to implement bevyengine#15391.
…bevyengine#15496) # Objective - Resolves bevyengine#15453 ## Solution - Added new `World::resource_id` and `World::register_resource` methods to support this feature - Added new `ReflectResource::register_resource` method, and new pointer to this new function - Added new `ReflectComponent::register_component` ## Testing - Tested this locally, but couldn't test the entire crate locally, just this new feature, expect that CI will do the rest of the work. --- ## Showcase ```rs #[derive(Component, Reflect)] #[reflect(Component)] struct MyComp; let mut world = World::new(); let mut registry = TypeRegistration::of::<MyComp>(); registry.insert::<ReflectComponent>(FromType::<MyComp>::from_type()); let data = registry.data::<ReflectComponent>().unwrap(); // Its now possible to register the Component in the world this way let component_id = data.register_component(&mut world); // They will be the same assert_eq!(component_id, world.component_id::<MyComp>().unwrap()); ``` ```rs #[derive(Resource, Reflect)] #[reflect(Resource)] struct MyResource; let mut world = World::new(); let mut registry = TypeRegistration::of::<MyResource>(); registry.insert::<ReflectResource>(FromType::<MyResource>::from_type()); let data = registry.data::<ReflectResource>().unwrap(); // Same with resources let component_id = data.register_resource(&mut world); // They match assert_eq!(component_id, world.resource_id::<MyResource>().unwrap()); ```
# Objective Fixes bevyengine#15503 ## Solution Move the use ## Testing Compiled with `cargo build --no-default-features --features bevy_gltf` successfully. ## Showcase ![image](https://github.com/user-attachments/assets/b5637e0e-2af9-4b8e-bf24-b378775d3f10)
# Objective - Fixes bevyengine#15504
* Save 16 bytes per vertex by calculating tangents in the shader at runtime, rather than storing them in the vertex data. * Based on https://jcgt.org/published/0009/03/04, https://www.jeremyong.com/graphics/2023/12/16/surface-gradient-bump-mapping. * Fixed visbuffer resolve to use the updated algorithm that flips ddy correctly * Added some more docs about meshlet material limitations, and some TODOs about transforming UV coordinates for the future. ![image](https://github.com/user-attachments/assets/222d8192-8c82-4d77-945d-53670a503761) For testing add a normal map to the bunnies with StandardMaterial like below, and then test that on both main and this PR (make sure to download the correct bunny for each). Results should be mostly identical. ```rust normal_map_texture: Some(asset_server.load_with_settings( "textures/BlueNoise-Normal.png", |settings: &mut ImageLoaderSettings| settings.is_srgb = false, )), ```
…bevyengine#15361) # Objective - Fixes: bevyengine#14451 ## Solution - Adding volumetric fog sampling code for both point lights and spotlights. ## Testing - I have modified the example of volumetric_fog.rs by adding a volumetric point light and a volumetric spotlight. https://github.com/user-attachments/assets/3eeb77a0-f22d-40a6-a48a-2dd75d55a877
…evyengine#15526) # Objective Fixes bevyengine#15394 ## Solution Observers now validate params. System registry has a new error variant for when system running fails due to invalid parameters. Run once now returns a `Result<Out, RunOnceError>` instead of `Out`. This is more inline with system registry, which also returns a result. I'll address warning messages in bevyengine#15500. ## Testing Added one test for each case. --- ## Migration Guide - `RunSystemOnce::run_system_once` and `RunSystemOnce::run_system_once_with` now return a `Result<Out>` instead of just `Out` --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com> Co-authored-by: Zachary Harrold <zac@harrold.com.au>
# Objective - fixes bevyengine#13473 ## Solution - When a single mesh is assigned multiple materials, it is divided into several primitive nodes, with each primitive assigned a unique material. Presently, these primitives are named using the format Mesh.index, which complicates querying. To improve this, we can assign a specific name to each primitive based on the material’s name, since each primitive corresponds to one material exclusively. ## Testing - I have included a simple example which shows how to query a material and mesh part based on the new name component. ## Changelog - adds `GltfMaterialName` component to the mesh entity of the gltf primitive node. --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective This implements another item on the way to complete the `Curves` implementation initiative Citing @mweatherley > Curve adaptors for making a curve repeat or ping-pong would be useful. This adds three widely applicable adaptors: - `ReverseCurve` "plays" the curve backwards - `RepeatCurve` to repeat the curve for `n` times where `n` in `[0,inf)` - `ForeverCurve` which extends the curves domain to `EVERYWHERE` - `PingPongCurve` (name wip (?)) to chain the curve with it's reverse. This would be achievable with `ReverseCurve` and `ChainCurve`, but it would require the use of `by_ref` which can be restrictive in some scenarios where you'd rather just consume the curve. Users can still create the same effect by combination of the former two, but since this will be most likely a very typical adaptor we should also provide it on the library level. (Why it's typical: you can create a single period of common waves with it pretty easily, think square wave (= pingpong + step), triangle wave ( = pingpong + linear), etc.) - `ContinuationCurve` which chains two curves but also makes sure that the samples of the second curve are translated so that `sample(first.end) == sample(second.start)` ## Solution Implement the adaptors above. (More suggestions are welcome!) ## Testing - [x] add simple tests. One per adaptor --------- Co-authored-by: eckz <567737+eckz@users.noreply.github.com> Co-authored-by: Matty <2975848+mweatherley@users.noreply.github.com> Co-authored-by: IQuick 143 <IQuick143cz@gmail.com> Co-authored-by: Matty <weatherleymatthew@gmail.com> Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
) # Objective - Fixes bevyengine#15077 ## Solution - Clears `ViewTargetAttachments` resource every frame before `create_surfaces` system instead, which was previously done after `extract_windows`. ## Testing - Confirmed that examples no longer panic on window resizing with DX12 backend. - `screenshot` example keeps working after this change.
# Objective Improve the documentation of `SystemParamBuilder`. Not all builder types have documentation, and the documentation is spread around and not linked together well. ## Solution Reorganize `SystemParamBuilder` docs and examples. All builder types now have their own examples, and the list of builder types is linked from the `SystemParamBuilder` trait. Add some examples to `FilteredEntityRef` and `FilteredEntityMut` so that `QueryParamBuilder` can reference them.
…5158) # Objective - `DynamicMap` currently uses an `HashMap` from a `u64` hash to the entry index in a `Vec`. This is incorrect in the presence of hash collisions, so let's fix it; - `DynamicMap::remove` was also buggy, as it didn't fix up the indexes of the other elements after removal. Fix that up as well and add a regression test. ## Solution - Use `HashTable` in `DynamicMap` to distinguish entries that have the same hash by using `reflect_partial_eq`, bringing it more in line with what `DynamicSet` does; - Reimplement `DynamicMap::remove` to properly fix up the index of moved elements after the removal. ## Testing - A regression test was added for the `DynamicMap::remove` issue. --- Some kinda related considerations: the use of a separate `Vec` for storing the entries adds some complications that I'm not sure are worth. This is mainly used to implement an efficient `get_at`, which is relied upon by `MapIter`. However both `HashMap` and `BTreeMap` implement `get_at` inefficiently (and cannot do so efficiently), leading to a `O(N^2)` complexity for iterating them. This could be removed in favor of a `Box<dyn Iterator>` like it's done in `DynamicSet`.
…evyengine#15202) # Objective - Fix panic when atlas index is out of bounds - Took the chance to clean it up a bit ## Solution - Use texture dimensions like rendering pipeline. Dropped atlas layouts and indexes out of bounds are shown as a sprite. ## Testing Used sprite_picking example, drop layout and/or use indexes out of bounds.
…tureAtlasLayout` serializable (bevyengine#15344) # Objective Mostly covers the first point in bevyengine#13713 (comment) The idea here is that a lot of people want to load their own texture atlases, and many of them do this by deserializing some custom version of `TextureAtlasLayout`. This makes that a little easier by providing `serde` impls for them. ## Solution In order to make `TextureAtlasLayout` serializable, the custom texture mappings that are added by `TextureAtlasBuilder` were separated into their own type, `TextureAtlasSources`. The inner fields are made public so people can create their own version of this type, although because it embeds asset IDs, it's not as easily serializable. In particular, atlases that are loaded directly (e.g. sprite sheets) will not have a copy of this map, and so, don't need to construct it at all. As an aside, since this is the very first thing in `bevy_sprite` with `serde` impls, I've added a `serialize` feature to the crate and made sure it gets activated when the `serialize` feature is enabled on the parent `bevy` crate. ## Testing I was kind of shocked that there isn't anywhere in the code besides a single example that actually used this functionality, so, it was relatively straightforward to do. In bevyengine#13713, among other places, folks have mentioned adding custom serialization into their pipelines. It would be nice to hear from people whether this change matches what they're doing in their code, and if it's relatively seamless to adapt to. I suspect that the answer is yes, but, that's mainly the only other kind of testing that can be added. ## Migration Guide `TextureAtlasBuilder` no longer stores a mapping back to the original images in `TextureAtlasLayout`; that functionality has been added to a new struct, `TextureAtlasSources`, instead. This also means that the signature for `TextureAtlasBuilder::finish` has changed, meaning that calls of the form: ```rust let (atlas_layout, image) = builder.build()?; ``` Will now change to the form: ```rust let (atlas_layout, atlas_sources, image) = builder.build()?; ``` And instead of performing a reverse-lookup from the layout, like so: ```rust let atlas_layout_handle = texture_atlases.add(atlas_layout.clone()); let index = atlas_layout.get_texture_index(&my_handle); let handle = TextureAtlas { layout: atlas_layout_handle, index, }; ``` You can perform the lookup from the sources instead: ```rust let atlas_layout = texture_atlases.add(atlas_layout); let index = atlas_sources.get_texture_index(&my_handle); let handle = TextureAtlas { layout: atlas_layout, index, }; ``` Additionally, `TextureAtlasSources` also has a convenience method, `handle`, which directly combines the index and an existing `TextureAtlasLayout` handle into a new `TextureAtlas`: ```rust let atlas_layout = texture_atlases.add(atlas_layout); let handle = atlas_sources.handle(atlas_layout, &my_handle); ``` ## Extra notes In the future, it might make sense to combine the three types returned by `TextureAtlasBuilder` into their own struct, just so that people don't need to assign variable names to all three parts. In particular, when creating a version that can be loaded directly (like bevyengine#11873), we could probably use this new type.
…ed `Map`, `List`, and `Set`. (bevyengine#15406) # Objective Fixes bevyengine#15185. # Solution Change `drain` to take a `&mut self` for most reflected types. Some notable exceptions to this change are `Array` and `Tuple`. These types don't make sense with `drain` taking a mutable borrow since they can't get "smaller". Also `BTreeMap` doesn't have a `drain` function, so we have to pop elements off one at a time. ## Testing - The existing tests are sufficient. --- ## Migration Guide - `reflect::Map`, `reflect::List`, and `reflect::Set` all now take a `&mut self` instead of a `Box<Self>`. Callers of these traits should add `&mut` before their boxes, and implementers of these traits should update to match.
… cause it to panic. (bevyengine#15411) # Objective `World::flush_commands` will cause a panic with `error[B0003]: Could not insert a bundle [...] for entity [...] because it doesn't exist in this World` if there was a `spawn` command in the queue and you should instead use `flush` for this but this isn't mentioned in the docs ## Solution Add a note to the docs suggesting to use `World::flush` in this context. This error doesn't appear to happen with `spawn_batch` so I didn't add that to the note although you can cause it with `commands.spawn_empty().insert(...)` but I wasn't sure that was worth the documentation complexity as it is pretty unlikely (and equivalent to `commands.spawn(...)`.
# Objective Adds a new `Readback` component to request for readback of a `Handle<Image>` or `Handle<ShaderStorageBuffer>` to the CPU in a future frame. ## Solution We track the `Readback` component and allocate a target buffer to write the gpu resource into and map it back asynchronously, which then fires a trigger on the entity in the main world. This proccess is asynchronous, and generally takes a few frames. ## Showcase ```rust let mut buffer = ShaderStorageBuffer::from(vec![0u32; 16]); buffer.buffer_description.usage |= BufferUsages::COPY_SRC; let buffer = buffers.add(buffer); commands .spawn(Readback::buffer(buffer.clone())) .observe(|trigger: Trigger<ReadbackComplete>| { info!("Buffer data from previous frame {:?}", trigger.event()); }); ``` --------- Co-authored-by: Kristoffer Søholm <k.soeholm@gmail.com> Co-authored-by: IceSentry <IceSentry@users.noreply.github.com>
…yengine#15425) # Objective - Provide a generic and _reflectable_ way to iterate over contained entities ## Solution Adds two new traits: * `VisitEntities`: Reflectable iteration, accepts a closure rather than producing an iterator. Implemented by default for `IntoIterator` implementing types. A proc macro is also provided. * A `Mut` variant of the above. Its derive macro uses the same field attribute to avoid repetition. ## Testing Added a test for `VisitEntities` that also transitively tests its derive macro as well as the default `MapEntities` impl.
# Objective * Remove all uses of render_resource_wrapper. * Make it easier to share a `wgpu::Device` between Bevy and application code. ## Solution Removed the `render_resource_wrapper` macro. To improve the `RenderCreation:: Manual ` API, `ErasedRenderDevice` was replaced by `Arc`. Unfortunately I had to introduce one more usage of `WgpuWrapper` which seems like an unwanted constraint on the caller. ## Testing - Did you test these changes? If so, how? - Ran `cargo test`. - Ran a few examples. - Used `RenderCreation::Manual` in my own project - Exercised `RenderCreation::Automatic` through examples - Are there any parts that need more testing? - No - How can other people (reviewers) test your changes? Is there anything specific they need to know? - Run examples - Use `RenderCreation::Manual` in their own project
# Objective - The shader_instancing example can be misleading since it doesn't explain that bevy has built in automatic instancing. ## Solution - Explain that bevy has built in instancing and that this example is for advanced users. - Add a new automatic_instancing example that shows how to use the built in automatic instancing - Rename the shader_instancing example to custom_shader_instancing to highlight that this is a more advanced implementation --------- Co-authored-by: JMS55 <47158642+JMS55@users.noreply.github.com>
…ne#15469) # Objective We introduced the fancy Curve API earlier in this version. The goal of this PR is to provide a level of integration between that API and the existing spline constructions in `bevy_math`. Note that this PR only covers the integration of position-sampling via the `Curve` API. Other (substantially more complex) planned work will introduce general facilities for handling derivatives. ## Solution `CubicSegment`, `CubicCurve`, `RationalSegment`, and `RationalCurve` all now implement `Curve`, using their `position` function to sample the output. Additionally, some documentation has been updated/corrected, and `Serialize`/`Deserialize` derives have been added for all the curve structs. (Note that there are some barriers to automatic registration of `ReflectSerialize`/`ReflectSerialize` involving generics that have not been resolved in this PR.) --- ## Migration Guide The `RationalCurve::domain` method has been renamed to `RationalCurve::length`. Calling `.domain()` on a `RationalCurve` now returns its entire domain as an `Interval`.
# Objective Currently, reflecting a generic type provides no information about the generic parameters. This means that you can't get access to the type of `T` in `Foo<T>` without creating custom type data (we do this for [`ReflectHandle`](https://docs.rs/bevy/0.14.2/bevy/asset/struct.ReflectHandle.html#method.asset_type_id)). ## Solution This PR makes it so that generic type parameters and generic const parameters are tracked in a `Generics` struct stored on the `TypeInfo` for a type. For example, `struct Foo<T, const N: usize>` will store `T` and `N` as a `TypeParamInfo` and `ConstParamInfo`, respectively. The stored information includes: - The name of the generic parameter (i.e. `T`, `N`, etc.) - The type of the generic parameter (remember that we're dealing with monomorphized types, so this will actually be a concrete type) - The default type/value, if any (e.g. `f32` in `T = f32` or `10` in `const N: usize = 10`) ### Caveats The only requirement for this to work is that the user does not opt-out of the automatic `TypePath` derive with `#[reflect(type_path = false)]`. Doing so prevents the macro code from 100% knowing that the generic type implements `TypePath`. This in turn means the generated `Typed` impl can't add generics to the type. There are two solutions for this—both of which I think we should explore in a future PR: 1. We could just not use `TypePath`. This would mean that we can't store the `Type` of the generic, but we can at least store the `TypeId`. 2. We could provide a way to opt out of the automatic `Typed` derive with a `#[reflect(typed = false)]` attribute. This would allow users to manually implement `Typed` to add whatever generic information they need (e.g. skipping a parameter that can't implement `TypePath` while the rest can). I originally thought about making `Generics` an enum with `Generic`, `NonGeneric`, and `Unavailable` variants to signify whether there are generics, no generics, or generics that cannot be added due to opting out of `TypePath`. I ultimately decided against this as I think it adds a bit too much complexity for such an uncommon problem. Additionally, user's don't necessarily _have_ to know the generics of a type, so just skipping them should generally be fine for now. ## Testing You can test locally by running: ``` cargo test --package bevy_reflect ``` --- ## Showcase You can now access generic parameters via `TypeInfo`! ```rust #[derive(Reflect)] struct MyStruct<T, const N: usize>([T; N]); let generics = MyStruct::<f32, 10>::type_info().generics(); // Get by index: let t = generics.get(0).unwrap(); assert_eq!(t.name(), "T"); assert!(t.ty().is::<f32>()); assert!(!t.is_const()); // Or by name: let n = generics.get_named("N").unwrap(); assert_eq!(n.name(), "N"); assert!(n.ty().is::<usize>()); assert!(n.is_const()); ``` You can even access parameter defaults: ```rust #[derive(Reflect)] struct MyStruct<T = String, const N: usize = 10>([T; N]); let generics = MyStruct::<f32, 5>::type_info().generics(); let GenericInfo::Type(info) = generics.get_named("T").unwrap() else { panic!("expected a type parameter"); }; let default = info.default().unwrap(); assert!(default.is::<String>()); let GenericInfo::Const(info) = generics.get_named("N").unwrap() else { panic!("expected a const parameter"); }; let default = info.default().unwrap(); assert_eq!(default.downcast_ref::<usize>().unwrap(), &10); ```
# Objective Add a `Populated` system parameter that acts like `Query`, but prevents system from running if there are no matching entities. Fixes: bevyengine#15302 ## Solution Implement the system param which newtypes the `Query`. The only change is new validation, which fails if query is empty. The new system param is used in `fallible_params` example. ## Testing Ran `fallible_params` example. --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective - Fixes bevyengine#15448. ## Solution - Add `World::register_resource_with_descriptor` and `Components::register_resource_with_descriptor`. ## Testing - Added a test `dynamic_resource`.
# Objective - Contributes to bevyengine#15460 - Allows `bevy_mikktspace` to be used in `no_std` contexts. ## Solution - Added `std` (default) and `libm` features which control the inclusion of the standard library. To use `bevy_mikktspace` in `no_std` environments, enable the `libm` feature. ## Testing - CI - `cargo clippy -p bevy_mikktspace --target "x86_64-unknown-none" --no-default-features --features libm`
# Objective - Adds a separate lifetimes for AssetSourceId
…t_released (bevyengine#12372) # Objective Fix bevyengine#12273 ## Solution – Only emit `KeyboardFocusLost` when the keyboard focus is lost – ignore synthetic key releases too, not just key presses (as they're already covered by `KeyboardFocusLost`) --- ## Changelog ### Fixed - Don't trigger `ButtonInput<KeyCode>::just_pressed`/`just_released` when spawning a window/focus moving between Bevy windows
# Objective - bevyengine#15496 introduced documentation with some missing links. ## Solution - Add the missing links and clean up a little.
…ine#15493) (Note: bevyengine#15434 implements something very similar to this for functional curve adaptors, which is why they aren't present in this PR.) # Objective Previously, there was basically no chance that the explicitly-interpolating sample curve structs from the `Curve` API would actually be `Reflect`. The reason for this is functional programming: the structs contain an explicit interpolation `I: Fn(&T, &T, f32) -> T` which, under typical circumstances, will never be `Reflect`, which prevents the derive from realistically succeeding. In fact, they won't be a lot of other things either, notably including both`Debug` and `TypePath`, which are also required for reflection to succeed. The goal of this PR is to weaken the implementations of reflection traits for these structs so that they can implement `Reflect` under reasonable circumstances. (Notably, they will still not be `FromReflect`, which is unavoidable.) ## Solution The function fields are marked as `#[reflect(ignore)]`, and the derive macro for `Reflect` has `FromReflect` disabled. (This is not fully optimal, but we don't presently have any kind of "read-only" attribute for these fields.) Additionally, these structs receive custom `Debug` and `TypePath` implementations that display the function's (unstable!) type name instead of its value or type path (respectively). In the case of `TypePath`, this is a bit janky, but the instability of `type_name` won't generally present an issue for generics, which would have to be registered manually in the type registry anyway, which is impossible because the function type parameters cannot be named. (And in general, the "blessed" route for such cases would generally involve manually monomorphizing the function parameter away, which also allows access to `FromReflect` etc. through very ordinary use of the derive macro.) ## Testing Tests in the new `bevy_math::curve::sample_curves` module guarantee that these are actually `Reflect` under reasonable circumstances. --- ## Future changes If and when function item types become `Default`, these types will need to receive custom `FromReflect` implementations that exploit it. Such a custom implementation would also be desirable if users start doing things like wrapping function items in `Default`/`FromReflect` wrappers that still implement a `Fn` trait. Additionally, if function types become nameable in user-space, the stance on `Debug`/`TypePath` may bear reexamination, since partial monomorphization through wrappers would make implementing reflect traits for function types potentially more viable. --------- Co-authored-by: Gino Valente <49806985+MrGVSV@users.noreply.github.com>
…vyengine#15808) # Objective Fixes bevyengine#15807 ## Solution We move the guard into this function. ## Testing N/A, This is just reverting to the old behavior before bevyengine#15509.
# Objective Animation docs could use some clarification regarding: - how exactly curves are evaluated - how additive blend nodes actually work ## Solution Add some documentation that explains how curve domains are used and how additive blend nodes treat their children. ## Commentary The way additive blend nodes work right now is a little bit weird, since their first child's weight is ignored. Arguably this makes sense, since additive animations are authored differently from ordinary animations, but it also feels a bit strange. We could make the first node's weight actually be applied, and the present behavior would be recovered when the weight is set to 1. The main disadvantage of how things are set up now is that combining a bunch of additive animations without a base pose is pretty awkward (e.g. to add them onto a base pose later in the graph). If we changed it, the main downside would be that reusing the same animation on different parts of the graph is harder; on the other hand, the weights can be locally reassigned by using blend nodes with no other children, which rectifies this shortfall.
# Objective MacOS has some nice options for controlling the window and titlebar to make the content appear much more "immersively" in the window. This PR exposes options for controlling this. ## Solution Adds new fields to `Window` to control these, with doc comments to explain what they do and that they're MacOS only. ## Testing Tested on a MacOS machine (not my own, I don't have one). That's where the below screenshots were taken. --- ## Showcase On MacOS, you now have more options for configuring the window titlebar. You can, for example, make the title bar transparent and only show the window controls. This provides a more "immersive" experience for your rendered content. Before, only this was possible: <img width="1392" alt="image" src="https://github.com/user-attachments/assets/abf03da2-d247-4202-a7e7-731c45d80d54"> Now, you can create windows like this: <img width="1392" alt="image2" src="https://github.com/user-attachments/assets/3239d0e3-4708-4798-8755-188541e14f93"> This uses the following `bevy_window::Window` settings: ```rs fullsize_content_view: true, titlebar_transparent: true, titlebar_show_title: false, ``` ## Migration Guide `bevy_window::Window` now has extra fields for configuring MacOS window settings: ```rs pub movable_by_window_background: bool, pub fullsize_content_view: bool, pub has_shadow: bool, pub titlebar_shown: bool, pub titlebar_transparent: bool, pub titlebar_show_title: bool, pub titlebar_show_buttons: bool, ``` Using `Window::default` keeps the same behaviour as before.
I wonder who left that there...
# Objective - Example validation job fails in CI - This happened after GitHub updated the latest version of ubuntu from the 22.04 to the 24.04 - The package libegl1-mesa is not available on ubuntu 24.04 ## Solution - Keep using ubuntu 22.04 - This is a temp fix and we should fix the update ## Testing - if it can get merged then it works 🤷
# Objective - Fixes bevyengine#15837 ## Solution - Change `Emitter` components to use `Stopwatch` to allow the time to be tracked independently. ## Testing - Changes were tested. - Run either the `spatial_audio_2d` or `spatial_audio_3d` example to test Co-authored-by: François Mockers <mockersf@gmail.com>
# Objective The previous `PhantomData` instances were written somewhat lazily, so they were just things like `PhantomData<T>` for curves with an output type of `T`. This looks innocuous, but it unnecessarily constrains `Send/Sync` inference based on `T`. See [here](https://doc.rust-lang.org/nomicon/phantom-data.html#table-of-phantomdata-patterns). ## Solution Switch to `PhantomData` of the form `PhantomData<fn() -> T>` for most of these adaptors. Since they only have a functional relationship to `T` (i.e. it shows up in the return type of trait methods), this is more accurate. ## Testing Tested by compiling Bevy. Co-authored-by: François Mockers <mockersf@gmail.com>
# Objective Currently text is recomputed unnecessarily on any changes to its color, which is extremely expensive. ## Solution Split up `TextStyle` into two separate components `TextFont` and `TextColor`. ## Testing I added this system to `many_buttons`: ```rust fn set_text_colors_changed(mut colors: Query<&mut TextColor>) { for mut text_color in colors.iter_mut() { text_color.set_changed(); } } ``` reports ~4fps on main, ~50fps with this PR. ## Migration Guide `TextStyle` has been renamed to `TextFont` and its `color` field has been moved to a separate component named `TextColor` which newtypes `Color`.
…ne#15800) # Objective Closes bevyengine#15545. `bevy_picking` supports UI and sprite picking, but not mesh picking. Being able to pick meshes would be extremely useful for various games, tools, and our own examples, as well as scene editors and inspectors. So, we need a mesh picking backend! Luckily, [`bevy_mod_picking`](https://github.com/aevyrie/bevy_mod_picking) (which `bevy_picking` is based on) by @aevyrie already has a [backend for it](https://github.com/aevyrie/bevy_mod_picking/blob/74f0c3c0fbc8048632ba46fd8f14e26aaea9c76c/backends/bevy_picking_raycast/src/lib.rs) using [`bevy_mod_raycast`](https://github.com/aevyrie/bevy_mod_raycast). As a side product of adding mesh picking, we also get support for performing ray casts on meshes! ## Solution Upstream a large chunk of the immediate-mode ray casting functionality from `bevy_mod_raycast`, and add a mesh picking backend based on `bevy_mod_picking`. Huge thanks to @aevyrie who did all the hard work on these incredible crates! All meshes are pickable by default. Picking can be disabled for individual entities by adding `PickingBehavior::IGNORE`, like normal. Or, if you want mesh picking to be entirely opt-in, you can set `MeshPickingBackendSettings::require_markers` to `true` and add a `RayCastPickable` component to the desired camera and target entities. You can also use the new `MeshRayCast` system parameter to cast rays into the world manually: ```rust fn ray_cast_system(mut ray_cast: MeshRayCast, foo_query: Query<(), With<Foo>>) { let ray = Ray3d::new(Vec3::ZERO, Dir3::X); // Only ray cast against entities with the `Foo` component. let filter = |entity| foo_query.contains(entity); // Never early-exit. Note that you can change behavior per-entity. let early_exit_test = |_entity| false; // Ignore the visibility of entities. This allows ray casting hidden entities. let visibility = RayCastVisibility::Any; let settings = RayCastSettings::default() .with_filter(&filter) .with_early_exit_test(&early_exit_test) .with_visibility(visibility); // Cast the ray with the settings, returning a list of intersections. let hits = ray_cast.cast_ray(ray, &settings); } ``` This is largely a direct port, but I did make several changes to match our APIs better, remove things we don't need or that I think are unnecessary, and do some general improvements to code quality and documentation. ### Changes Relative to `bevy_mod_raycast` and `bevy_mod_picking` - Every `Raycast` and "raycast" has been renamed to `RayCast` and "ray cast" (similar reasoning as the "Naming" section in bevyengine#15724) - `Raycast` system param has been renamed to `MeshRayCast` to avoid naming conflicts and to be explicit that it is not for colliders - `RaycastBackend` has been renamed to `MeshPickingBackend` - `RayCastVisibility` variants are now `Any`, `Visible`, and `VisibleInView` instead of `Ignore`, `MustBeVisible`, and `MustBeVisibleAndInView` - `NoBackfaceCulling` has been renamed to `RayCastBackfaces`, to avoid implying that it affects the rendering of backfaces for meshes (it doesn't) - `SimplifiedMesh` and `RayCastBackfaces` live near other ray casting API types, not in their own 10 LoC module - All intersection logic and types are in the same `intersections` module, not split across several modules - Some intersection types have been renamed to be clearer and more consistent - `IntersectionData` -> `RayMeshHit` - `RayHit` -> `RayTriangleHit` - General documentation and code quality improvements ### Removed / Not Ported - Removed unused ray helpers and types, like `PrimitiveIntersection` - Removed getters on intersection types, and made their properties public - There is no `2d` feature, and `Raycast::mesh_query` and `Raycast::mesh2d_query` have been merged into `MeshRayCast::mesh_query`, which handles both 2D and 3D - I assume this existed previously because `Mesh2dHandle` used to be in `bevy_sprite`. Now both the 2D and 3D mesh are in `bevy_render`. - There is no `debug` feature or ray debug rendering - There is no deferred API (`RaycastSource`) - There is no `CursorRayPlugin` (the picking backend handles this) ### Note for Reviewers In case it's helpful, the [first commit](bevyengine@281638e) here is essentially a one-to-one port. The rest of the commits are primarily refactoring and cleaning things up in the ways listed earlier, as well as changes to the module structure. It may also be useful to compare the original [picking backend](https://github.com/aevyrie/bevy_mod_picking/blob/74f0c3c0fbc8048632ba46fd8f14e26aaea9c76c/backends/bevy_picking_raycast/src/lib.rs) and [`bevy_mod_raycast`](https://github.com/aevyrie/bevy_mod_raycast) to this PR. Feel free to mention if there are any changes that I should revert or something I should not include in this PR. ## Testing I tested mesh picking and relevant components in some examples, for both 2D and 3D meshes, and added a new `mesh_picking` example. I also ~~stole~~ ported over the [ray-mesh intersection benchmark](https://github.com/aevyrie/bevy_mod_raycast/blob/dbc5ef32fe48997a1a7eeec7434d9dd8b829e52e/benches/ray_mesh_intersection.rs) from `bevy_mod_raycast`. --- ## Showcase Below is a version of the `2d_shapes` example modified to demonstrate 2D mesh picking. This is not included in this PR. https://github.com/user-attachments/assets/7742528c-8630-4c00-bacd-81576ac432bf And below is the new `mesh_picking` example: https://github.com/user-attachments/assets/b65c7a5a-fa3a-4c2d-8bbd-e7a2c772986e There is also a really cool new `mesh_ray_cast` example ported over from `bevy_mod_raycast`: https://github.com/user-attachments/assets/3c5eb6c0-bd94-4fb0-bec6-8a85668a06c9 --------- Co-authored-by: Aevyrie <aevyrie@gmail.com> Co-authored-by: Trent <2771466+tbillington@users.noreply.github.com> Co-authored-by: François Mockers <mockersf@gmail.com>
# Objective With the warning removed in bevyengine#15736, the rules for the UI tree changes. We no longer need to traverse non `Node`/`GhostNode` entities. ## Solution - Added a filter `Or<(With<Node>, With<GhostNode>)>` to the child traversal query so we don't unnecessarily traverse nodes that are not part of the UI tree (like text nodes). - Also moved the warning for NoUI->UI entities so it is actually triggered (see comments) ## Testing - Ran unit tests (still passing) - Ran the ghost_nodes and ui examples, still works and looks fine 👍 - Tested the warning by spawning a Node under an empty entity. --- --------- Co-authored-by: UkoeHB <37489173+UkoeHB@users.noreply.github.com>
# Objective Fixes bevyengine#15515 ## Solution I went for the simplest solution because "format" in `shader_format_spirv` didn't sound directly related. ## Testing The command `cargo b -p bevy --no-default-features -F spirv_shader_passthrough,x11` failed before, but works now.
# Objective Fixes bevyengine#15445 ## Solution Add a note to the doc comment for `Real`. ## Testing Viewed the built documentation. ## Showcase ![image](https://github.com/user-attachments/assets/815b8655-c632-4c92-b64e-28c06959c38b) [*possible bug in rustdoc rendering the footnote](rust-lang/rust#131631)
# Objective - Required components replace bundles, but `SpatialBundle` is yet to be deprecated ## Solution - Deprecate `SpatialBundle` - Insert `Transform` and `Visibility` instead in examples using it - In `spawn` or `insert` inserting a default `Transform` or `Visibility` with component already requiring either, remove those components from the tuple ## Testing - Did you test these changes? If so, how? Yes, I ran the examples I changed and tests - Are there any parts that need more testing? The `gamepad_viewer` and and `custom_shader_instancing` examples don't work as intended due to entirely unrelated code, didn't check main. - How can other people (reviewers) test your changes? Is there anything specific they need to know? Run examples, or just check that all spawned values are identical - If relevant, what platforms did you test these changes on, and are there any important ones you can't test? Linux, wayland trough x11 (cause that's the default feature) --- ## Migration Guide `SpatialBundle` is now deprecated, insert `Transform` and `Visibility` instead which will automatically insert all other components that were in the bundle. If you do not specify these values and any other components in your `spawn`/`insert` call already requires either of these components you can leave that one out. before: ```rust commands.spawn(SpatialBundle::default()); ``` after: ```rust commands.spawn((Transform::default(), Visibility::default()); ```
# Objective `insert_or_spawn_batch` exists, but a version for just inserting doesn't - Closes bevyengine#2693 - Closes bevyengine#8384 - Adopts/supersedes bevyengine#8600 ## Solution Add `insert_batch`, along with the most common `insert` variations: - `World::insert_batch` - `World::insert_batch_if_new` - `World::try_insert_batch` - `World::try_insert_batch_if_new` - `Commands::insert_batch` - `Commands::insert_batch_if_new` - `Commands::try_insert_batch` - `Commands::try_insert_batch_if_new` ## Testing Added tests, and added a benchmark for `insert_batch`. Performance is slightly better than `insert_or_spawn_batch` when only inserting: ![Code_HPnUN0QeWe](https://github.com/user-attachments/assets/53091e4f-6518-43f4-a63f-ae57d5470c66) <details> <summary>old benchmark</summary> This was before reworking it to remove the `UnsafeWorldCell`: ![Code_QhXJb8sjlJ](https://github.com/user-attachments/assets/1061e2a7-a521-48e1-a799-1b6b8d1c0b93) </details> --- ## Showcase Usage is the same as `insert_or_spawn_batch`: ``` use bevy_ecs::{entity::Entity, world::World, component::Component}; #[derive(Component)] struct A(&'static str); #[derive(Component, PartialEq, Debug)] struct B(f32); let mut world = World::new(); let entity_a = world.spawn_empty().id(); let entity_b = world.spawn_empty().id(); world.insert_batch([ (entity_a, (A("a"), B(0.0))), (entity_b, (A("b"), B(1.0))), ]); assert_eq!(world.get::<B>(entity_a), Some(&B(0.0))); ```
# Objective - closes bevyengine#15866 ## Solution - Simply migrate where possible. ## Testing - Expect that CI will do most of the work. Examples is another way of testing this, as most of the work is in that area. --- ## Notes For now, this PR doesn't migrate `QueryState::single` and friends as for now, this look like another issue. So for example, QueryBuilders that used single or `World::query` that used single wasn't migrated. If there is a easy way to migrate those, please let me know. Most of the uses of `Query::single` were removed, the only other uses that I found was related to tests of said methods, so will probably be removed when we remove `Query::single`.
…evyengine#15745) # Objective bevyengine#15320 is a particularly painful breaking change, and the new `RenderEntity` in particular is very noisy, with a lot of `let entity = entity.id()` spam. ## Solution Implement `WorldQuery`, `QueryData` and `ReadOnlyQueryData` for `RenderEntity` and `WorldEntity`. These work the same as the `Entity` impls from a user-facing perspective: they simply return an owned (copied) `Entity` identifier. This dramatically reduces noise and eases migration. Under the hood, these impls defer to the implementations for `&T` for everything other than the "call .id() for the user" bit, as they involve read-only access to component data. Doing it this way (as opposed to implementing a custom fetch, as tried in the first commit) dramatically reduces the maintenance risk of complex unsafe code outside of `bevy_ecs`. To make this easier (and encourage users to do this themselves!), I've made `ReadFetch` and `WriteFetch` slightly more public: they're no longer `doc(hidden)`. This is a good change, since trying to vendor the logic is much worse than just deferring to the existing tested impls. ## Testing I've run a handful of rendering examples (breakout, alien_cake_addict, auto_exposure, fog_volumes, box_shadow) and nothing broke. ## Follow-up We should lint for the uses of `&RenderEntity` and `&MainEntity` in queries: this is just less nice for no reason. --------- Co-authored-by: Trashtalk217 <trashtalk217@gmail.com>
…yengine#15890) # Objective The type `AssetLoadError` has `PartialEq` and `Eq` impls, which is problematic due to the fact that the `AssetLoaderError` and `AddAsyncError` variants lie in their impls: they will return `true` for any `Box<dyn Error>` with the same `TypeId`, even if the actual value is different. This can lead to subtle bugs if a user relies on the equality comparison to ensure that two values are equal. The same is true for `DependencyLoadState`, `RecursiveDependencyLoadState`. More generally, it is an anti-pattern for large error types involving dynamic dispatch, such as `AssetLoadError`, to have equality comparisons. Directly comparing two errors for equality is usually not desired -- if some logic needs to branch based on the value of an error, it is usually more correct to check for specific variants and inspect their fields. As far as I can tell, the only reason these errors have equality comparisons is because the `LoadState` enum wraps `AssetLoadError` for its `Failed` variant. This equality comparison is only used to check for `== LoadState::Loaded`, which we can easily replace with an `is_loaded` method. ## Solution Remove the `{Partial}Eq` impls from `LoadState`, which also allows us to remove it from the error types. ## Migration Guide The types `bevy_asset::AssetLoadError` and `bevy_asset::LoadState` no longer support equality comparisons. If you need to check for an asset's load state, consider checking for a specific variant using `LoadState::is_loaded` or the `matches!` macro. Similarly, consider using the `matches!` macro to check for specific variants of the `AssetLoadError` type if you need to inspect the value of an asset load error in your code. `DependencyLoadState` and `RecursiveDependencyLoadState` are not released yet, so no migration needed, --------- Co-authored-by: Joseph <21144246+JoJoJet@users.noreply.github.com>
# Objective Fixes bevyengine#15847 Alternative to bevyengine#15862. Would appreciate a rendering person signaling preference for one or the other. ## Solution Partially revert the changes made to this example in bevyengine#15524. Add comment explaining that the non-usage of the built-in color vertex attribute is intentional. ## Testing `cargo run --example mesh2d_manual`
# Objective - Android doesn't receive lifecycle event `Suspended` before suspension ## Solution - Fix update triggering just after state change on android ## Testing - Tested on the android emulator
# Objective - Compare screenshots for a few examples between PRs and main ## Solution - Send screenshots taken to a screenshot comparison service - Not completely sure every thing will work at once, but it shouldn't break anything at least - it needs a secret to work, I'll add it if enough people agree with this PR - this PR doesn't change anything on the screenshot selection (load_gltf and breakout currently), this will need rendering folks input and can happen later --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
Bumps [crate-ci/typos](https://github.com/crate-ci/typos) from 1.25.0 to 1.26.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/crate-ci/typos/releases">crate-ci/typos's releases</a>.</em></p> <blockquote> <h2>v1.26.0</h2> <h2>[1.26.0] - 2024-10-07</h2> <h3>Compatibility</h3> <ul> <li><em>(pre-commit)</em> Requires 3.2+</li> </ul> <h3>Fixes</h3> <ul> <li><em>(pre-commit)</em> Resolve deprecations in 4.0 about deprecated stage names</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/crate-ci/typos/blob/master/CHANGELOG.md">crate-ci/typos's changelog</a>.</em></p> <blockquote> <h2>[1.26.0] - 2024-10-07</h2> <h3>Compatibility</h3> <ul> <li><em>(pre-commit)</em> Requires 3.2+</li> </ul> <h3>Fixes</h3> <ul> <li><em>(pre-commit)</em> Resolve deprecations in 4.0 about deprecated stage names</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/crate-ci/typos/commit/6802cc60d4e7f78b9d5454f6cf3935c042d5e1e3"><code>6802cc6</code></a> chore: Release</li> <li><a href="https://github.com/crate-ci/typos/commit/caa55026aee3d2cdcaf1f9b0c258651dbb01c283"><code>caa5502</code></a> docs: Update changelog</li> <li><a href="https://github.com/crate-ci/typos/commit/2114c1924169510820bc12e59427851514624ac2"><code>2114c19</code></a> Merge pull request <a href="https://redirect.github.com/crate-ci/typos/issues/1114">#1114</a> from tobiasraabe/patch-1</li> <li><a href="https://github.com/crate-ci/typos/commit/9de7b2c6bed6e32c6b34ed91702ac6eaba138a99"><code>9de7b2c</code></a> Updates stage names in <code>.pre-commit-hooks.yaml</code>.</li> <li><a href="https://github.com/crate-ci/typos/commit/14f49f455cf3b6a38841665e82c3b9135b91c929"><code>14f49f4</code></a> Merge pull request <a href="https://redirect.github.com/crate-ci/typos/issues/1105">#1105</a> from crate-ci/renovate/unicode-width-0.x</li> <li><a href="https://github.com/crate-ci/typos/commit/58ffa4baefb10b607bbc30bd16f7fe8a4446a643"><code>58ffa4b</code></a> Merge pull request <a href="https://redirect.github.com/crate-ci/typos/issues/1108">#1108</a> from crate-ci/renovate/stable-1.x</li> <li><a href="https://github.com/crate-ci/typos/commit/003cb769377a25a6c659c67429585644c5321348"><code>003cb76</code></a> chore(deps): Update dependency STABLE to v1.81.0</li> <li><a href="https://github.com/crate-ci/typos/commit/bc00184a2367b7d354946b042483a30d92e012e9"><code>bc00184</code></a> chore(deps): Update Rust crate unicode-width to 0.2.0</li> <li>See full diff in <a href="https://github.com/crate-ci/typos/compare/v1.25.0...v1.26.0">compare view</a></li> </ul> </details> <br /> [![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=crate-ci/typos&package-manager=github_actions&previous-version=1.25.0&new-version=1.26.0)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
This commit allows the Bevy renderer to use the clustering infrastructure for light probes (reflection probes and irradiance volumes) on platforms where at least 3 storage buffers are available. On such platforms (the vast majority), we stop performing brute-force searches of light probes for each fragment and instead only search the light probes with bounding spheres that intersect the current cluster. This should dramatically improve scalability of irradiance volumes and reflection probes. The primary platform that doesn't support 3 storage buffers is WebGL 2, and we continue using a brute-force search of light probes on that platform, as the UBO that stores per-cluster indices is too small to fit the light probe counts. Note, however, that that platform also doesn't support bindless textures (indeed, it would be very odd for a platform to support bindless textures but not SSBOs), so we only support one of each type of light probe per drawcall in the first place. So this isn't a performance problem, as the search will only have one light probe to consider. (In fact, clustering would probably end up being a performance loss.) Known potential improvements include: 1. We currently cull based on a conservative bounding sphere test and not based on the oriented bounding box (OBB) of the light probe. This is improvable, but in the interests of simplicity, I opted to keep the bounding sphere test for now. The OBB improvement can be a follow-up. 2. This patch doesn't change the fact that each fragment only takes a single light probe into account. Typical light probe implementations detect the case in which multiple light probes cover the current fragment and perform some sort of weighted blend between them. As the light probe fetch function presently returns only a single light probe, implementing that feature would require more code restructuring, so I left it out for now. It can be added as a follow-up. 3. Light probe implementations typically have a falloff range. Although this is a wanted feature in Bevy, this particular commit also doesn't implement that feature, as it's out of scope. 4. This commit doesn't raise the maximum number of light probes past its current value of 8 for each type. This should be addressed later, but would possibly require more bindings on platforms with storage buffers, which would increase this patch's complexity. Even without raising the limit, this patch should constitute a significant performance improvement for scenes that get anywhere close to this limit. In the interest of keeping this patch small, I opted to leave raising the limit to a follow-up.
BenjaminBrienen
force-pushed
the
cluster-light-probes
branch
from
October 14, 2024 19:00
b82688a
to
1e8de1a
Compare
@pcwalton Let me know if I need to do anything else here |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Objective
Merged bevyengine/bevy:main
Solution
The conflicts were mostly to do with the volumetric lighting PR from a couple weeks ago. I added the volumetric lighting field to the cluster variants.