
# Objective Fixes a part of #14274. Bevy has an incredibly inconsistent naming convention for its system sets, both internally and across the ecosystem. <img alt="System sets in Bevy" src="https://github.com/user-attachments/assets/d16e2027-793f-4ba4-9cc9-e780b14a5a1b" width="450" /> *Names of public system set types in Bevy* Most Bevy types use a naming of `FooSystem` or just `Foo`, but there are also a few `FooSystems` and `FooSet` types. In ecosystem crates on the other hand, `FooSet` is perhaps the most commonly used name in general. Conventions being so wildly inconsistent can make it harder for users to pick names for their own types, to search for system sets on docs.rs, or to even discern which types *are* system sets. To reign in the inconsistency a bit and help unify the ecosystem, it would be good to establish a common recommended naming convention for system sets in Bevy itself, similar to how plugins are commonly suffixed with `Plugin` (ex: `TimePlugin`). By adopting a consistent naming convention in first-party Bevy, we can softly nudge ecosystem crates to follow suit (for types where it makes sense to do so). Choosing a naming convention is also relevant now, as the [`bevy_cli` recently adopted lints](https://github.com/TheBevyFlock/bevy_cli/pull/345) to enforce naming for plugins and system sets, and the recommended naming used for system sets is still a bit open. ## Which Name To Use? Now the contentious part: what naming convention should we actually adopt? This was discussed on the Bevy Discord at the end of last year, starting [here](<https://discord.com/channels/691052431525675048/692572690833473578/1310659954683936789>). `FooSet` and `FooSystems` were the clear favorites, with `FooSet` very narrowly winning an unofficial poll. However, it seems to me like the consensus was broadly moving towards `FooSystems` at the end and after the poll, with Cart ([source](https://discord.com/channels/691052431525675048/692572690833473578/1311140204974706708)) and later Alice ([source](https://discord.com/channels/691052431525675048/692572690833473578/1311092530732859533)) and also me being in favor of it. Let's do a quick pros and cons list! Of course these are just what I thought of, so take it with a grain of salt. `FooSet`: - Pro: Nice and short! - Pro: Used by many ecosystem crates. - Pro: The `Set` suffix comes directly from the trait name `SystemSet`. - Pro: Pairs nicely with existing APIs like `in_set` and `configure_sets`. - Con: `Set` by itself doesn't actually indicate that it's related to systems *at all*, apart from the implemented trait. A set of what? - Con: Is `FooSet` a set of `Foo`s or a system set related to `Foo`? Ex: `ContactSet`, `MeshSet`, `EnemySet`... `FooSystems`: - Pro: Very clearly indicates that the type represents a collection of systems. The actual core concept, system(s), is in the name. - Pro: Parallels nicely with `FooPlugins` for plugin groups. - Pro: Low risk of conflicts with other names or misunderstandings about what the type is. - Pro: In most cases, reads *very* nicely and clearly. Ex: `PhysicsSystems` and `AnimationSystems` as opposed to `PhysicsSet` and `AnimationSet`. - Pro: Easy to search for on docs.rs. - Con: Usually results in longer names. - Con: Not yet as widely used. Really the big problem with `FooSet` is that it doesn't actually describe what it is. It describes what *kind of thing* it is (a set of something), but not *what it is a set of*, unless you know the type or check its docs or implemented traits. `FooSystems` on the other hand is much more self-descriptive in this regard, at the cost of being a bit longer to type. Ultimately, in some ways it comes down to preference and how you think of system sets. Personally, I was originally in favor of `FooSet`, but have been increasingly on the side of `FooSystems`, especially after seeing what the new names would actually look like in Avian and now Bevy. I prefer it because it usually reads better, is much more clearly related to groups of systems than `FooSet`, and overall *feels* more correct and natural to me in the long term. For these reasons, and because Alice and Cart also seemed to share a preference for it when it was previously being discussed, I propose that we adopt a `FooSystems` naming convention where applicable. ## Solution Rename Bevy's system set types to use a consistent `FooSet` naming where applicable. - `AccessibilitySystem` → `AccessibilitySystems` - `GizmoRenderSystem` → `GizmoRenderSystems` - `PickSet` → `PickingSystems` - `RunFixedMainLoopSystem` → `RunFixedMainLoopSystems` - `TransformSystem` → `TransformSystems` - `RemoteSet` → `RemoteSystems` - `RenderSet` → `RenderSystems` - `SpriteSystem` → `SpriteSystems` - `StateTransitionSteps` → `StateTransitionSystems` - `RenderUiSystem` → `RenderUiSystems` - `UiSystem` → `UiSystems` - `Animation` → `AnimationSystems` - `AssetEvents` → `AssetEventSystems` - `TrackAssets` → `AssetTrackingSystems` - `UpdateGizmoMeshes` → `GizmoMeshSystems` - `InputSystem` → `InputSystems` - `InputFocusSet` → `InputFocusSystems` - `ExtractMaterialsSet` → `MaterialExtractionSystems` - `ExtractMeshesSet` → `MeshExtractionSystems` - `RumbleSystem` → `RumbleSystems` - `CameraUpdateSystem` → `CameraUpdateSystems` - `ExtractAssetsSet` → `AssetExtractionSystems` - `Update2dText` → `Text2dUpdateSystems` - `TimeSystem` → `TimeSystems` - `AudioPlaySet` → `AudioPlaybackSystems` - `SendEvents` → `EventSenderSystems` - `EventUpdates` → `EventUpdateSystems` A lot of the names got slightly longer, but they are also a lot more consistent, and in my opinion the majority of them read much better. For a few of the names I took the liberty of rewording things a bit; definitely open to any further naming improvements. There are still also cases where the `FooSystems` naming doesn't really make sense, and those I left alone. This primarily includes system sets like `Interned<dyn SystemSet>`, `EnterSchedules<S>`, `ExitSchedules<S>`, or `TransitionSchedules<S>`, where the type has some special purpose and semantics. ## Todo - [x] Should I keep all the old names as deprecated type aliases? I can do this, but to avoid wasting work I'd prefer to first reach consensus on whether these renames are even desired. - [x] Migration guide - [x] Release notes
205 lines
8.4 KiB
Rust
205 lines
8.4 KiB
Rust
use async_channel::{Receiver, Sender};
|
|
|
|
use bevy_app::{App, AppExit, AppLabel, Plugin, SubApp};
|
|
use bevy_ecs::{
|
|
resource::Resource,
|
|
schedule::MainThreadExecutor,
|
|
world::{Mut, World},
|
|
};
|
|
use bevy_tasks::ComputeTaskPool;
|
|
|
|
use crate::RenderApp;
|
|
|
|
/// A Label for the sub app that runs the parts of pipelined rendering that need to run on the main thread.
|
|
///
|
|
/// The Main schedule of this app can be used to run logic after the render schedule starts, but
|
|
/// before I/O processing. This can be useful for something like frame pacing.
|
|
#[derive(Debug, Clone, Copy, Hash, PartialEq, Eq, AppLabel)]
|
|
pub struct RenderExtractApp;
|
|
|
|
/// Channels used by the main app to send and receive the render app.
|
|
#[derive(Resource)]
|
|
pub struct RenderAppChannels {
|
|
app_to_render_sender: Sender<SubApp>,
|
|
render_to_app_receiver: Receiver<SubApp>,
|
|
render_app_in_render_thread: bool,
|
|
}
|
|
|
|
impl RenderAppChannels {
|
|
/// Create a `RenderAppChannels` from a [`async_channel::Receiver`] and [`async_channel::Sender`]
|
|
pub fn new(
|
|
app_to_render_sender: Sender<SubApp>,
|
|
render_to_app_receiver: Receiver<SubApp>,
|
|
) -> Self {
|
|
Self {
|
|
app_to_render_sender,
|
|
render_to_app_receiver,
|
|
render_app_in_render_thread: false,
|
|
}
|
|
}
|
|
|
|
/// Send the `render_app` to the rendering thread.
|
|
pub fn send_blocking(&mut self, render_app: SubApp) {
|
|
self.app_to_render_sender.send_blocking(render_app).unwrap();
|
|
self.render_app_in_render_thread = true;
|
|
}
|
|
|
|
/// Receive the `render_app` from the rendering thread.
|
|
/// Return `None` if the render thread has panicked.
|
|
pub async fn recv(&mut self) -> Option<SubApp> {
|
|
let render_app = self.render_to_app_receiver.recv().await.ok()?;
|
|
self.render_app_in_render_thread = false;
|
|
Some(render_app)
|
|
}
|
|
}
|
|
|
|
impl Drop for RenderAppChannels {
|
|
fn drop(&mut self) {
|
|
if self.render_app_in_render_thread {
|
|
// Any non-send data in the render world was initialized on the main thread.
|
|
// So on dropping the main world and ending the app, we block and wait for
|
|
// the render world to return to drop it. Which allows the non-send data
|
|
// drop methods to run on the correct thread.
|
|
self.render_to_app_receiver.recv_blocking().ok();
|
|
}
|
|
}
|
|
}
|
|
|
|
/// The [`PipelinedRenderingPlugin`] can be added to your application to enable pipelined rendering.
|
|
///
|
|
/// This moves rendering into a different thread, so that the Nth frame's rendering can
|
|
/// be run at the same time as the N + 1 frame's simulation.
|
|
///
|
|
/// ```text
|
|
/// |--------------------|--------------------|--------------------|--------------------|
|
|
/// | simulation thread | frame 1 simulation | frame 2 simulation | frame 3 simulation |
|
|
/// |--------------------|--------------------|--------------------|--------------------|
|
|
/// | rendering thread | | frame 1 rendering | frame 2 rendering |
|
|
/// |--------------------|--------------------|--------------------|--------------------|
|
|
/// ```
|
|
///
|
|
/// The plugin is dependent on the [`RenderApp`] added by [`crate::RenderPlugin`] and so must
|
|
/// be added after that plugin. If it is not added after, the plugin will do nothing.
|
|
///
|
|
/// A single frame of execution looks something like below
|
|
///
|
|
/// ```text
|
|
/// |---------------------------------------------------------------------------|
|
|
/// | | | RenderExtractApp schedule | winit events | main schedule |
|
|
/// | sync | extract |----------------------------------------------------------|
|
|
/// | | | extract commands | rendering schedule |
|
|
/// |---------------------------------------------------------------------------|
|
|
/// ```
|
|
///
|
|
/// - `sync` is the step where the entity-entity mapping between the main and render world is updated.
|
|
/// This is run on the main app's thread. For more information checkout [`SyncWorldPlugin`].
|
|
/// - `extract` is the step where data is copied from the main world to the render world.
|
|
/// This is run on the main app's thread.
|
|
/// - On the render thread, we first apply the `extract commands`. This is not run during extract, so the
|
|
/// main schedule can start sooner.
|
|
/// - Then the `rendering schedule` is run. See [`RenderSystems`](crate::RenderSystems) for the standard steps in this process.
|
|
/// - In parallel to the rendering thread the [`RenderExtractApp`] schedule runs. By
|
|
/// default, this schedule is empty. But it is useful if you need something to run before I/O processing.
|
|
/// - Next all the `winit events` are processed.
|
|
/// - And finally the `main app schedule` is run.
|
|
/// - Once both the `main app schedule` and the `render schedule` are finished running, `extract` is run again.
|
|
///
|
|
/// [`SyncWorldPlugin`]: crate::sync_world::SyncWorldPlugin
|
|
#[derive(Default)]
|
|
pub struct PipelinedRenderingPlugin;
|
|
|
|
impl Plugin for PipelinedRenderingPlugin {
|
|
fn build(&self, app: &mut App) {
|
|
// Don't add RenderExtractApp if RenderApp isn't initialized.
|
|
if app.get_sub_app(RenderApp).is_none() {
|
|
return;
|
|
}
|
|
app.insert_resource(MainThreadExecutor::new());
|
|
|
|
let mut sub_app = SubApp::new();
|
|
sub_app.set_extract(renderer_extract);
|
|
app.insert_sub_app(RenderExtractApp, sub_app);
|
|
}
|
|
|
|
// Sets up the render thread and inserts resources into the main app used for controlling the render thread.
|
|
fn cleanup(&self, app: &mut App) {
|
|
// skip setting up when headless
|
|
if app.get_sub_app(RenderExtractApp).is_none() {
|
|
return;
|
|
}
|
|
|
|
let (app_to_render_sender, app_to_render_receiver) = async_channel::bounded::<SubApp>(1);
|
|
let (render_to_app_sender, render_to_app_receiver) = async_channel::bounded::<SubApp>(1);
|
|
|
|
let mut render_app = app
|
|
.remove_sub_app(RenderApp)
|
|
.expect("Unable to get RenderApp. Another plugin may have removed the RenderApp before PipelinedRenderingPlugin");
|
|
|
|
// clone main thread executor to render world
|
|
let executor = app.world().get_resource::<MainThreadExecutor>().unwrap();
|
|
render_app.world_mut().insert_resource(executor.clone());
|
|
|
|
render_to_app_sender.send_blocking(render_app).unwrap();
|
|
|
|
app.insert_resource(RenderAppChannels::new(
|
|
app_to_render_sender,
|
|
render_to_app_receiver,
|
|
));
|
|
|
|
std::thread::spawn(move || {
|
|
#[cfg(feature = "trace")]
|
|
let _span = tracing::info_span!("render thread").entered();
|
|
|
|
let compute_task_pool = ComputeTaskPool::get();
|
|
loop {
|
|
// run a scope here to allow main world to use this thread while it's waiting for the render app
|
|
let sent_app = compute_task_pool
|
|
.scope(|s| {
|
|
s.spawn(async { app_to_render_receiver.recv().await });
|
|
})
|
|
.pop();
|
|
let Some(Ok(mut render_app)) = sent_app else {
|
|
break;
|
|
};
|
|
|
|
{
|
|
#[cfg(feature = "trace")]
|
|
let _sub_app_span = tracing::info_span!("sub app", name = ?RenderApp).entered();
|
|
render_app.update();
|
|
}
|
|
|
|
if render_to_app_sender.send_blocking(render_app).is_err() {
|
|
break;
|
|
}
|
|
}
|
|
|
|
tracing::debug!("exiting pipelined rendering thread");
|
|
});
|
|
}
|
|
}
|
|
|
|
// This function waits for the rendering world to be received,
|
|
// runs extract, and then sends the rendering world back to the render thread.
|
|
fn renderer_extract(app_world: &mut World, _world: &mut World) {
|
|
app_world.resource_scope(|world, main_thread_executor: Mut<MainThreadExecutor>| {
|
|
world.resource_scope(|world, mut render_channels: Mut<RenderAppChannels>| {
|
|
// we use a scope here to run any main thread tasks that the render world still needs to run
|
|
// while we wait for the render world to be received.
|
|
if let Some(mut render_app) = ComputeTaskPool::get()
|
|
.scope_with_executor(true, Some(&*main_thread_executor.0), |s| {
|
|
s.spawn(async { render_channels.recv().await });
|
|
})
|
|
.pop()
|
|
.unwrap()
|
|
{
|
|
render_app.extract(world);
|
|
|
|
render_channels.send_blocking(render_app);
|
|
} else {
|
|
// Renderer thread panicked
|
|
world.send_event(AppExit::error());
|
|
}
|
|
});
|
|
});
|
|
}
|