diff --git a/release-content/migration-guides/BorderRects_fields_are_now_vec2s.md b/release-content/migration-guides/BorderRects_fields_are_now_vec2s.md deleted file mode 100644 index d9f6407c919c6..0000000000000 --- a/release-content/migration-guides/BorderRects_fields_are_now_vec2s.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: "`BorderRect` now has `Vec2` fields" -pull_requests: [21581] ---- - -The directional BorderRect fields (`left`, `right`, `top`, and `bottom`) have been replaced with `min_inset` and `max_inset` `Vec2` fields. - -Using `min_inset` and `max_inset` removes the need to interpret `top` or `bottom` relative to the coordinate system, so the same logic will work consistently in both UI and 2D. diff --git a/release-content/migration-guides/ambient_light_split.md b/release-content/migration-guides/ambient_light_split.md deleted file mode 100644 index ae974e835ea64..0000000000000 --- a/release-content/migration-guides/ambient_light_split.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: "`AmbientLight` split into a component and a resource" -pull_requests: [21585] ---- - -The `AmbientLight` used to be both a component *and* a resource. -In 0.18, we've split this in two separate structs: `AmbientLight` and `GlobalAmbientLight`. -The resource `GlobalAmbientLight` is the default ambient light for the entire world and automatically added by `LightPlugin`. -Meanwhile, `AmbientLight` is a component that can be added to a `Camera` in order to override the default `GlobalAmbientLight`. -When appropriate, rename `AmbientLight` to `GlobalAmbientLight`. - -Before: - -```rust -app.insert_resource(AmbientLight { - color: Color::WHITE, - brightness: 2000., - ..default() -}); -``` - -After: - -```rust -app.insert_resource(GlobalAmbientLight { - color: Color::WHITE, - brightness: 2000., - ..default() -}); -``` diff --git a/release-content/migration-guides/animation-event-trigger-rename.md b/release-content/migration-guides/animation-event-trigger-rename.md deleted file mode 100644 index 743bfae5ee114..0000000000000 --- a/release-content/migration-guides/animation-event-trigger-rename.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: "`AnimationEventTrigger::animation_player` has been renamed to `AnimationEventTrigger::target`" -pull_requests: [21593] ---- - -This field and its docs strongly suggested that it would point to an entity holding an `AnimationPlayer`, but that actually depends on how the event was registered. - -- If you used `AnimationClip::add_event`, the field really did point to the `AnimationPlayer` -- But if you used `AnimationClip::add_event_to_target`, this field instead pointed to an `AnimationTargetId` - -To make this more clear, the field was renamed to `target` and the docs surrounding it improved. diff --git a/release-content/migration-guides/animation-target-refactor.md b/release-content/migration-guides/animation-target-refactor.md deleted file mode 100644 index 1e1fc631ae3fd..0000000000000 --- a/release-content/migration-guides/animation-target-refactor.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -title: "`AnimationTarget` replaced by separate components" -pull_requests: [20774] ---- - -The `AnimationTarget` component has been split into two separate components. -`AnimationTarget::id` is now an `AnimationTargetId` component, and -`AnimationTarget::player` is now an `AnimatedBy` component. - -This change was made to add flexibility. It's now possible to calculate the -`AnimationTargetId` first, but defer the choice of player until later. - -Before: - -```rust -entity.insert(AnimationTarget { id: AnimationTargetId(id), player: player_entity }); -``` - -After: - -```rust -entity.insert((AnimationTargetId(id), AnimatedBy(player_entity))); -``` diff --git a/release-content/migration-guides/archetype_query_data.md b/release-content/migration-guides/archetype_query_data.md deleted file mode 100644 index 34967124901bb..0000000000000 --- a/release-content/migration-guides/archetype_query_data.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "`ArchetypeQueryData` trait" -pull_requests: [21581] ---- - -To support richer querying across relations, -Bevy now supports query data that are not archetypal: the query can return entities based on conditions that do not exclusively involve the entity's archetype. - -An example of non-archetypal filter is `Changed`: the entity is filtered based on the archetype (having the component C) but also based on the change ticks of the component. - -Code that requires queries to `impl ExactSizeIterator` may need to replace `QueryData` bounds with `ArchetypeQueryData`. - -```rust -// 0.17 -fn requires_exact_size(q: Query) -> usize { - q.into_iter().len() -} -// 0.18 -fn requires_exact_size(q: Query) -> usize { - q.into_iter().len() -} -``` - -Manual implementations of `QueryData` will now need to provide the `IS_ARCHETYPAL` associated constant. -This will be `true` for most existing queries, -although queries that wrap other queries should delegate as appropriate. -In addition, queries with `IS_ARCHETYPAL = true` should implement `ArchetypeQueryData`. diff --git a/release-content/migration-guides/asset_plugin_processed_override.md b/release-content/migration-guides/asset_plugin_processed_override.md deleted file mode 100644 index 0bb7b5e7e044f..0000000000000 --- a/release-content/migration-guides/asset_plugin_processed_override.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: AssetPlugin now has a `use_asset_processor_override` field. -pull_requests: [21409] ---- - -The `AssetPlugin` now has a `use_asset_processor_override` field. If you were previously setting all -`AssetPlugin` fields, you should either use struct update syntax `..Default::default()`, or set the -new `use_asset_processor_override` to `None`. diff --git a/release-content/migration-guides/asset_watcher_async_sender.md b/release-content/migration-guides/asset_watcher_async_sender.md deleted file mode 100644 index 60b1383e5c23f..0000000000000 --- a/release-content/migration-guides/asset_watcher_async_sender.md +++ /dev/null @@ -1,12 +0,0 @@ ---- -title: AssetSources now give an `async_channel::Sender` instead of a `crossbeam_channel::Sender` -pull_requests: [] ---- - -Previously, when creating an asset source, `AssetSourceBuilder::with_watcher` would provide users -with a `crossbeam_channel::Sender`. Now, this has been changed to `async_channel::Sender`. - -If you were previously calling `sender.send(AssetSourceEvent::ModifiedAsset("hello".into()))`, now -it would be `sender.send_blocking(AssetSourceEvent::ModifiedAsset("hello".into()))`. These channels -are very comparable, so finding an analogous method between `crossbeam_channel` and `async_channel` -should be straight forward. diff --git a/release-content/migration-guides/bevy_input_features.md b/release-content/migration-guides/bevy_input_features.md deleted file mode 100644 index dbab8f69455e9..0000000000000 --- a/release-content/migration-guides/bevy_input_features.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Put input sources for `bevy_input` under features -pull_requests: [21447] ---- - -`bevy_input` provides primitives for all kinds of input. But on -consoles you usually don't have things like touch. On more obscure -platforms, like GBA, only gamepad input is needed. - -If you use `bevy_window` or `bevy_gilrs`, they will automatically -enable the necessary features on `bevy_input`. If you don't depend -on them (for example, if you are developing for a platform that -isn't supported by these crates), you need to enable the required -input sources on `bevy_input` manually: - -```toml -# Before: -bevy = { version = "0.17", default-features = false } -# After (enable sources that you actually use): -bevy = { version = "0.18", default-features = false, features = [ - "mouse", - "keyboard", - "gamepad", - "touch", - "gestures", -] } -``` diff --git a/release-content/migration-guides/bevy_manifest_scope_api.md b/release-content/migration-guides/bevy_manifest_scope_api.md deleted file mode 100644 index 815e86a07e3f0..0000000000000 --- a/release-content/migration-guides/bevy_manifest_scope_api.md +++ /dev/null @@ -1,17 +0,0 @@ ---- -title: "`BevyManifest::shared` is now a scope-like API." -pull_requests: [20630] ---- - -In previous versions of Bevy, `BevyManifest` returned a mapped `RwLock` guard. Now, it's a scope-like API: - -```rust -// 0.16 -let manifest = BevyManifest::shared(); -let path = manifest.get_path("my_bevy_crate"); - -// 0.17 -let path = BevyManifest::shared(|manifest| { - manifest.get_path("my_bevy_crate") -}); -``` diff --git a/release-content/migration-guides/bind-group-layout-descriptors.md b/release-content/migration-guides/bind-group-layout-descriptors.md deleted file mode 100644 index 834ed88f28e8e..0000000000000 --- a/release-content/migration-guides/bind-group-layout-descriptors.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: "`RenderPipelineDescriptor` and `ComputePipelineDescriptor` now hold a `BindGroupLayoutDescriptor`" -pull_requests: [21205] ---- - -In previous versions of Bevy, `RenderPipelineDescriptor` and `ComputePipelineDescriptor` held a `BindGroupLayout` to describe the layout of shader bind groups, depending directly on `wgpu`'s `BindGroupLayout`. -Now, they hold a new type `BindGroupLayoutDescriptor` which holds the `BindGroupLayoutEntry`s directly. The descriptors are used to create `BindGroupLayout`s when they are first needed by a pipeline, and cached for reuse. - -Concretely, this means wherever you were using a `RenderDevice` to create a `BindGroupLayout` to store in a `RenderPipelineDescriptor` or `ComputePipelineDescriptor`, you will now create a `BindGroupLayoutDescriptor`: - -```rust -// 0.17 -let bind_group_layout = render_device.create_bind_group_layout( - // ... -); -commands.insert_resource(MyPipeline { - bind_group_layout, - /// ... -}); -// ... -let bind_group = render_context.render_device().create_bind_group( - None - &my_pipeline.bind_group_layout, - // ... -); - -// 0.18 -let bind_group_layout = BindGroupLayoutDescriptor::new( - // ... -); -commands.insert_resource(MyPipeline { - bind_group_layout, - /// ... -}); -// ... -let bind_group = render_context.render_device().create_bind_group( - None - &pipeline_cache.get_bind_group_layout(&my_pipeline.bind_group), - // ... -); -``` diff --git a/release-content/migration-guides/bindgroup-labels-mandatory.md b/release-content/migration-guides/bindgroup-labels-mandatory.md deleted file mode 100644 index efe9667b14db7..0000000000000 --- a/release-content/migration-guides/bindgroup-labels-mandatory.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -title: "`BindGroupLayout` labels are no longer optional" -pull_requests: [21573] ---- - -In previous versions of Bevy, the `label` of a `BindGroupLayout` was optional. This practically only applies when implementing `AsBindGroup` manually without the `AsBindGroup` derive. - -If you were previously omitting the `label` implementation from a `impl AsBindGroup`, you now must implement it: - -```rust -fn label() -> &'static str { - "my label" -} -``` diff --git a/release-content/migration-guides/border_radius_is_now_a_field_on_node.md b/release-content/migration-guides/border_radius_is_now_a_field_on_node.md deleted file mode 100644 index c55d5806be6c4..0000000000000 --- a/release-content/migration-guides/border_radius_is_now_a_field_on_node.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: "`BorderRadius` has been added to `Node` and is no longer a component" -pull_requests: [21781] ---- - -`BorderRadius` is no longer a component, instead a `border_radius: BorderRadius` field has been added to `Node`. diff --git a/release-content/migration-guides/bundle_component_ids.md b/release-content/migration-guides/bundle_component_ids.md deleted file mode 100644 index 55c70331c45cd..0000000000000 --- a/release-content/migration-guides/bundle_component_ids.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: Change `Bundle::component_ids` and `Bundle::get_component_ids` to return an iterator. -pull_requests: [14791, 15458, 15269] ---- - -`Bundle::component_ids` and `Bundle::get_component_ids` were changed to return an iterator over -`ComponentId` and `Option` respectively. In some cases this can avoid allocating. - -```rust -// For implementors -// Before -unsafe impl Bundle for C { - fn component_ids(components: &mut ComponentsRegistrator, ids: &mut impl FnMut(ComponentId)) { - ids(components.register_component::()); - } - - fn get_component_ids(components: &Components, ids: &mut impl FnMut(Option)) { - ids(components.get_id(TypeId::of::())); - } -} - -// After -unsafe impl Bundle for C { - fn component_ids<( - components: &mut ComponentsRegistrator, - // we use a `use` here to explicitly not capture the lifetime of `components` - ) -> impl Iterator + use { - iter::once(components.register_component::()) - } - - fn get_component_ids(components: &Components) -> impl Iterator> { - iter::once(components.get_id(TypeId::of::())) - } -} -``` - -```rust -// For Consumers -// Before -let mut components = vec![]; -MyBundle::component_ids(&mut world.components_registrator(), &mut |id| { - components.push(id); -}); - -// After -let components: Vec<_> = B::component_ids(&mut world.components_registrator()).collect(); -``` diff --git a/release-content/migration-guides/cargo_feature_collections.md b/release-content/migration-guides/cargo_feature_collections.md deleted file mode 100644 index 61f1527039cf7..0000000000000 --- a/release-content/migration-guides/cargo_feature_collections.md +++ /dev/null @@ -1,8 +0,0 @@ ---- -title: Cargo Feature Collections -pull_requests: [21472] ---- - -Bevy now has high-level cargo feature collections (ex: `2d`, `3d`, `ui`) and mid-level feature collections (ex: `2d_api`, `3d_api`, `default_app`, `default_platform`). This isn't technically a breaking change, but if you were previously disabling Bevy's default features and manually enabling each specific cargo feature you wanted, we _highly_ recommend switching to using the higher level feature collections wherever possible. This will make it much easier to define the functionality you want, and it will reduce the burden of keeping your list of features up to date across Bevy releases. - -See the Cargo Feature Collections pull request for a full list of options. diff --git a/release-content/migration-guides/change_detection_refactors.md b/release-content/migration-guides/change_detection_refactors.md deleted file mode 100644 index 16f0929eefb32..0000000000000 --- a/release-content/migration-guides/change_detection_refactors.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: "Tick-related refactors" -pull_requests: [21562, 21613] ---- - -`TickCells` is now `ComponentTickCells`. - -`ComponentSparseSet::get_with_ticks` now returns `Option<(Ptr, ComponentTickCells)>` instead of `Option<(Ptr, TickCells, MaybeLocation)>`. - -The following types have been moved from the `component` module to the `change_detection` module: - -- `Tick` -- `ComponentTicks` -- `ComponentTickCells` -- `CheckChangeTicks` diff --git a/release-content/migration-guides/changed_asset_server_init.md b/release-content/migration-guides/changed_asset_server_init.md deleted file mode 100644 index ae0735c6c4d15..0000000000000 --- a/release-content/migration-guides/changed_asset_server_init.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -title: Changes to `AssetServer` and `AssetProcessor` creation. -pull_requests: [21763] ---- - -Previously `AssetServer`s `new` methods would take `AssetSources`. Now, these methods take -`Arc`. So if you previously had: - -```rust -AssetServer::new( - sources, - mode, - watching_for_changes, - unapproved_path_mode, -) - -// OR: -AssetServer::new_with_meta_check( - sources, - mode, - meta_check, - watching_for_changes, - unapproved_path_mode, -) -``` - -Now you need to do: - -```rust -AssetServer::new( - Arc::new(sources), - mode, - watching_for_changes, - unapproved_path_mode, -) - -// OR: -AssetServer::new_with_meta_check( - Arc::new(sources), - mode, - meta_check, - watching_for_changes, - unapproved_path_mode, -) -``` - -`AssetProcessor::new` has also changed. It now returns to you the `Arc` which can (and -should) be shared with the `AssetServer`. So if you previously had: - -```rust -let processor = AssetProcessor::new(sources); -``` - -Now you need: - -```rust -let (processor, sources_arc) = AssetProcessor::new( - sources, - // A bool whether the returned sources should listen for changes as asset processing completes. - false, -); -``` diff --git a/release-content/migration-guides/combinator_system.md b/release-content/migration-guides/combinator_system.md deleted file mode 100644 index 7af01c344e41c..0000000000000 --- a/release-content/migration-guides/combinator_system.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: System Combinators -pull_requests: [20671] ---- - -The `CombinatorSystem`s can be used to combine multiple `SystemCondition`s with logical operators. Previously, the conditions would short circuit if the system failed to run, for example because it's query could not be filled by the world. - -Now, the `CombinatorSystem`s will work as expected, following the semantics of rust's logical operators. -Namely, if a `SystemCondition` fails, it will be considered to have returned `false` and in combinators that don't short circuit the other condition will now be run. - -Specifically, the combinators act as follows: - -| Combinator | Rust Equivalent | -|:----------:|:---------------:| -| `and` | `a && b` | -| `or` | `a \|\| b` | -| `xor` | `a ^ b` | -| `nand` | `!(a && b)` | -| `nor` | `!(a \|\| b)` | -| `xnor` | `!(a ^ b)` | - -```rust -fn vacant(_: crate::system::Single<&Vacant>) -> bool { - true -} - -fn is_true() -> bool { - true -} - -assert!(world.query::<&Vacant>().iter(&world).next().is_none()); - -// previously: -assert!(world.run_system_once(is_true.or(vacant)).is_err()); - -// now: -assert!(matches!(world.run_system_once(is_true.or(vacant)), Ok(true))); -``` diff --git a/release-content/migration-guides/custom_asset_source_infallible.md b/release-content/migration-guides/custom_asset_source_infallible.md deleted file mode 100644 index 4a921982525ff..0000000000000 --- a/release-content/migration-guides/custom_asset_source_infallible.md +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: Custom asset sources now require a reader. -pull_requests: [21721] ---- - -Previously, it was possible to create asset sources with no reader, resulting in your asset sources -silently being skipped. This is no longer possible, since `AssetSourceBuilder` must now be given a -reader to start. We also slightly changed how sources are expected to be built. - -In previous versions, creating a custom source would look like: - -```rust -AssetSource::build() - .with_reader(move || todo!("the reader!")) - .with_writer(move || todo!()) - .with_processed_reader(move || todo!()) - .with_processed_writer(move || todo!()) -``` - -In Bevy 0.18, this now looks like: - -```rust -// You may need to import AssetSourceBuilder. -AssetSourceBuilder::new(move || todo!("the reader!")) - .with_writer(move || todo!()) - .with_processed_reader(move || todo!()) - .with_processed_writer(move || todo!()) -``` diff --git a/release-content/migration-guides/derive_compile_error_for_non_static_resource.md b/release-content/migration-guides/derive_compile_error_for_non_static_resource.md deleted file mode 100644 index 45e4b57419623..0000000000000 --- a/release-content/migration-guides/derive_compile_error_for_non_static_resource.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: Derive on Resource will fail when using non-static lifetimes -pull_requests: [21385] ---- - -Any type with `#[derive(Resource)]` that uses non-static lifetime will no longer compile. - -```rust -// Will no longer compile in 0.18, -// 'a should be 'static -#[derive(Resource)] -struct Foo<'a> { - bar: &'a str -} -``` diff --git a/release-content/migration-guides/dragenter-now-fires-on-drag-starts.md b/release-content/migration-guides/dragenter-now-fires-on-drag-starts.md deleted file mode 100644 index 187067a05cb82..0000000000000 --- a/release-content/migration-guides/dragenter-now-fires-on-drag-starts.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: "DragEnter now fires on drag starts" -pull_requests: [21999] ---- - -`DragEnter` now also fires when a drag starts over an already hovered entity. diff --git a/release-content/migration-guides/draw_functions.md b/release-content/migration-guides/draw_functions.md deleted file mode 100644 index b9d843bf49232..0000000000000 --- a/release-content/migration-guides/draw_functions.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Per-RenderPhase Draw Functions" -pull_requests: [21021] ---- - -This PR makes draw function labels in `MaterialProperties` per-`RenderPhase` instead -of per-pass. This should only affect users of the low-level "manual Material" API, -and not users of the broader Material API. Specifying all draw functions is not -mandatory, but users should specify draw functions for all render phases the -material may queue to, or the material may not render. - -- Removed `MaterialDrawFunction` in favor of: - - `MainPassOpaqueDrawFunction` - - `MainPassAlphaMaskDrawFunction` - - `MainPassTransmissiveDrawFunction` - - `MainPassTransparentDrawFunction` - -- Removed `PrepassDrawFunction` in favor of: - - `PrepassOpaqueDrawFunction` - - `PrepassAlphaMaskDrawFunction` - -- Removed `DeferredDrawFunction` in favor of: - - `DeferredOpaqueDrawFunction` - - `DeferredAlphaMaskDrawFunction` diff --git a/release-content/migration-guides/dynamic_relationships_api.md b/release-content/migration-guides/dynamic_relationships_api.md deleted file mode 100644 index 9317ad8a32d4f..0000000000000 --- a/release-content/migration-guides/dynamic_relationships_api.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: API for working with `Relationships` and `RelationshipTargets` in type-erased contexts -pull_requests: [21601] ---- - -`ComponentDescriptor` now stores additional data for working with relationships in dynamic contexts. -This resulted in changes to `ComponentDescriptor::new_with_layout`: - -- Now requires additional parameter `relationship_accessor`, which should be set to `None` for all existing code creating `ComponentDescriptors`. diff --git a/release-content/migration-guides/enable_prepass.md b/release-content/migration-guides/enable_prepass.md deleted file mode 100644 index 32ea69d646bed..0000000000000 --- a/release-content/migration-guides/enable_prepass.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "`enable_prepass` and `enable_shadows` are now Material methods" -pull_requests: [20999] ---- - -The `MaterialPlugin` fields `prepass_enabled` and `shadows_enabled` have -been replaced by the `Material` methods `enable_prepass` and `enable_shadows`. - -Analogous methods have also been added to `MaterialExtension` - -```rust -/// before -MaterialPlugin:: { - prepass_enabled: false, - shadows_enabled: false, -} - -/// after -impl Material for MyMaterial { - /// ... - - fn enable_prepass() { false } - fn enable_shadows() { false } -} -``` diff --git a/release-content/migration-guides/entities_apis.md b/release-content/migration-guides/entities_apis.md deleted file mode 100644 index ebc475c69c465..0000000000000 --- a/release-content/migration-guides/entities_apis.md +++ /dev/null @@ -1,71 +0,0 @@ ---- -title: Entities APIs -pull_requests: [19350, 19433, 19451] ---- - -Entities are spawned by allocating their id and then giving that id a location within the world. -In 0.17, this was done in one stroke through `spawn` and `Entities::flush`. -In 0.18, the flushing functionality has been removed in favor of `spawn`ing individual `EntityRow`s instead. -Don't worry, these changes don't affect the common operations like `spawn` and `despawn`, but the did impact the peripheral interfaces and error types. -For a full explanation of the new entity paradigm, errors and terms, see the new `entity` module docs. -If you want more background for the justification of these changes or more information about where these new terms come from, see pr #19451. -This opens up a lot of room for performance improvement but also caused a lot of breaking changes: - -## `Entities` rework - -A lot has changed here. -First, `alloc`, `free`, `reserve`, `reserve_entity`, `reserve_entities`, `flush`, `flush_as_invalid`, `EntityDoesNotExistError`, `total_count`, `used_count`, and `total_prospective_count` have all been removed 😱. - -Allocation has moved to the new `EntitiesAllocator` type, accessible via `World::entities_allocator` and `World::entities_allocator_mut`, which have `alloc`, `free`, and `alloc_many`. - -Reservation and flushing have been completely removed as they are no longer needed. -Instead of reserving an entity and later flushing it, you can `EntitiesAllocator::alloc` (which does not need mutable access), and `World::spawn_at` can be used to "flush" the entity. - -The counting methods have been reworked in the absence of flushing: -`len` and `is_empty` now deal with how many entity rows have been allocated (not necessarily the number that have been spawned), -and the new `count_spawned` and `any_spawned` are similar to the old `len` and `is_empty` behavior but are now O(n). - -In terms of getting information from `Entities`, `get` and `contains` has been reworked to include non-spawned entities. -If you only want spawned entities, `get_spawned` and `contains_spawned` are available. -Additionally, `get` now returns `Result, InvalidEntityError>` instead of `Option` for clarity. -Entities now may or may not have a location, depending on if it is spawned or not. - -`EntityDoesNotExistError` has been removed and reworked. -See the new entity module docs for more, but: -When an entity's generation is not up to date with its row, `InvalidEntityError` is produced. -When an entity index's `Option` is `None`, `EntityValidButNotSpawnedError` is produced. -When an `Entity` is expected to be spawned but is not (either because its generation is outdated or because its row is not spawned), `EntityNotSpawnedError` is produced. -A few other wrapper error types have slightly changed as well, generally moving from "entity does not exist" to "entity is not spawned". - -### Entity Ids - -Entity ids previously used "row" terminology, but now use "index" terminology as that more closely specifies its current implementation. -As such, all functions and types dealing with the previous `EntityRow` have had their names 1 to 1 mapped to index. -Ex: `EntityRow` -> `EntityIndex`, `Entity::row` -> `Entity::index`, `Entity::from_row` -> `Entity::from_index`, etc. -Note that `Entity::index` did exist before. It served to give the numeric representation of the `EntityRow`. -The same functionality exists, now under `Entity::index_u32`. - -### Entity Pointers - -When migrating, entity pointers, like `EntityRef`, were changed to assume that the entity they point to is spawned. -This was not necessarily checked before, so the errors for creating an entity pointer is now `EntityNotSpawnedError`. -This probably will not affect you since creating a pointer to an entity that was not spawned is kinda pointless. - -It is still possible to invalidate an `EntityWorldMut` by despawning it from commands. (Ex: The hook for adding a component to an entity actually despawns the entity it was added to.) -If that happens, it may lead to panics, but `EntityWorldMut::is_spawned` has been added to help detect that. - -### Entity Commands - -`Commands::new_from_entities` now also needs `&EntitiesAllocator`, which can be obtained from `UnsafeWorldCell::entities_allocator`. -`Commands::get_entity` does not error for non-spawned entities, making it useful to amend an entity you have queued to spawn through commands. -If you only want spawned entities, use `Commands::get_spawned_entity`. - -### Other entity interactions - -The `ArchetypeRow::INVALID` and `ArchetypeId::INVALID` constants have been removed, since they are no longer needed for flushing. -If you depended on these, use options instead. - -`BundleSpawner::spawn_non_existent` is now `BundleSpawner::construct`. -`World::inspect_entity` now errors with `EntityNotSpawnedError` instead of `EntityDoesNotExistError`. -`QueryEntityError::EntityDoesNotExist` is now `QueryEntityError::NotSpawned`. -`ComputeGlobalTransformError::NoSuchEntity` and `ComputeGlobalTransformError::MalformedHierarchy` now wrap `EntityNotSpawnedError`. diff --git a/release-content/migration-guides/extracted_uinodes_z_order.md b/release-content/migration-guides/extracted_uinodes_z_order.md deleted file mode 100644 index 4f6fd4ef41596..0000000000000 --- a/release-content/migration-guides/extracted_uinodes_z_order.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -title: "`ExtractedUiNode`'s `stack_index` has been renamed to `z_order` and is now an `f32`." -pull_requests: [19691] ---- - -`ExtractedUiNode`’s `stack_index` field has been renamed to `z_order` and its type changed from `u32` to `f32`. -Previously `stack_index` would be converted into an `f32` after extraction during the `Render` schedule, then -offsets would be applied to determine draw order before sorting (lowest value rendered first). -For example, a node's fill color is given an offset of `0.` and a box shadow is given an offset of `-0.1`, so that -the shadow will be drawn behind the node. - -Changing the field to an `f32`, enables finer control of the UI draw order by allowing these offsets to be applied during extraction, -and fixes a bug affecting the ordering of texture-sliced nodes. diff --git a/release-content/migration-guides/feature-cleanup.md b/release-content/migration-guides/feature-cleanup.md deleted file mode 100644 index d36ceb1d0b760..0000000000000 --- a/release-content/migration-guides/feature-cleanup.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: Feature cleanup -pull_requests: [21388, 21435, 21436, 21437] ---- - -`animation` has been renamed to `gltf_animation`. -`bevy_sprite_picking_backend` has been renamed to `sprite_picking`. -`bevy_ui_picking_backend` has been renamed to `ui_picking`. -`bevy_mesh_picking_backend` has been renamed to `mesh_picking`. diff --git a/release-content/migration-guides/function_system_generics.md b/release-content/migration-guides/function_system_generics.md deleted file mode 100644 index a302dd72cf329..0000000000000 --- a/release-content/migration-guides/function_system_generics.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: "FunctionSystem Generics" -authors: ["@ecoskey"] -pull_requests: [21917] ---- - -`FunctionSystem` now has a new generic parameter: `In`. - -Old: `FunctionSystem` -New: `FunctionSystem` - -Additionally, there's an extra bound on the `System` and `IntoSystem` impls -related to `FunctionSystem`: - -`::In: FromInput` - -This enabled systems to take as input any *compatible* type, in addition to the -exact one specified by the system function. This shouldn't impact users at all -since it only adds functionality, but users writing heavily generic code may -want to add a similar bound. See `function_system.rs` to see how it works in -practice. diff --git a/release-content/migration-guides/generalized_atmosphere.md b/release-content/migration-guides/generalized_atmosphere.md deleted file mode 100644 index 14bcd8a621997..0000000000000 --- a/release-content/migration-guides/generalized_atmosphere.md +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: "Generalized Atmospheric Scattering Media" -authors: ["@ecoskey"] -pull_requests: [20838] ---- - -Most of the fields on `Atmosphere` have been removed in favor of a handle -to the new `ScatteringMedium` asset. - -```diff -pub struct Atmosphere { - pub bottom_radius: f32, - pub top_radius: f32, - pub ground_albedo: Vec3, -+ pub medium: Handle, -- pub rayleigh_density_exp_scale: f32, -- pub rayleigh_scattering: Vec3, -- pub mie_density_exp_scale: f32, -- pub mie_scattering: f32, -- pub mie_absorption: f32, -- pub mie_asymmetry: f32, -- pub ozone_layer_altitude: f32, -- pub ozone_layer_width: f32, -- pub ozone_absorption: Vec3, -} -``` - -Unfortunately, this means `Atmosphere` no longer implements `Default`. Instead, -you can still access the default earthlike atmosphere through the -`EarthlikeAtmosphere` resource: - -```rust -fn setup_camera( - mut commands: Commands, - earthlike_atmosphere: Res -) { - commands.spawn(( - Camera3d, - earthlike_atmosphere.get(), - )); -} -``` diff --git a/release-content/migration-guides/get_components.md b/release-content/migration-guides/get_components.md deleted file mode 100644 index f91a5e44300d6..0000000000000 --- a/release-content/migration-guides/get_components.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: get_components, get_components_mut_unchecked now return a Result -pull_requests: [21780] ---- - -`get_components`, `get_components_mut_unchecked`, and `into_components_mut_unchecked` -now return a `Result<_, QueryAccessError>` instead of an `Option`. diff --git a/release-content/migration-guides/get_many_renamed_to_get_disjoint.md b/release-content/migration-guides/get_many_renamed_to_get_disjoint.md deleted file mode 100644 index 6af887e7b7004..0000000000000 --- a/release-content/migration-guides/get_many_renamed_to_get_disjoint.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -title: Renamed `bevy_platform::HashMap::get_many_*` to `bevy_platform::HashMap::get_disjoint_*` -pull_requests: [21898] ---- - -Matching both [`hashbrown`](https://github.com/rust-lang/hashbrown/pull/648) and the `std` library, -we've renamed all the `get_many_*` methods on `bevy_platform::HashMap` to `get_disjoint_*`. So -rename: - -- `get_many_mut` -> `get_disjoint_mut` -- `get_many_unchecked_mut` -> `get_disjoint_unchecked_mut` -- `get_many_key_value_mut` -> `get_disjoint_key_value_mut` -- `get_many_key_value_unchecked_mut` -> `get_disjoint_key_value_unchecked_mut` diff --git a/release-content/migration-guides/gizmos-cuboid.md b/release-content/migration-guides/gizmos-cuboid.md deleted file mode 100644 index 2b936a5278f23..0000000000000 --- a/release-content/migration-guides/gizmos-cuboid.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: "`Gizmos::cuboid` has been renamed to `Gizmos::cube`" -pull_requests: [21393] ---- - -`Gizmos::cuboid` was renamed to `Gizmos::cube`. diff --git a/release-content/migration-guides/gizmos-render.md b/release-content/migration-guides/gizmos-render.md deleted file mode 100644 index 7e8d8773f5034..0000000000000 --- a/release-content/migration-guides/gizmos-render.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: "`bevy_gizmos` rendering split" -pull_requests: [21536] ---- - -The rendering backend of `bevy_gizmos` has been split off into `bevy_gizmos_render`. -If you were using `default-features = false` and `bevy_gizmos` and `bevy_render`, you may want to enable the `bevy_gizmos_render` feature now. diff --git a/release-content/migration-guides/gltf-coordinate-conversion.md b/release-content/migration-guides/gltf-coordinate-conversion.md deleted file mode 100644 index fda7db176f789..0000000000000 --- a/release-content/migration-guides/gltf-coordinate-conversion.md +++ /dev/null @@ -1,96 +0,0 @@ ---- -title: glTF Coordinate Conversion -pull_requests: [20394] ---- - -**Bevy 0.17** added experimental options for coordinate conversion of glTF -files - `GltfPlugin::use_model_forward_direction` and -`GltfLoaderSettings::use_model_forward_direction`. In **Bevy 0.18** these -options have changed. The options are disabled by default, so if you haven't -enabled them then your glTFs will work the same as before. - -The goal of coordinate conversion is to take objects that face forward in the -glTF and change them to match the direction of Bevy's `Transform::forward`. -Conversion is necessary because glTF's standard scene forward is +Z, while -Bevy's is -Z (although not all glTF files follow the standard, and there are -exceptions for cameras and lights). - -In 0.17 the conversion was applied to nodes and meshes within glTF scenes. -This worked well for some users, but had -[bugs](https://github.com/bevyengine/bevy/issues/20621) and didn't work well for -other users. In particular, node conversion caused issues with cameras and -lights. - -In 0.18 there are two changes. Firstly, the `use_model_forward_direction` option -has been renamed to `convert_coordinates`, and is now a struct with two separate -options. - -```diff - struct GltfPlugin { - ... -- use_model_forward_direction: bool, -+ convert_coordinates: GltfConvertCoordinates, - } -``` - -```rust -struct GltfConvertCoordinates { - rotate_scene_entity: bool, - rotate_meshes: bool, -} -``` - -Secondly, the conversion behavior has changed. Nodes within the glTF scene are -no longer converted - instead a new conversion is applied to the scene entity -and mesh primitive entities. Whether these changes affect you will depend on how -you're using glTFs. - -- If you never enabled the 0.17 conversion then you don't need to change - anything - conversion remains disabled by default in 0.18. To check if you - enabled the conversion, search for `use_model_forward_direction`. - -- If you simply spawn your glTF via `SceneRoot` and want it to visually match - the `Transform::forward` of the entity it's spawned on, then you're still - supported. The internals of the scene will be different in 0.18, but the - visual result will be the same. The only option you need to enable is `GltfConvertCoordinates::rotate_scene_entity`. - -- If you want the `Mesh` assets in your glTF to be converted then you're - supported by the `GltfConvertCoordinates::rotate_meshes` option. This can be - combined with the `rotate_scene_entity` option if you want both. - -- If you enabled the 0.17 conversion and aren't sure what to enable in 0.18, - try enabling both the `rotate_scene_entity` and `rotate_meshes` options. This - will be closest to the 0.17 behavior. - -- If you tried the 0.17 conversion but found it caused issues with cameras or - lights, then the 0.18 conversion should fix these issues. - -- If you relied on node conversion, you'll find that 0.18 no longer applies that - conversion. This change was made to avoid bugs and give other users more - options. - -If you want to try out glTF coordinate conversion, the simplest method is to -set `GltfPlugin::convert_coordinates` - this option can be set on app startup, -and is applied to all glTFs when they're loaded. For an app that uses -`DefaultPlugins`, the example below shows how to enable just scene conversion. - -```rust -App::new() - .add_plugins(DefaultPlugins.set(GltfPlugin { - convert_coordinates: GltfConvertCoordinates { rotate_scene_entity: true, ..default() }, - ..default() - })) - .run(); -``` - -If you want finer control, you can choose the option per-glTF with -`GltfLoaderSettings`. - -```rust -let handle = asset_server.load_with_settings( - "fox.gltf#Scene0", - |settings: &mut GltfLoaderSettings| { - settings.convert_coordinates = Some(GltfConvertCoordinates { rotate_scene_entity: true, ..default() }); - }, -); -``` diff --git a/release-content/migration-guides/image_loader_array_layout.md b/release-content/migration-guides/image_loader_array_layout.md deleted file mode 100644 index bca9fcb18bc5a..0000000000000 --- a/release-content/migration-guides/image_loader_array_layout.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: Image Loader Array Layout -pull_requests: [21628] ---- - -`ImageLoader` now supports loading array textures using the new `ImageLoaderSettings::array_layout` setting. - -In previous versions, loading an array texture generally required a system that waited for the asset to load, then called `Image::reinterpret_stacked_2d_as_array`. Now the `ImageLoader` can do that for you automatically. - -```rs -use bevy::image::{ImageLoaderSettings, ImageArrayLayout}; - -let array_texture = asset_server.load_with_settings( - "textures/array_texture.png", - |settings: &mut ImageLoaderSettings| { - // Load the image as a stacked array of 4 textures. - settings.array_layout = Some(ImageArrayLayout::RowCount { rows: 4 }); - }, -); -``` diff --git a/release-content/migration-guides/image_reinterpret_returns_result.md b/release-content/migration-guides/image_reinterpret_returns_result.md deleted file mode 100644 index 29280afa5a5e6..0000000000000 --- a/release-content/migration-guides/image_reinterpret_returns_result.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: "Image::reinterpret_size and Image::reinterpret_stacked_2d_as_array now return a Result" -pull_requests: [20797] ---- - -`Image::reinterpret_size` and `Image::reinterpret_stacked_2d_as_array` now return a `Result` instead of panicking. - -Previously, calling this method on image assets that did not conform to certain constraints could lead to runtime panics. The new return type makes the API safer and more explicit about the constraints. - -To migrate your code, you will need to handle the `Result` returned by `Image::reinterpret_size` or `Image::reinterpret_stacked_2d_as_array`. diff --git a/release-content/migration-guides/image_render_target_scale_factor_is_now_f32.md b/release-content/migration-guides/image_render_target_scale_factor_is_now_f32.md deleted file mode 100644 index afe4c4d1f56fb..0000000000000 --- a/release-content/migration-guides/image_render_target_scale_factor_is_now_f32.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: "`ImageRenderTarget`s `scale_factor` field is now an `f32`" -pull_requests: [ 21054 ] ---- - -The `scale_factor` field on `ImageRenderTarget` is now an `f32` and no longer requires wrapping in `FloatOrd`. diff --git a/release-content/migration-guides/immutable-entity-events.md b/release-content/migration-guides/immutable-entity-events.md deleted file mode 100644 index 3d1e8b162149f..0000000000000 --- a/release-content/migration-guides/immutable-entity-events.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: "Immutable Entity Events" -pull_requests: [21408] ---- - -The mutable methods of `EntityEvent` (`EntityEvent::from` and `EntityEvent::event_target_mut`) -have been moved to a separate trait: `SetEntityEventTarget` - -This makes all `EntityEvents` immutable by default. - -`SetEntityEventTarget` is implemented automatically for propagated events (e.g. `#[entity_event(propagate)]`). diff --git a/release-content/migration-guides/internal_disabling_component_removed.md b/release-content/migration-guides/internal_disabling_component_removed.md deleted file mode 100644 index 4694885554cfc..0000000000000 --- a/release-content/migration-guides/internal_disabling_component_removed.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "`Internal` has been removed" -pull_requests: [ 21623 ] ---- - -The `Internal` component, previously added as a required component to both one-shot systems and observer entities has been removed. - -You can remove all references to it: these entities are no longer hidden by default query filters. -If you have tests which rely on a specific number of entities existing in the world, -you should refactor them to query for entities with a component that you care about: -this is much more robust in general. - -This component was previously motivated by two factors: - -1. A desire to protect users from accidentally modifying engine internals, breaking their app in subtle and complex ways. -2. A unified API for entity inspectors, allowing them to readily distinguish between "engine-internal" and "user-defined" entities. - -In practice, we found that this increased user friction and confusion without meaningfully improving robustness. -Entity inspectors and similar tools can and should define their own entity categorization functionality: -simply lumping all "internal" entities together is rarely helpful. diff --git a/release-content/migration-guides/lineheight_is_now_a_separate_component.md b/release-content/migration-guides/lineheight_is_now_a_separate_component.md deleted file mode 100644 index 8a8ed6d5f2fa8..0000000000000 --- a/release-content/migration-guides/lineheight_is_now_a_separate_component.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: "`LineHeight` is now a separate component" -pull_requests: [] ---- - -The `line_height` field has been removed from `TextFont`. `LineHeight` is now a component required by `Text`, `Text2d`, and `TextSpan`. diff --git a/release-content/migration-guides/load_context_asset_path.md b/release-content/migration-guides/load_context_asset_path.md deleted file mode 100644 index c4a2e58b585ae..0000000000000 --- a/release-content/migration-guides/load_context_asset_path.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -title: LoadContext::path now returns `AssetPath`. -pull_requests: [21713] ---- - -`LoadContext::asset_path` has been removed, and `LoadContext::path` now returns `AssetPath`. So the -migrations are: - -- `load_context.asset_path()` -> `load_context.path()` -- `load_context.path()` -> `load_context.path().path()` - - While this migration will keep your code running, seriously consider whether you need to use - the `Path` itself. The `Path` does not support custom asset sources, so care needs to be taken - when using it directly. Consider instead using the `AssetPath` instead, along with - `AssetPath::resolve_embed`, to properly support custom asset sources. diff --git a/release-content/migration-guides/process_trait_changes.md b/release-content/migration-guides/process_trait_changes.md deleted file mode 100644 index 0b043a60e0845..0000000000000 --- a/release-content/migration-guides/process_trait_changes.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: Changes to the `Process` trait in `bevy_asset`. -pull_requests: [21925] ---- - -`ProcessContext` no longer includes `asset_bytes`. This has been replaced by `asset_reader`. To -maintain current behavior in a `Process` implementation, you can read all the bytes into memory. -If previously, you did: - -```rust -// Inside `impl Process for Type` -let bytes = context.asset_bytes(); -// Use bytes here! -``` - -Then now, it should be: - -```rust -// Inside `impl Process for Type` -let reader = context.asset_reader(); -let mut bytes = vec![]; -reader - .read_to_end(&mut bytes) - .await - .map_err(|err| ProcessError::AssetReaderError { - path: context.path().clone_owned(), - err: err.into(), - })?; -// Use bytes here! -``` diff --git a/release-content/migration-guides/reader_required_features.md b/release-content/migration-guides/reader_required_features.md deleted file mode 100644 index c9fda72f2986c..0000000000000 --- a/release-content/migration-guides/reader_required_features.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: The `AssetReader` trait now takes a `ReaderRequiredFeatures` argument. -pull_requests: [] ---- - -The `AssetReader::read` method now takes an additional `ReaderRequiredFeatures` argument. If -previously you had: - -```rust -struct MyAssetReader; - -impl AssetReader for MyAssetReader { - async fn read<'a>( - &'a self, - path: &'a Path, - ) -> Result { - todo!() - } - - // more stuff... -} -``` - -Change this to: - -```rust -struct MyAssetReader; - -impl AssetReader for MyAssetReader { - async fn read<'a>( - &'a self, - path: &'a Path, - _required_features: ReaderRequiredFeatures, - ) -> Result { - todo!() - } - - // more stuff... -} -``` diff --git a/release-content/migration-guides/readers_impl_async_seek.md b/release-content/migration-guides/readers_impl_async_seek.md deleted file mode 100644 index d2957efc6a220..0000000000000 --- a/release-content/migration-guides/readers_impl_async_seek.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: Implementations of `Reader` now must implement `AsyncSeek`, and `AsyncSeekForward` is deleted. -pull_requests: [] ---- - -The `Reader` trait no longer requires implementing `AsyncSeekForward` and instead requires -implementing `AsyncSeek`. Each reader will have its own unique implementation so implementing this -will be case specific. The simplest implementation is to simply reject these seeking cases like so: - -```rust -impl AsyncSeek for MyReader { - fn poll_seek( - self: Pin<&mut Self>, - _cx: &mut core::task::Context<'_>, - pos: SeekFrom, - ) -> Poll> { - let forward = match pos { - SeekFrom::Current(curr) if curr >= 0 => curr as u64, - _ => return std::io::Error::new( - std::io::ErrorKind::InvalidInput, - "invalid seek mode", - ), - }; - - // Do whatever your previous `AsyncSeekForward` implementation did... - } -} -``` - -In addition, the `AssetReader` trait now includes a `ReaderRequiredFeatures` argument which can be -used to return an error early for invalid requests. For example: - -```rust -impl AssetReader for MyAssetReader { - async fn read<'a>( - &'a self, - path: &'a Path, - required_features: ReaderRequiredFeatures, - ) -> Result { - match required_features.seek { - SeekKind::Forward => {} - SeekKind::AnySeek => return Err(UnsupportedReaderFeature::AnySeek), - } - - // Do whatever your previous `AssetReader` implementation did, like... - Ok(MyReader) - } -} -``` - -Since we now just use the `AsyncSeek` trait, we've deleted the `AsyncSeekForward` trait. Users of -this trait can migrate by calling the `AsyncSeek::poll_seek` method with -`SeekFrom::Current(offset)`, or the `AsyncSeekExt::seek` method. diff --git a/release-content/migration-guides/reflect_parentheses.md b/release-content/migration-guides/reflect_parentheses.md deleted file mode 100644 index 7f71f740e89db..0000000000000 --- a/release-content/migration-guides/reflect_parentheses.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: "`#[reflect(...)]` now supports only parentheses" -pull_requests: [21400] ---- - -Previously, the `#[reflect(...)]` attribute of the `Reflect` derive macro -supported parentheses, braces, or brackets, to standardize the syntax going -forward, it now supports only parentheses. - -```rust -/// before -#[derive(Clone, Reflect)] -#[reflect[Clone]] - -/// after -#[derive(Clone, Reflect)] -#[reflect(Clone)] - -/// before -#[derive(Clone, Reflect)] -#[reflect{Clone}] - -/// after -#[derive(Clone, Reflect)] -#[reflect(Clone)] -``` diff --git a/release-content/migration-guides/remove-dummy-white-gpu-image.md b/release-content/migration-guides/remove-dummy-white-gpu-image.md deleted file mode 100644 index 5ef7058d06ad7..0000000000000 --- a/release-content/migration-guides/remove-dummy-white-gpu-image.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: "Removed `dummy_white_gpu_image`" -pull_requests: [21572] ---- - -`MeshPipeline`, `Mesh2dPipeline` and `SpritePipeline` no longer have `dummy_white_gpu_image`. - -`MeshPipeline` and `Mesh2dPipeline` no longer have `get_image_texture()` in their `impl`. - -The method `build_dummy_white_gpu_image()` and `get_image_texture()` can be used if needed. diff --git a/release-content/migration-guides/remove_dangling_with_align.md b/release-content/migration-guides/remove_dangling_with_align.md deleted file mode 100644 index 71fbd10e859c9..0000000000000 --- a/release-content/migration-guides/remove_dangling_with_align.md +++ /dev/null @@ -1,14 +0,0 @@ ---- -title: Remove `bevy::ptr::dangling_with_align()` -pull_requests: [21822] ---- - -`bevy::ptr::dangling_with_align()` has been removed. Use `NonNull::without_provenance()` instead: - -```rust -// 0.17 -let ptr = dangling_with_align(align); - -// 0.18 -let ptr = NonNull::without_provenance(align); -``` diff --git a/release-content/migration-guides/remove_ron_reexport.md b/release-content/migration-guides/remove_ron_reexport.md deleted file mode 100644 index bf10d66b536ba..0000000000000 --- a/release-content/migration-guides/remove_ron_reexport.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -title: Remove ron re-export from bevy_scene and bevy_asset -pull_requests: [21611] ---- - -The `ron` crate is no longer re-exported from `bevy_scene` or `bevy_asset`. This was done to reduce naming conflicts and improve API clarity. - -If you were importing `ron` through `bevy_scene` or `bevy_asset`, you should now add `ron` as a direct dependency to your project. - -This change only affects code that was explicitly importing the `ron` module. All internal scene serialization and deserialization functionality remains unchanged. diff --git a/release-content/migration-guides/removed-font-atlas-sets.md b/release-content/migration-guides/removed-font-atlas-sets.md deleted file mode 100644 index 33c303a20b1e6..0000000000000 --- a/release-content/migration-guides/removed-font-atlas-sets.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: Removed `FontAtlasSets` -pull_requests: [21345] ---- - -* `FontAtlasSets` has been removed. -* `FontAtlasKey` now newtypes a `(AssetId, u32, FontSmoothing)`. -* `FontAtlasSet` is now a resource. It newtypes a `HashMap>` and derives `Deref` and `DerefMut`. -* Font atlases are looked up directly using a `FontAtlasKey`, there's no longer a separate `AssetId` to `FontAtlasKey` map. -* `remove_dropped_font_atlas_sets` has been renamed to `free_unused_font_atlases_system`. -* The `FontAtlasSet` methods `add_glyph_to_atlas`, `get_glyph_atlas_info`, and `get_outlined_glyph_texture` have been moved into the `font_atlas` module and reworked into free functions. diff --git a/release-content/migration-guides/removed_simple_executor.md b/release-content/migration-guides/removed_simple_executor.md deleted file mode 100644 index 02bbcfdb600de..0000000000000 --- a/release-content/migration-guides/removed_simple_executor.md +++ /dev/null @@ -1,16 +0,0 @@ ---- -title: Removed `SimpleExecutor` -pull_requests: [21176] ---- - -Bevy has removed the previously deprecated `SimpleExecutor`, one of the `SystemExecutor`s in Bevy alongside `SingleThreadedExecutor` and `MultiThreadedExecutor` (which aren't going anywhere any time soon). -The `MultiThreadedExecutor` is great at large schedules and async heavy work, and the `SingleThreadedExecutor` is good at smaller schedules or schedules that have fewer parallelizable systems. -So what was `SimpleExecutor` good at? Not much. That's why it was removed. Removing it reduced some maintenance and consistency burdens on maintainers, allowing them to focus on more exciting features! - -If you were using `SimpleExecutor`, consider upgrading to `SingleThreadedExecutor` instead, or try `MultiThreadedExecutor` if it fits the schedule. -It's worth mentioning that `SimpleExecutor` ran deferred commands inbetween *each* system, regardless of if it was needed. -The other executors are more efficient about this, but that means they need extra information about when to run those commands. -In most schedules, that information comes from the contents and ordering of systems, via `before`, `after`, `chain`, etc. -If a schedule that was previously using `SimpleExecutor` still needs commands from one system to be applied before another system runs, -make sure that ordering is enforced explicitly by these methods, rather than implicitly by the order of `add_systems`. -If you are looking for a quick fix, `chain` is the easiest way to do this. diff --git a/release-content/migration-guides/rename-clear_children.md b/release-content/migration-guides/rename-clear_children.md deleted file mode 100644 index 4b325c8a1ea99..0000000000000 --- a/release-content/migration-guides/rename-clear_children.md +++ /dev/null @@ -1,18 +0,0 @@ ---- -title: Renamed `clear_children` and `clear_related` methods to `detach_*` -pull_requests: [21470, 21537] ---- - -In summary, we renamed `clear_*` and `remove_*` methods to `detach_*`. -This should clarify that these methods do not despawn the child entities or related entities. - -We renamed several related methods on both `EntityCommands` and `EntityWorldMut`: - -- The method `EntityCommands::clear_children` has been renamed to `EntityCommands::detach_all_children`. -- The method `EntityWorldMut::clear_children` has been renamed to `EntityWorldMut::detach_all_children`. -- The method `EntityCommands::remove_children` has been renamed to `EntityCommands::detach_children`. -- The method `EntityWorldMut::remove_children` has been renamed to `EntityWorldMut::detach_children`. -- The method `EntityCommands::remove_child` has been renamed to `EntityCommands::detach_child`. -- The method `EntityWorldMut::remove_child` has been renamed to `EntityWorldMut::detach_child`. -- The method `EntityCommands::clear_related` has been renamed to `EntityCommands::detach_all_related`. -- The method `EntityWorldMut::clear_related` has been renamed to `EntityWorldMut::detach_all_related`. diff --git a/release-content/migration-guides/rename-reflect-documentation-feature.md b/release-content/migration-guides/rename-reflect-documentation-feature.md deleted file mode 100644 index b01f4e1ce8b0c..0000000000000 --- a/release-content/migration-guides/rename-reflect-documentation-feature.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: Renamed `bevy_reflect` feature `documentation` to `reflect_documentation` -pull_requests: [21577] ---- - -The `documentation` feature in `bevy_reflect` has been renamed to `reflect_documentation` to clarify that it allows reflecting documentation of rust code at runtime. diff --git a/release-content/migration-guides/rename_thin_column.md b/release-content/migration-guides/rename_thin_column.md deleted file mode 100644 index f69c01ab2bb41..0000000000000 --- a/release-content/migration-guides/rename_thin_column.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: Replaced `Column` with `ThinColumn` -pull_requests: [21427] ---- - -The low-level `Column` and `ThinColumn` types in `bevy_ecs` have been -merged into a single type, now called `Column` but with the api -of `ThinColumn`. This type does not keep track of its own allocated -length, and only provides unsafe methods. diff --git a/release-content/migration-guides/render_target_component.md b/release-content/migration-guides/render_target_component.md deleted file mode 100644 index 9896cebbb5e4c..0000000000000 --- a/release-content/migration-guides/render_target_component.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: "`RenderTarget` is now a component" -pull_requests: [20917] ---- - -`RenderTarget` has been moved from a field on `Camera` to a separate required component. - -When spawning a camera, specify `RenderTarget` as a component instead of setting `camera.target`: - -```rust -// before -commands.spawn(( - Camera3d::default(), - Camera { - target: RenderTarget::Image(image_handle.into()), - ..default() - }, -)); - -// after -commands.spawn(( - Camera3d::default(), - RenderTarget::Image(image_handle.into()), -)); -``` diff --git a/release-content/migration-guides/same_state_transitions.md b/release-content/migration-guides/same_state_transitions.md deleted file mode 100644 index 5ee41128332ac..0000000000000 --- a/release-content/migration-guides/same_state_transitions.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -title: Same State Transitions -pull_requests: [19363, 21792] ---- - -Setting the next state will now always trigger state transitions like `OnEnter` and `OnExit`, even if the state is already the same. -If you depend on the previous behavior, you can use the `set_if_neq` method instead. - -```rust -// 0.17 -next_state.set(State::Menu); - -// 0.18 -next_state.set_if_neq(State::Menu); -``` diff --git a/release-content/migration-guides/schedule_cleanup.md b/release-content/migration-guides/schedule_cleanup.md deleted file mode 100644 index 0b1281519d677..0000000000000 --- a/release-content/migration-guides/schedule_cleanup.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: "Schedule cleanup" -pull_requests: [21608, 21817] ---- - -- `ScheduleGraph::topsort_graph` has been moved to `DiGraph::toposort`, and now takes a `Vec` parameter for allocation reuse. -- `ReportCycles` was removed: instead, `DiGraphToposortError`s should be immediately - wrapped into hierarchy graph or dependency graph `ScheduleBuildError` variants. -- `ScheduleBuildError::HierarchyLoop` variant was removed, use `ScheduleBuildError::HierarchySort(DiGraphToposortError::Loop())` instead. -- `ScheduleBuildError::HierarchyCycle` variant was removed, use `ScheduleBuildError::HierarchySort(DiGraphToposortError::Cycle())` instead. -- `ScheduleBuildError::DependencyLoop` variant was removed, use `ScheduleBuildError::DependencySort(DiGraphToposortError::Loop())` instead. -- `ScheduleBuildError::DependencyCycle` variant was removed, use `ScheduleBuildError::DependencySort(DiGraphToposortError::Cycle())` instead. -- `ScheduleBuildError::CrossDependency` now wraps a `DagCrossDependencyError` instead of directly holding two `NodeId`s. Fetch them from the wrapped struct instead. -- `ScheduleBuildError::SetsHaveOrderButIntersect` now wraps a `DagOverlappingGroupError` instead of directly holding two `SystemSetKey`s. Fetch them from the wrapped struct instead. -- `ScheduleBuildError::SystemTypeSetAmbiguity` now wraps a `SystemTypeSetAmbiguityError` instead of directly holding a `SystemSetKey`. Fetch them from the wrapped struct instead. -- `ScheduleBuildWarning::HierarchyRedundancy` now wraps a `DagRedundancyError` instead of directly holding a `Vec<(NodeId, NodeId)>`. Fetch them from the wrapped struct instead. -- `ScheduleBuildWarning::Ambiguity` now wraps a `AmbiguousSystemConflictsWarning` instead of directly holding a `Vec`. Fetch them from the wrapped struct instead. -- `ScheduleGraph::conflicting_systems` now returns a `&ConflictingSystems` instead of a slice. Fetch conflicts from the wrapped struct instead. -- `ScheduleGraph::systems_in_set` now returns a `&HashSet` instead of a slice, to reduce redundant allocations. -- `ScheduleGraph::conflicts_to_string` functionality has been replaced with `ConflictingSystems::to_string`. -- `ScheduleBuildPass::build` now takes `&mut Dag` instead of `&mut DiGraph`, to allow reusing previous toposorts. -- `ScheduleBuildPass::collapse_set` now takes `&HashSet` instead of a slice, to reduce redundant allocations. -- `simple_cycles_in_component` has been changed from a free function into a method on `DiGraph`. -- `DiGraph::try_into`/`UnGraph::try_into` was renamed to `DiGraph::try_convert`/`UnGraph::try_convert` to prevent overlap with the `TryInto` trait, and now makes use of `TryInto` instead of `TryFrom` for conversions. diff --git a/release-content/migration-guides/set_index_buffer.md b/release-content/migration-guides/set_index_buffer.md deleted file mode 100644 index f7c76026124b0..0000000000000 --- a/release-content/migration-guides/set_index_buffer.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -title: "`TrackedRenderPass::set_index_buffer` no longer takes buffer offset" -pull_requests: [20468] ---- - -`TrackedRenderPass::set_index_buffer` no longer takes a separate buffer offset argument, which wasn't actually forwarded to wgpu. You have already needed to pass a `BufferSlice` that is sliced to the desired offset/size. - -```rust -// Before: -pass.set_index_buffer(indices.slice(1..), 1, IndexFormat::Uint32); -// After: -pass.set_index_buffer(indices.slice(1..), IndexFormat::Uint32); -``` diff --git a/release-content/migration-guides/text_layout_info_section_rects_is_replaced_by_run_geometry.md b/release-content/migration-guides/text_layout_info_section_rects_is_replaced_by_run_geometry.md deleted file mode 100644 index bbbdfc76cb43c..0000000000000 --- a/release-content/migration-guides/text_layout_info_section_rects_is_replaced_by_run_geometry.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: "`TextLayoutInfo`'s `section_rects` field has been replaced with `run_geometry`" -pull_requests: [] ---- - -`TextLayoutInfo`'s `section_rects` field has been removed. -In its place is a new field `run_geometry` that contains the non-glyph layout geometry for a run of glyphs: the run's span index, bounding rectangle, underline position and thickness, and strikethrough position and thickness. A run in `bevy_text` is a contiguous sequence of glyphs on the same line that share the same text attributes like font, font size, and line height. The coordinates stored in `run_geometry` are unscaled and relative to the top left corner of the text layout. - -Unlike the tuples of `section_rects`, `RunGeometry` does not include an `Entity` id. To find the corresponding text entity, call the `entities` method on the root text entity’s `ComputedTextBlock` component and use the `span_index` to index into the returned slice. diff --git a/release-content/migration-guides/the_non-text_areas_of_text_nodes_are_no_longer_pickable.md b/release-content/migration-guides/the_non-text_areas_of_text_nodes_are_no_longer_pickable.md deleted file mode 100644 index 360d6ee483bc2..0000000000000 --- a/release-content/migration-guides/the_non-text_areas_of_text_nodes_are_no_longer_pickable.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: "The non-text areas of UI `Text` nodes are no longer pickable" -pull_requests: [22047] ---- - -Only the sections of `Text` node's containing text are pickable now, the non-text areas of the node do not register pointer hits. -To replicate Bevy 0.17's picking behavior, use an intermediate parent node to intercept the pointer hits. diff --git a/release-content/migration-guides/thin_slice_ptr_get_unchecked.md b/release-content/migration-guides/thin_slice_ptr_get_unchecked.md deleted file mode 100644 index b9101992783c8..0000000000000 --- a/release-content/migration-guides/thin_slice_ptr_get_unchecked.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: Rename `ThinSlicePtr::get()` to `ThinSlicePtr::get_unchecked()` -pull_requests: [21823] ---- - -`ThinSlicePtr::get()` has been deprecated in favor of the new `ThinSlicePtr::get_unchecked()` -method in order to more clearly signal that bounds checking is not performed. Beyond the name -change, the only difference between these two methods is that `get_unchecked()` takes `&self` while -`get()` takes `self`. In order to migrate, simply rename all usages of `get()` with -`get_unchecked()`: - -```rust -let slice: &[u32] = &[2, 4, 8]; -let thin_slice = ThinSlicePtr::from(slice); - -// 0.17 -let x = unsafe { thin_slice.get(0) }; - -// 0.18 -let x = unsafe { thin_slice.get_unchecked(0) }; -``` diff --git a/release-content/migration-guides/tilemap_chunk_layout_change.md b/release-content/migration-guides/tilemap_chunk_layout_change.md deleted file mode 100644 index 194c49e4f7ef6..0000000000000 --- a/release-content/migration-guides/tilemap_chunk_layout_change.md +++ /dev/null @@ -1,13 +0,0 @@ ---- -title: Tilemap Chunk Layout -pull_requests: [21684] ---- - -`TilemapChunk` and `TilemapChunkTileData`'s default layout has been changed from the origin being in the top left to the origin being in the bottom left. - -The previous layout origin didn't align with Bevy's world coordinate system, so when mapping to and from chunk space (to map a world coordinate to a tile) you would have to account for the chunk y coordinate being inverted. - -With the origin of the chunk being in the bottom left, you can simply mod world coordinates to get chunk coordinates. - -Some other tiling tools have the convention of the origin being at the top left, but it's more important for Bevy's features -to be internally consistent as it allows for better ease of use. diff --git a/release-content/migration-guides/type_path_for_asset_traits.md b/release-content/migration-guides/type_path_for_asset_traits.md deleted file mode 100644 index eda0fd901735f..0000000000000 --- a/release-content/migration-guides/type_path_for_asset_traits.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: Traits `AssetLoader`, `AssetTransformer`, `AssetSaver`, and `Process` all now require `TypePath` -pull_requests: [21339] ---- - -The `AssetLoader`, `AssetTransformer`, `AssetSaver`, and `Process` traits now include a super trait -of `TypePath`. This means if you previously had a loader like: - -```rust -struct MyFunkyLoader { - add_funk: u32, -} -``` - -You will need to add the following derive: - -```rust -#[derive(TypePath)] -struct MyFunkyLoader { - add_funk: u32, -} -``` - -`TypePath` comes from `bevy_reflect`, so libraries may also need to add a dependency on -`bevy_reflect`. diff --git a/release-content/migration-guides/virtual_geometry.md b/release-content/migration-guides/virtual_geometry.md deleted file mode 100644 index bdc873f66edbe..0000000000000 --- a/release-content/migration-guides/virtual_geometry.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: Virtual Geometry -pull_requests: [21301] ---- - -Virtual geometry's asset format has changed. You must regenerate `MeshletMesh` assets. diff --git a/release-content/migration-guides/winit_user_events_removed.md b/release-content/migration-guides/winit_user_events_removed.md deleted file mode 100644 index 87683935f3a79..0000000000000 --- a/release-content/migration-guides/winit_user_events_removed.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: Winit user events removed -pull_requests: [22088] ---- - -In Bevy 0.17 and earlier, `WinitPlugin` and `EventLoopProxyWrapper` was generic over a `M: Message` type, that could be used to wake up the winit event loop and which was then forwarded to the ECS world. In 0.18 support for this has been removed, and those types are no longer generic. - -If you used the default `WakeUp` type via the event loop proxy, you can still do this by using the new `WinitUserEvent` type: - -```rust -// 0.17 -fn wakeup_system(event_loop_proxy: Res>) -> Result { - event_loop_proxy.send_event(WakeUp)?; - - Ok(()) -} - -// 0.18 -fn wakeup_system(event_loop_proxy: Res) -> Result { - event_loop_proxy.send_event(WinitUserEvent::WakeUp)?; - - Ok(()) -} -``` - -If you were using it to send information into the ECS world from outside Bevy, you will need to create your own channel and system that forwards the messages. diff --git a/release-content/release-notes/atmosphere_occlusion.md b/release-content/release-notes/atmosphere_occlusion.md deleted file mode 100644 index a4ad31b5333ec..0000000000000 --- a/release-content/release-notes/atmosphere_occlusion.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: "Atmosphere Occlusion and PBR Shading" -authors: ["@mate-h"] -pull_requests: [21383] ---- - -The procedural atmosphere now affects how light reaches objects in your scene! Sunlight automatically picks up the right colors as it travels through the atmosphere, appearing orange or red when the sun is closer to the horizon. - -This works seamlessly with volumetric fog and all rendering modes, so your scenes will have more cohesive and realistic lighting right out of the box. - -Check out the updated `atmosphere` example to see it in action! diff --git a/release-content/release-notes/automatic_directional_navigation.md b/release-content/release-notes/automatic_directional_navigation.md deleted file mode 100644 index 250d113177e39..0000000000000 --- a/release-content/release-notes/automatic_directional_navigation.md +++ /dev/null @@ -1,91 +0,0 @@ ---- -title: Automatic Directional Navigation -authors: ["@jbuehler23"] -pull_requests: [21668] ---- - -Bevy now supports **automatic directional navigation graph generation** for UI elements! No more tedious manual wiring of navigation connections for your menus and UI screens. - -## What's New? - -Previously, creating directional navigation for UI required manually defining every connection between focusable elements using `DirectionalNavigationMap`. For dynamic UIs or complex layouts, this was time-consuming and error-prone. - -Now, you can simply add the `AutoDirectionalNavigation` component to your UI entities, and Bevy will automatically compute navigation connections based on spatial positioning. The system intelligently finds the nearest neighbor in each of the 8 compass directions (North, Northeast, East, etc.), considering: - -- **Distance**: Closer elements are preferred -- **Alignment**: Elements that are more directly in line with the navigation direction are favored -- **Overlap**: For cardinal directions (N/S/E/W), the system ensures sufficient perpendicular overlap - -## How to Use It - -Simply add the `AutoDirectionalNavigation` component to your UI entities: - -```rust -commands.spawn(( - Button, - Node { /* ... */ }, - AutoDirectionalNavigation::default(), - // ... other components -)); -``` - -That's it! The `DirectionalNavigationPlugin` includes a system that automatically maintains the navigation graph as your UI changes. - -### Configuration - -You can tune the behavior using the `AutoNavigationConfig` resource: - -```rust -app.insert_resource(AutoNavigationConfig { - // Minimum overlap required (0.0 = any overlap, 1.0 = perfect alignment) - min_alignment_factor: 0.0, - // Optional maximum distance for connections - max_search_distance: Some(500.0), - // Whether to strongly prefer well-aligned nodes - prefer_aligned: true, -}); -``` - -### Manual Override - -Automatic navigation respects manually-defined edges. If you want to override specific connections, you can still use `DirectionalNavigationMap::add_edge()` or `add_symmetrical_edge()`, and those connections will take precedence over the auto-generated ones. -You may also call `auto_generate_navigation_edges()` directly, if you have multiple UI layers (though may not be widely used) - -## Why This Matters - -This feature dramatically simplifies UI navigation setup: - -- **Less boilerplate**: No need to manually wire up dozens or hundreds of navigation connections -- **Works with dynamic UIs**: Automatically adapts when UI elements are added, removed, or repositioned -- **Flexible**: Mix automatic and manual navigation as needed -- **Configurable**: Tune the algorithm to match your UI's needs - -Whether you're building menus, inventory screens, or any other gamepad/keyboard-navigable UI, automatic directional navigation makes it much easier to create intuitive, responsive navigation experiences. - -## Migration Guide - -This is a non-breaking change. Existing manual navigation setups continue to work as before. - -If you want to convert existing manual navigation to automatic: - -**Before:** - -```rust -// Manually define all edges -directional_nav_map.add_looping_edges(&row_entities, CompassOctant::East); -directional_nav_map.add_edges(&column_entities, CompassOctant::South); -// ... repeat for all rows and columns -``` - -**After:** - -```rust -// Just add the component to your UI entities -commands.spawn(( - Button, - Node { /* ... */ }, - AutoDirectionalNavigation::default(), -)); -``` - -Note: The automatic navigation system requires entities to have position and size information (`ComputedNode` and `UiGlobalTransform` for `bevy_ui` entities). diff --git a/release-content/release-notes/camera_controllers.md b/release-content/release-notes/camera_controllers.md deleted file mode 100644 index 87d544b39c965..0000000000000 --- a/release-content/release-notes/camera_controllers.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: First-party camera controllers -authors: ["@alice-i-cecile", "@syszery"] -pull_requests: [20215, 21450, 21520] ---- - -To understand a scene, you must look at it through the lens of a camera: explore it, and interact with it. -Because this is such a fundamental operation, game devs have developed a rich collection of tools -called "camera controllers" for manipulating them. - -Getting camera controllers feeling *right* is both tricky and essential: they have a serious -impact on both the feeling of your game and the usability of your software. - -Historically, Bevy has left this entirely up to individual game developers: -camera controllers require deep customization and endless twiddling. -However, Bevy as a game engine needs its *own* camera controllers: -allowing users to quickly and easily explore scenes during development (rather than gameplay). - -To that end, we've created `bevy_camera_controller`: giving us a place to store, share and refine the camera controllers -that we need for easy development, and yes, an eventual Editor. -We're kicking it off with a couple of camera controllers, detailed below. - -## `FreeCamera` - -The first camera controller that we've introduced is a "free camera", designed for quickly moving around a scene, -completely ignoring both physics and geometry. -You may have heard of a "fly camera" controller before, which is a specialization of a "free camera" controller -designed for fast and fluid movement for covering large amounts of terrain. - -To add a free camera controller to your project (typically under a `dev_mode` feature flag), -add the `FreeCameraPlugin` and the `FreeCamera` component to your camera entity. - -To configure the settings (speed, behavior, keybindings) or enable / disable the controller modify the `FreeCamera` component. -We've done our best to select good defaults, but the details of your scene (especially the scale!) will make a big -difference to what feels right. - -## `PanCamera` - -The `PanCamera` controller is a simple and effective tool designed for 2D games or any project where you need -to pan the camera and zoom in/out with ease. It allows you to move the camera using the WASD keys and zoom -in and out with the mouse wheel or +/- keys. - -By adding the `PanCameraPlugin` and attaching the `PanCamera` component to your camera entity, you can quickly add -this controller to your project. - -To configure the camera's zoom levels, speed, or keybindings, simply modify the `PanCamera` component. The default -settings should work well for most use cases, but you can adjust them based on your specific needs, especially -for large-scale or high-resolution 2D scenes. - -## Using `bevy_camera_controller` in your own projects - -The provided camera controllers are designed to be functional, pleasant debug and dev tools: -add the correct plugin and camera component and you're good to go! - -They can also be useful for prototyping, giving you a quick-and-dirty camera controller -as you get your game off the ground. - -However, they are deliberately *not* architected to give you the level of extensibility and customization -needed to make a production-grade camera controller for games. -Customizatibility comes with a real cost in terms of user experience and maintainability, -and because each project only ever needs one or two distinct camera controllers, exposing more knobs and levers is often a questionable design. -Instead, consider vendoring (read: copy-pasting the source code) the camera controller you want to extend -into your project and rewriting the quite-approachable logic to meet your needs, -or looking for [ecosystem camera crates](https://bevy.org/assets/#camera) that correspond to the genre you're building in. diff --git a/release-content/release-notes/cargo_feature_collections.md b/release-content/release-notes/cargo_feature_collections.md deleted file mode 100644 index 9fdbfd7e04754..0000000000000 --- a/release-content/release-notes/cargo_feature_collections.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: Cargo Feature Collections -authors: ["@cart"] -pull_requests: [21472] ---- - -Historically, Bevy developers have lived one of two lifestyles: - -1. Use all of Bevy's default features, potentially compiling many unwanted or unneeded features. -2. Disable Bevy's default features and manually define the complete list of features. - -Living in the world of (2) was an exercise in frustration, as the list of bevy features is _massive_ and the features required to accomplish a given task changes regularly across releases. This was an _expert level_ task that required intimate knowledge of engine internals to get right. - -**Bevy 0.18** introduces high-level "cargo feature collections" to the `bevy` crate: `2d`, `3d`, and `ui`. This enables developers to easily select the kind of app they want to build, and only compile the pieces of Bevy needed for that app. - -This means scenarios like using Bevy as a UI framework, without pulling in the rest of the engine, is now as easy as: - -```toml -bevy = { version = "0.18", default-features = false, features = ["ui"] } -``` - -We've also added mid-level feature collections like `2d_api`, which is Bevy's 2D API _without the default Bevy renderer_. This makes it much easier to swap out the default Bevy renderer for a custom one. - -For example, the `2d` profile looks like this: - -```toml -2d = [ - "default_app", - "default_platform", - "2d_api", - "2d_bevy_render", - "ui", - "scene", - "audio", - "picking", -] -``` - -Someone building a custom 2D renderer now just needs to remove `2d_bevy_render` and provide their own. - -Developers can now define their own high-level cargo feature profiles from these mid-level pieces, making it _much_ easier to define the subset of Bevy you want to build into your app. diff --git a/release-content/release-notes/computed_node_helper_functions.md b/release-content/release-notes/computed_node_helper_functions.md deleted file mode 100644 index b9a08ab8440ca..0000000000000 --- a/release-content/release-notes/computed_node_helper_functions.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: "`ComputedNode` helper functions" -authors: ["@ickshonpe"] -pull_requests: [21903] ---- - -Helper functions `border_box`, `padding_box`, and `content_box` that return a node’s object-centered border, padding, and content boxes have been added to `ComputedNode`. diff --git a/release-content/release-notes/easy_marketing_material.md b/release-content/release-notes/easy_marketing_material.md deleted file mode 100644 index 943a9b26a61e7..0000000000000 --- a/release-content/release-notes/easy_marketing_material.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: Helpers to Produce Marketing Material -authors: ["@mockersf"] -pull_requests: [21235, 21237] ---- - -Bevy can take a screenshot of what's rendered since 0.11. This is now easier to setup to help you create marketing material, so that you can take screenshot with consistent formatting with the new `EasyScreenshotPlugin`. With its default settings, once you add this plugin to your application, a PNG screenshot will be taken when you press the `PrintScreen` key. You can change the trigger key, or the screenshot format between PNG, JPEG or BMP. - -It is now possible to record a movie from Bevy, with the new `EasyScreenRecordPlugin`. This plugins add a toggle key, space bar by default, that will toggle screen recording. Recording can also be started and stopped programmatically with the `RecordScreen` messages. - -Screen recording is not working for now on Windows. diff --git a/release-content/release-notes/fallible_interpolation.md b/release-content/release-notes/fallible_interpolation.md deleted file mode 100644 index 4d7674c5ec54b..0000000000000 --- a/release-content/release-notes/fallible_interpolation.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: Fallible Interpolation -authors: ["@viridia"] -pull_requests: [21633] ---- - -## Fallible Interpolation - -The `StableInterpolate` trait is great, but sadly there's one important type that it doesn't work -with: The `Val` type from `bevy_ui`. The reason is that `Val` is an enum, representing different -length units such as pixels and percentages, and it's not generally possible or even meaningful to -try and interpolate between different units. - -However, the use cases for wanting to animate `Val` don't require mixing units: often we just want -to slide or stretch the length of a widget such as a toggle switch. We can do this so long as we -check at runtime that both interpolation control points are in the same units. - -The new `TryStableInterpolate` trait introduces the idea of interpolation that can fail, by returning -a `Result`. Note that "failure" in this case is not necessarily bad: it just means that the -animation player will need to modify the parameter in some other way, such as "snapping" or -"jumping" to the new keyframe without smoothly interpolating. This lets us create complex animations -that incorporate both kinds of parameters: ones that interpolate, and ones that don't. - -There's a blanket implementation of `TryStableInterpolate` for all types that impl -`StableInterpolate`, and these can never fail. There are additional impls for `Color` and `Val` -which can fail if the control points are not in the same units / color space. diff --git a/release-content/release-notes/font_weights.md b/release-content/release-notes/font_weights.md deleted file mode 100644 index 670ab18433b81..0000000000000 --- a/release-content/release-notes/font_weights.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: "Font weight support" -authors: ["@ickshonpe"] -pull_requests: [22038] ---- - -Adds support for font weights. - -`TextFont` now has a `weight: FontWeight` field. `FontWeight` newtypes a `u16`, values inside the range 1 and 1000 are valid. Values outside the range are clamped. diff --git a/release-content/release-notes/fullscreen_material.md b/release-content/release-notes/fullscreen_material.md deleted file mode 100644 index 59f0307107982..0000000000000 --- a/release-content/release-notes/fullscreen_material.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: Fullscreen Material -authors: ["@IceSentry"] -pull_requests: [20414] ---- - -Users often want to run a fullscreen shader but currently the only to do this is to copy the custom_post_processing example which is very verbose and contains a lot of low level details. We introduced a new `FullscreenMaterial` trait and `FullscreenMaterialPlugin` that let you easily run a fullscreen shader and specify in which order it will run relative to other render passes in the engine. diff --git a/release-content/release-notes/generalized_atmosphere.md b/release-content/release-notes/generalized_atmosphere.md deleted file mode 100644 index fade4c07c1719..0000000000000 --- a/release-content/release-notes/generalized_atmosphere.md +++ /dev/null @@ -1,74 +0,0 @@ ---- -title: "Generalized Atmospheric Scattering Media" -authors: ["@ecoskey"] -pull_requests: [20838] ---- - -Until now, Bevy's atmospheric scattering system has been fast and beautiful, but -not very customizable. There's only a limited number of ways to customize the -existing parameters, which constrain the system to mostly earth-like scenes. - -Bevy 0.18 introduces a new `ScatteringMedium` asset for designing atmospheric -scattering media of all kinds: clear desert skies, foggy coastlines, and -even atmospheres of other planets! We've used Bevy's asset system to the -fullest--alongside some custom optimizations--to make sure rendering stays -fast even for complicated scattering media. - -```rust -fn setup_camera( - mut commands: Commands, - mut media: ResMut>, -) { - // Also feel free to use `ScatteringMedium::earthlike()`! - let medium = media.add(ScatteringMedium::new( - 256, - 256, - [ - ScatteringTerm { - absorption: Vec3::ZERO, - scattering: Vec3::new(5.802e-6, 13.558e-6, 33.100e-6), - falloff: Falloff::Exponential { strength: 12.5 }, - phase: PhaseFunction::Rayleigh, - }, - ScatteringTerm { - absorption: Vec3::splat(3.996e-6), - scattering: Vec3::splat(0.444e-6), - falloff: Falloff::Exponential { strength: 83.5 }, - phase: PhaseFunction::Mie { asymmetry: 0.8 }, - }, - ScatteringTerm { - absorption: Vec3::new(0.650e-6, 1.881e-6, 0.085e-6), - scattering: Vec3::ZERO, - falloff: Falloff::Tent { - center: 0.75, - width: 0.3, - }, - phase: PhaseFunction::Isotropic, - }, - ], - )); - - commands.spawn(( - Camera3d, - Atmosphere::earthlike(medium) - )); -} - -// We've provided a nice `EarthlikeAtmosphere` resource -// for the most common case :) -fn setup_camera_simple( - mut commands: Commands, - earthlike_atmosphere: Res -) { - commands.spawn(( - Camera3d, - earthlike_atmosphere.get(), - )); -} -``` - -(TODO: engine example of martian/extraterrestrial sunrise) - -Alongside this change we've also added a bunch of documentation, and links to -learn more about the technical terms used. It's definitely a complex feature -under the hood, so we're hoping to make the learning curve a little less steep :) diff --git a/release-content/release-notes/get_components_mut.md b/release-content/release-notes/get_components_mut.md deleted file mode 100644 index c7d72563d9c26..0000000000000 --- a/release-content/release-notes/get_components_mut.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: get_components_mut -authors: ["@hymm"] -pull_requests: [21780] ---- - -Methods `EntityMut::get_components_mut` and `EntityWorldMut::get_components_mut` are now -added, providing a safe API for retrieving mutable references to multiple components via -these entity access APIs. - -Previously, only the unsafe variants of these methods, called -`get_components_mut_unchecked`, were present. They are not safe because they allow -retrieving `(&mut T, &mut T)` - two mutable references to a single component - which -breaks Rust's pointer aliasing rules. - -The new methods work around this via performing a quadratic time complexity check between -all specified components for conflicts, returning `QueryAccessError::Conflict` if such -occurs. This potentially has a runtime performance cost, so it might be favorable to still -use `get_components_mut_unchecked` if you can guarantee that no aliasing would occur. diff --git a/release-content/release-notes/gltf_extension_handling.md b/release-content/release-notes/gltf_extension_handling.md deleted file mode 100644 index f2753aaf16c30..0000000000000 --- a/release-content/release-notes/gltf_extension_handling.md +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: "Userspace glTF Extension Handling" -authors: ["@christopherbiscardi"] -pull_requests: [22106] ---- - -Prior to 0.18, the code to handle extensions like `KHR_lights_punctual` was hardcoded into Bevy's glTF loader. -In 0.18, users may implement the `GltfExtensionHandler` trait to do stateful processing of glTF data as it loads. -Processing _extension_ data is only half the story here because to process extension data you also have to be able to process the non-extension data like meshes, materials, animations, and more. - -Extension handlers can be written for wide variety of use cases, including: - -- Insert Bevy Component data on entities -- Convert all `Mesh3d` components to `Mesh2d` -- Build `AnimationGraph`s and insert them on animation roots -- Replace `StandardMaterial` with custom materials -- Insert lightmaps - -## Extras vs Extensions - -glTF has two mechanisms for extending glTF files with additional user data: Extras and Extensions. - -**Extras** are meant to be arbitrary application-specific data, often authored by users directly in tools like Blender's custom properties. -Extras are historically well supported by Bevy; If you add a custom property in Blender that data will end up in one of the `GltfExtras` components on the relevant `Entity`. - -**Extensions** are meant for data that can be shared across applications. -They are more flexible, allowing for new data in more places inside a glTF file, and more powerful as a result. -Extensions can add new object types, such as `lights` from the `KHR_lights_punctual` extension, as well as arbitrary buffers, data that is at the root of the glTF file, and more. - -More examples of extensions can be found in the [KhronosGroup git repo](https://github.com/KhronosGroup/glTF/blob/7bbd90978cad06389eee3a36882c5ef2f2039faf/extensions/README.md) - -## Case Study - -Extensions typically require an application that is _producing_ the data as well as _consuming_ the data. - -For example: [Skein](https://github.com/rust-adventure/skein) defines a glTF extension that allows adding Bevy Components to glTF objects. -This is most commonly produced by Blender and consumed by Skein's `GltfExtensionHandler` in Bevy. -These components are then inserted on entities in a scene at the same time built-in components like `Transform` and `Mesh3d` are. - -Using glTF Extensions for this data means that other level editors like Trenchbroom can also write the same format to glTF files. -Any third party software that writes component data into a glTF file can use Skein's `GltfExtensionHandler`, resulting in components being "ready-to-go" when spawning `Scene`s. - -## New Examples - -Two new examples show off use cases: - -- The first builds an `AnimationGraph` and inserts it onto the animation root in a Scene, which means it is now accessible to play animations using the `AnimationPlayer` on the same `Entity` later when that Scene is spawned. -- The second uses a `GltfExtensionHandler` to switch the 3d Mesh and Material components for their 2d counterparts. This is useful if you're using software like Blender to build 2d worlds. - -```shell -cargo run --example gltf_extension_animation_graph -cargo run --example gltf_extension_mesh_2d -``` diff --git a/release-content/release-notes/ignore-scroll.md b/release-content/release-notes/ignore-scroll.md deleted file mode 100644 index 47a48a3842165..0000000000000 --- a/release-content/release-notes/ignore-scroll.md +++ /dev/null @@ -1,9 +0,0 @@ ---- -title: Support for Ui nodes that ignore parent scroll position. -authors: ["@PPakalns"] -pull_requests: [21648] ---- - -Adds the `IgnoreScroll` component, which controls whether a UI element ignores its parent’s `ScrollPosition` along specific axes. - -This can be used to achieve basic sticky row and column headers in scrollable UI layouts. See `scroll` example. diff --git a/release-content/release-notes/more_standard_widgets.md b/release-content/release-notes/more_standard_widgets.md deleted file mode 100644 index 305e98ea8f9e5..0000000000000 --- a/release-content/release-notes/more_standard_widgets.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: More Standard Widgets -authors: ["@viridia"] -pull_requests: [21636, 21743] ---- - -## More Standard Widgets - -We are continuing to flesh out the collection of standard widgets first introduced in -Bevy 0.17. - -### Popover - -The `Popover` component can be placed on an absolutely-positioned UI node to provide -automatic popup positioning. This is inspired by the popular `floating-ui` npm package. - -Popovers will be placed relative to an anchor element, and positioned so that they don't get -cut off by the window edge. You can specify a list of preferred "placements": top, bottom, -left or right, along with alignment options for each. If the popup is so large that it's -impossible to position it without it getting cut off, it will choose the placement that results -in the most visibility (as determined by the area cut off). (A future version might also -have an option to constrain the popup to be no larger than the window size, but this will be -more useful once we have better support for scrolling.) - -This automatic positioning is dynamic, which means that if the anchor element moves around, is -inside a scrolling container, or the window is resized, the popover may "flip" sides in order to -remain fully visible. - -Popovers can be used for dropdown menus, but they can also be used for tooltips. - -### Menu - -The `Menu` component uses `Popover` to provide a dropdown menu widget. This adds events for opening -and closing the menu, along with keyboard navigation and activation using the focus system. - -### Color Plane - -The `Color Plane` widget is a two-dimensional color picker that allows selecting two different -channels within a color space, one along the horizontal axis and one along the vertical. It can be -configured to display a variety of different color spaces: hue vs. lightness, hue vs. saturation, -red vs. blue, and so on. diff --git a/release-content/release-notes/opentype_font_features.md b/release-content/release-notes/opentype_font_features.md deleted file mode 100644 index a953526204a7d..0000000000000 --- a/release-content/release-notes/opentype_font_features.md +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: OpenType Font Features -authors: ["@hansler"] -pull_requests: [19020] ---- - -OpenType font features allow fine-grained control over how text is displayed, including [ligatures](https://en.wikipedia.org/wiki/Ligature_(writing)), [small caps](https://en.wikipedia.org/wiki/Small_caps), and [many more](https://learn.microsoft.com/en-us/typography/opentype/spec/featurelist). - -These features can now be used in Bevy, allowing users to add typographic polish (like discretionary ligatures and oldstyle numerals) to their UI. It also allows complex scripts like Arabic or Devanagari to render more correctly with their intended ligatures. - -Example usage: - -```rust -commands.spawn(( - TextSpan::new("Ligatures: ff, fi, fl, ffi, ffl"), - TextFont { - font: opentype_font_handle, - font_features: FontFeatures::builder() - .enable(FontFeatureTag::STANDARD_LIGATURES) - .set(FontFeatureTag::WIDTH, 300) - .build(), - ..default() - }, -)); -``` - -FontFeatures can also be constructed from a list: - -```rust -TextFont { - font: opentype_font_handle, - font_features: [ - FontFeatureTag::STANDARD_LIGATURES, - FontFeatureTag::STYLISTIC_ALTERNATES, - FontFeatureTag::SLASHED_ZERO - ].into(), - ..default() -} -``` - -Note that OpenType font features are only available for `.otf` fonts that support them, and different fonts may support different subsets of OpenType features. diff --git a/release-content/release-notes/optional_asset_reader_seek.md b/release-content/release-notes/optional_asset_reader_seek.md deleted file mode 100644 index cd92446174289..0000000000000 --- a/release-content/release-notes/optional_asset_reader_seek.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: The `AssetReader` trait can now (optionally) support seeking any direction. -authors: ["@andriyDev"] -pull_requests: [] ---- - -In Bevy 0.15, we replaced the `AsyncSeek` super trait on `Reader` with `AsyncSeekForward`. This -allowed our `Reader` trait to apply to more cases (e.g., it could allow cases like an HTTP request, -which may not support seeking backwards). However, it also meant that we could no longer use seeking -fully where it was available. - -To resolve this issue, we now allow `AssetLoader`s to provide a `ReaderRequiredFeatures` to the -`AssetReader`. The `AssetReader` can then choose how to handle those required features. For example, -it can return an error to indicate that the feature is not supported, or it can choose to use a -different `Reader` implementation to fallback in order to continue to support the feature. - -This allowed us to bring back the "requirement" the `Reader: AsyncSeek`, but with a more relaxed -policy: the `Reader` may choose to avoid supporting certain features (corresponding to fields in -`ReaderRequiredFeatures`). - -Our general recommendation is that if your `Reader` implementation does not support a feature, make -your `AssetReader` just return an error for that feature. Usually, an `AssetLoader` can implement a -fallback itself (e.g., reading all the data into memory and then loading from that), and loaders can -be selected using `.meta` files (allowing for fine-grained opt-in in these cases). However if there -is some reasonable implementation you can provide (even if not optimal), feel free to provide one! diff --git a/release-content/release-notes/per_text_section_picking.md b/release-content/release-notes/per_text_section_picking.md deleted file mode 100644 index 7ab2e7ac5df2d..0000000000000 --- a/release-content/release-notes/per_text_section_picking.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: "UI per text section picking" -authors: ["@ickshonpe"] -pull_requests: [22047] ---- - -Individual text sections belonging to UI text nodes are now pickable and can be given observers. diff --git a/release-content/release-notes/radio_group_and_button_widget_improvements.md b/release-content/release-notes/radio_group_and_button_widget_improvements.md deleted file mode 100644 index 6fe62ec232932..0000000000000 --- a/release-content/release-notes/radio_group_and_button_widget_improvements.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -title: "`RadioButton`, `RadioGroup` widget minor improvements" -authors: ["@PPakalns"] -pull_requests: [21294] ---- - -`RadioButton` and `RadioGroup` usage remains fully backward compatible. - -Improvements: - -- Event propagation from user interactions will now be canceled even if - widgets are disabled. Previously, some relevant event propagation - was not properly canceled. -- `RadioButton` now emits a `ValueChange` entity event when checked, - even when checked via a `RadioGroup`. Consistent with other `Checkable` widgets. - As a `RadioButton` cannot be unchecked through direct user interaction with this widget, - a `ValueChange` event with value `false` can not be triggered for `RadioButton`. -- If a `RadioButton` is focusable, a value change event can be triggered - using the **Space** or **Enter** keys when focused. -- `RadioGroup` is now optional and can be replaced with a custom implementation. diff --git a/release-content/release-notes/remove_systems.md b/release-content/release-notes/remove_systems.md deleted file mode 100644 index ac1c81a58b09a..0000000000000 --- a/release-content/release-notes/remove_systems.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Remove Systems from Schedules -authors: ["@hymm"] -pull_requests: [20298] ---- - -A long requested feature has come to Bevy! You can now remove systems from a schedule. -The previous recommended way of preventing a scheduled system from running was to use `RunCondition`'s. -You will still use this for most situations as removing a system will cause the schedule to be rebuilt. -This process can be slow since the schedule checking logic is complex. But in situations where this is -not a problem, you can now call `remove_systems_in_set`. The advantage of this is that this will remove the -cost of the run condition being checked. - -```rust -app.add_systems((system_a, (system_b, system_c).in_set(MySet))); - -// remove a system -schedule.remove_systems_in_set(my_system, ScheduleCleanupPolicy::RemoveSystemsOnly); - -// remove systems in a set -app.remove_systems_in_set(MySet, ScheduleCleanupPolicy::RemoveSetAndSystems); -``` diff --git a/release-content/release-notes/render-assets-diagnostics.md b/release-content/release-notes/render-assets-diagnostics.md deleted file mode 100644 index e01aeeef1c84c..0000000000000 --- a/release-content/release-notes/render-assets-diagnostics.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: Render Assets diagnostics -authors: ["@hukasu"] -pull_requests: [19311] ---- - -## Goals - -Create diagnostics plugins `MeshAllocatorDiagnosticPlugin`, `MaterialAllocatorDiagnosticPlugin`, -`RenderAssetDiagnosticPlugin`, and `ErasedRenderAssetDiagnosticPlugin`, that collect measurements -related to `MeshAllocator`s, `MaterialBindGroupAllocator`, `RenderAssets`, and `ErasedRenderAssets` -respectively. - -`MeshAllocatorDiagnosticPlugin` and `MaterialDiagnosticPlugin` measure the number of slabs, the total size of memory -allocated by the slabs, and the number of objects allocated in the slabs. Only bindless materials use slabs for their -allocations, non-bindless materials return 0 for all of them. - -`RenderAssetDiagnosticsPlugin` and `ErasedAssetDiagnosticsPlugin` measure the number of -assets in `RenderAssets` and `ErasedRenderAssets`. `ErasedAssetDiagnosticsPlugin` -will report the same number of assets for all `ERA` that share the same `ERA::ErasedAsset`. - -## Showcase - -```rust -app.add_plugins(DefaultPlugins) - .add_plugins(( - MeshAllocatorDiagnosticPlugin, - MaterialAllocatorDiagnosticPlugin::::default(), - RenderAssetDiagnosticPlugin::::new(" render meshes"), - RenderAssetDiagnosticPlugin::::new(" gpu images"), - // ImageMaterial is the name of the manual material used on the `manual_material` example - ErasedRenderAssetDiagnosticPlugin::::new(" image materials"), - )); -``` - -If you also have `LogDiagnosticsPlugin`, the output looks something like this: - -```ignore -INFO bevy_diagnostic: mesh_allocator_allocations : 4.000000 meshes (avg 4.000000 meshes) -INFO bevy_diagnostic: mesh_allocator_slabs : 4.000000 slabs (avg 4.000000 slabs) -INFO bevy_diagnostic: mesh_allocator_slabs_size : 4194360.000000 bytes (avg 4194360.000000 bytes) -INFO bevy_diagnostic: material_allocator_allocations/bevy_pbr::pbr_material::StandardMaterial: 14.000000 materials (avg 14.000000 materials) -INFO bevy_diagnostic: material_allocator_slabs/bevy_pbr::pbr_material::StandardMaterial : 1.000000 slabs (avg 1.000000 slabs) -INFO bevy_diagnostic: material_allocator_slabs_size/bevy_pbr::pbr_material::StandardMaterial : 576.000000 bytes (avg 576.000000 bytes) -INFO bevy_diagnostic: render_asset/bevy_render::mesh::RenderMesh : 5.000000 render meshes (avg 5.000000 render meshes) -INFO bevy_diagnostic: render_asset/bevy_render::texture::gpu_image::GpuImage : 10.000000 gpu images (avg 10.000000 gpu images) -INFO bevy_diagnostic: erased_render_asset/manual_material::ImageMaterial : 2.000000 image materials (avg 2.000000 image materials) -``` diff --git a/release-content/release-notes/ring_primitive.md b/release-content/release-notes/ring_primitive.md deleted file mode 100644 index 3912f32339fdf..0000000000000 --- a/release-content/release-notes/ring_primitive.md +++ /dev/null @@ -1,110 +0,0 @@ ---- -title: Ring primitives -authors: ["@tigregalis", "@lynn-lumen"] -pull_requests: [21446] ---- - -## Ring / hollow shapes - -![Rings of 2d primitives (bottom row)](https://github.com/user-attachments/assets/8fac6c82-3da0-488e-ab38-80816b2129c0) - -![Extrusions of rings of extrudable primitives (front row)](https://github.com/user-attachments/assets/70c4dee0-4f82-4723-b95c-9d02ddb95363) - -There is a new generic primitive `Ring`, which takes as input any `Primitive2d`, with two instances of that primitive shape: the outer and the inner (or hollow). -A `Ring` here is what an `Annulus` is to a `Circle`. -This allows us to have (or at least approximate - more on that later) "hollow" shapes or "outlines". - -```rs -// construct the `Ring` from an outer and inner shape - -let capsule_ring = Ring::new(Capsule2d::new(50.0, 100.0), Capsule2d::new(45.0, 100.0)); -let hexagon_ring = Ring::new(RegularPolygon::new(50.0, 6), RegularPolygon::new(45.0, 6)); // note vertex count must match - -// or, from a shape and a thickness for any types that implement `Inset` - -let capsule_ring = Ring::from_primitive_and_thickness(Capsule2d::new(50.0, 100.0), 5.0); -let hexagon_ring = Ring::from_primitive_and_thickness(RegularPolygon::new(50.0, 6), 5.0); - -// or, from the `ToRing` trait for any types that implement `Inset` - -let capsule_ring = Capsule2d::new(50.0, 100.0).to_ring(5.0); -let hexagon_ring = RegularPolygon::new(50.0, 6).to_ring(5.0); - -``` - -## How it works - -The mesh for a `RingMeshBuilder` is constructed by concatenating the vertices of the outer and inner meshes, then walking the perimeter to join corresponding vertices like so: - -![Vertices around a pentagon ring](https://github.com/user-attachments/assets/2cecb458-3b59-44fb-858b-1beffecd1e57) - -```text -# outer vertices, then inner vertices -positions = [ - 0 1 2 3 4 - 0' 1' 2' 3' 4' -] -# pairs of triangles -indices = [ - 0 1 0' 0' 1 1' - 1 2 1' 1' 2 2' - 2 3 2' 2' 3 3' - 3 4 3' 3' 4 4' - 4 0 4' 4' 0 0' -] -``` - -Examples of generated meshes: - -![Mesh for a pentagon ring](https://github.com/user-attachments/assets/cb9881e5-4518-4743-b8de-5816b632f36f) - -![Mesh for a heart ring](https://github.com/user-attachments/assets/348bbd91-9f4e-4040-bfa5-d508a4308c10) - -## Extrusions - -A `Ring` for a type that is `Extrudable` is also `Extrudable`. - -```rs -let extrusion = Extrusion::new(RegularPolygon::new(1.0, 5).to_ring(0.2)); -``` - -![Mesh for an extruded pentagon ring](https://github.com/user-attachments/assets/7d2022c9-b8cf-4b4b-bb09-cbe4fe49fb89) - -![Mesh for an extruded heart ring](https://github.com/user-attachments/assets/dbaf894e-6f7f-4b79-af3e-69516da85898) - -## Inset shapes - -Some shapes can be "inset", that is, we can produce a smaller shape where the lines/curves/vertices are equidistant from the outer shape's when they share the same origin. -This is represented by the `Inset` trait. -Inset shapes give us nice "outlines" when combined with `Ring`, so for these shapes we provide a `ToRing` method that takes an inset distance. - -The implementation of `Inset` can be unintuitive - have a look at the source at [crates/bevy_math/src/primitives/inset.rs][Source]. -For example, the inset `CircularSegment` in our implementation is actually constructed by shortening the radius _and_ the angle. - -Some shapes can't be represented by an inset: `Ellipse` for example doesn't implement `Inset`, because concentric ellipses do not have parallel lines. - -![Concentric ellipses](https://github.com/user-attachments/assets/3f419f8f-4d7a-4bfb-a231-fba9464e0f93) - -If the ellipse is not a circle, the inset shape is not actually an ellipse (although it may look like one) but can also be a lens-like shape. -The following image shows an ellipse in white and all points at a constant distance from that ellipse in blue. -Neither of the blue shapes is an ellipse. - -![An ellipse in white and its parallel lines in blue](https://github.com/user-attachments/assets/8c7520d1-9911-4c9c-8e6f-2688e160f510) - -For the sake of flexibility, however, we don't require `Ring` shapes to be `Inset`. - -## Limitations - -It's assumed that the inner and outer meshes have the same number of vertices. - -It's currently assumed the vertex positions are well ordered (i.e. -walking around the perimeter, without zig-zagging), otherwise it will result in incorrect geometries. - -The `outer_shape` must contain the `inner_shape` for the generated meshes to be accurate. -If there are vertices in the `inner_shape` that escape the `outer_shape` (for example, if the `inner_shape` is in fact larger), it may result in incorrect geometries. - -Because the origin of the generated mesh matters when constructing a `Ring`, some "outline" shapes can't currently be easily represented. - - - -[Source]: https://github.com/bevyengine/bevy/blob/6e348948cae9523d0d7f13f0ed598d16790ff4ae/crates/bevy_math/src/primitives/inset.rs diff --git a/release-content/release-notes/short_type_path_asset_processors.md b/release-content/release-notes/short_type_path_asset_processors.md deleted file mode 100644 index ab74ae7febb98..0000000000000 --- a/release-content/release-notes/short_type_path_asset_processors.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: Short-type-path asset processors -authors: ["@andriyDev"] -pull_requests: [21339] ---- - -Asset processors allow manipulating assets at "publish-time" to convert them into a more optimal -form when loading the data at runtime. This can either be done using a default processor, which -processes all assets with a particular file extension, or by specifying the processor in the asset's -meta file. - -In previous versions of Bevy, the processor had to be **fully** specified in the asset's meta file. -For example: - -```ron -( - meta_format_version: "1.0", - asset: Process( - processor: "bevy_asset::processor::process::LoadTransformAndSave", - settings: ( - loader_settings: (), - transformer_settings: (), - saver_settings: (), - ), - ), -) -``` - -As you can see, processor types can be very verbose! In order to make these meta files easier to -manipulate, we now also support using the "short type path" of the asset. This would look like: - -```ron -( - meta_format_version: "1.0", - asset: Process( - processor: "LoadTransformAndSave", - settings: ( - loader_settings: (), - transformer_settings: (), - saver_settings: (), - ), - ), -) -``` diff --git a/release-content/release-notes/solari.md b/release-content/release-notes/solari.md deleted file mode 100644 index 1586b9ebe467f..0000000000000 --- a/release-content/release-notes/solari.md +++ /dev/null @@ -1,19 +0,0 @@ ---- -title: Solari Improvements -authors: ["@JMS55", "@SparkyPotato"] -pull_requests: [21391, 21355, 21810] ---- - -(Too many PRs to list in full - this is just a small selection!) - -Solari - Bevy's forward-looking realtime raytraced renderer - has seen many improvements in this release. - -Notably: - -- Support for specular materials and reflections -- Faster-reacting lighting -- A large amount of quality/accuracy improvements -- Physically-based soft shadows for directional lights -- Improved performance on larger scenes - -For the full list of details, check out the author's [full blog post](https://jms55.github.io/posts/2025-12-27-solari-bevy-0-18). diff --git a/release-content/release-notes/text_strikethrough_and_underline.md b/release-content/release-notes/text_strikethrough_and_underline.md deleted file mode 100644 index 0d82ee2a56603..0000000000000 --- a/release-content/release-notes/text_strikethrough_and_underline.md +++ /dev/null @@ -1,7 +0,0 @@ ---- -title: Text strikethrough and underline support -authors: ["@ickshonpe"] -pull_requests: [21555, 21559] ---- - -`bevy_text` now supports strikethrough and underline. To display text with strikethrough or underline, just add the `Strikethrough` or `Underline` components to any `Text`, `Text2d`, or `TextSpan` entity. You can set colors for strikethrough and underline using the `StrikethroughColor` and `UnderlineColor` components, respectively.