# Objective NOTE: This depends on #7267 and should not be merged until #7267 is merged. If you are reviewing this before that is merged, I highly recommend viewing the Base Sets commit instead of trying to find my changes amongst those from #7267. "Default sets" as described by the [Stageless RFC](https://github.com/bevyengine/rfcs/pull/45) have some [unfortunate consequences](https://github.com/bevyengine/bevy/discussions/7365). ## Solution This adds "base sets" as a variant of `SystemSet`: A set is a "base set" if `SystemSet::is_base` returns `true`. Typically this will be opted-in to using the `SystemSet` derive: ```rust #[derive(SystemSet, Clone, Hash, Debug, PartialEq, Eq)] #[system_set(base)] enum MyBaseSet { A, B, } ``` **Base sets are exclusive**: a system can belong to at most one "base set". Adding a system to more than one will result in an error. When possible we fail immediately during system-config-time with a nice file + line number. For the more nested graph-ey cases, this will fail at the final schedule build. **Base sets cannot belong to other sets**: this is where the word "base" comes from Systems and Sets can only be added to base sets using `in_base_set`. Calling `in_set` with a base set will fail. As will calling `in_base_set` with a normal set. ```rust app.add_system(foo.in_base_set(MyBaseSet::A)) // X must be a normal set ... base sets cannot be added to base sets .configure_set(X.in_base_set(MyBaseSet::A)) ``` Base sets can still be configured like normal sets: ```rust app.add_system(MyBaseSet::B.after(MyBaseSet::Ap)) ``` The primary use case for base sets is enabling a "default base set": ```rust schedule.set_default_base_set(CoreSet::Update) // this will belong to CoreSet::Update by default .add_system(foo) // this will override the default base set with PostUpdate .add_system(bar.in_base_set(CoreSet::PostUpdate)) ``` This allows us to build apis that work by default in the standard Bevy style. This is a rough analog to the "default stage" model, but it use the new "stageless sets" model instead, with all of the ordering flexibility (including exclusive systems) that it provides. --- ## Changelog - Added "base sets" and ported CoreSet to use them. ## Migration Guide TODO
		
			
				
	
	
		
			77 lines
		
	
	
		
			2.6 KiB
		
	
	
	
		
			Rust
		
	
	
	
	
	
			
		
		
	
	
			77 lines
		
	
	
		
			2.6 KiB
		
	
	
	
		
			Rust
		
	
	
	
	
	
//! Illustrates parallel queries with `ParallelIterator`.
 | 
						|
 | 
						|
use bevy::ecs::query::BatchingStrategy;
 | 
						|
use bevy::prelude::*;
 | 
						|
use rand::random;
 | 
						|
 | 
						|
#[derive(Component, Deref)]
 | 
						|
struct Velocity(Vec2);
 | 
						|
 | 
						|
fn spawn_system(mut commands: Commands, asset_server: Res<AssetServer>) {
 | 
						|
    commands.spawn(Camera2dBundle::default());
 | 
						|
    let texture = asset_server.load("branding/icon.png");
 | 
						|
    for _ in 0..128 {
 | 
						|
        commands.spawn((
 | 
						|
            SpriteBundle {
 | 
						|
                texture: texture.clone(),
 | 
						|
                transform: Transform::from_scale(Vec3::splat(0.1)),
 | 
						|
                ..default()
 | 
						|
            },
 | 
						|
            Velocity(20.0 * Vec2::new(random::<f32>() - 0.5, random::<f32>() - 0.5)),
 | 
						|
        ));
 | 
						|
    }
 | 
						|
}
 | 
						|
 | 
						|
// Move sprites according to their velocity
 | 
						|
fn move_system(mut sprites: Query<(&mut Transform, &Velocity)>) {
 | 
						|
    // Compute the new location of each sprite in parallel on the
 | 
						|
    // ComputeTaskPool
 | 
						|
    //
 | 
						|
    // This example is only for demonstrative purposes. Using a
 | 
						|
    // ParallelIterator for an inexpensive operation like addition on only 128
 | 
						|
    // elements will not typically be faster than just using a normal Iterator.
 | 
						|
    // See the ParallelIterator documentation for more information on when
 | 
						|
    // to use or not use ParallelIterator over a normal Iterator.
 | 
						|
    sprites
 | 
						|
        .par_iter_mut()
 | 
						|
        .for_each_mut(|(mut transform, velocity)| {
 | 
						|
            transform.translation += velocity.extend(0.0);
 | 
						|
        });
 | 
						|
}
 | 
						|
 | 
						|
// Bounce sprites outside the window
 | 
						|
fn bounce_system(windows: Query<&Window>, mut sprites: Query<(&Transform, &mut Velocity)>) {
 | 
						|
    let window = windows.single();
 | 
						|
    let width = window.width();
 | 
						|
    let height = window.height();
 | 
						|
    let left = width / -2.0;
 | 
						|
    let right = width / 2.0;
 | 
						|
    let bottom = height / -2.0;
 | 
						|
    let top = height / 2.0;
 | 
						|
    // The default batch size can also be overridden.
 | 
						|
    // In this case a batch size of 32 is chosen to limit the overhead of
 | 
						|
    // ParallelIterator, since negating a vector is very inexpensive.
 | 
						|
    sprites
 | 
						|
        .par_iter_mut()
 | 
						|
        .batching_strategy(BatchingStrategy::fixed(32))
 | 
						|
        .for_each_mut(|(transform, mut v)| {
 | 
						|
            if !(left < transform.translation.x
 | 
						|
                && transform.translation.x < right
 | 
						|
                && bottom < transform.translation.y
 | 
						|
                && transform.translation.y < top)
 | 
						|
            {
 | 
						|
                // For simplicity, just reverse the velocity; don't use realistic bounces
 | 
						|
                v.0 = -v.0;
 | 
						|
            }
 | 
						|
        });
 | 
						|
}
 | 
						|
 | 
						|
fn main() {
 | 
						|
    App::new()
 | 
						|
        .add_plugins(DefaultPlugins)
 | 
						|
        .add_startup_system(spawn_system)
 | 
						|
        .add_system(move_system)
 | 
						|
        .add_system(bounce_system)
 | 
						|
        .run();
 | 
						|
}
 |