Struct EguiPlugin 

pub struct EguiPlugin {
    pub enable_multipass_for_primary_context: bool,
    pub ui_render_order: UiRenderOrder,
    pub bindless_mode_array_size: Option<NonZero<u32>>,
}

Adds all Egui resources and render graph nodes.

Fields

enable_multipass_for_primary_context: bool

👎Deprecated: The option to disable the multi-pass mode is now deprecated, use EguiPlugin::default instead

About Egui multi-pass mode

From the Egui documentation:

By default, egui usually only does one pass for each rendered frame. However, egui supports multi-pass immediate mode. Another pass can be requested with egui::Context::request_discard.

This is used by some widgets to cover up “first-frame jitters”. For instance, the egui::Grid needs to know the width of all columns before it can properly place the widgets. But it cannot know the width of widgets to come. So it stores the max widths of previous frames and uses that. This means the first time a Grid is shown it will guess the widths of the columns, and will usually guess wrong. This means the contents of the grid will be wrong for one frame, before settling to the correct places. Therefore Grid calls egui::Context::request_discard when it is first shown, so the wrong placement is never visible to the end user.

Usage

Set this to true to enable an experimental support for the Egui multi-pass mode.

Enabling the multi-pass mode will require your app to use the new EguiPrimaryContextPass schedule:

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .add_plugins(EguiPlugin::default())
        .add_systems(Startup, setup_camera_system)
        .add_systems(EguiPrimaryContextPass, ui_example_system)
        .run();
}
fn setup_camera_system(mut commands: Commands) {
    commands.spawn(Camera2d);
}
fn ui_example_system(contexts: EguiContexts) -> Result {
    // ...
    Ok(())
}

If you create multiple contexts (for example, when using multiple windows or rendering to an image), you need to define a custom schedule and assign it to additional contexts manually:

#[derive(ScheduleLabel, Clone, Debug, PartialEq, Eq, Hash)]
pub struct SecondWindowContextPass;

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .add_plugins(EguiPlugin::default())
        .add_systems(Startup, setup_system)
        .add_systems(EguiPrimaryContextPass, ui_example_system)
        .add_systems(SecondWindowContextPass, ui_example_system)
        .run();
}

fn setup_system(
    mut commands: Commands,
    mut egui_global_settings: ResMut<EguiGlobalSettings>,
) {
    // Disable the automatic creation of a primary context to set it up manually.
    egui_global_settings.auto_create_primary_context = false;
    // Spawn a camera for the primary window.
    commands.spawn((Camera3d::default(), PrimaryEguiContext));
    // Spawn the second window and its camera.
    let second_window_id = commands.spawn(Window::default()).id();
    commands.spawn((
        EguiMultipassSchedule::new(SecondWindowContextPass),
        Camera3d::default(),
        Camera {
            target: RenderTarget::Window(WindowRef::Entity(second_window_id)),
            ..Default::default()
        },
    ));
}

fn ui_example_system(contexts: EguiContexts) -> Result {
    // ...
    Ok(())
}

In the future, the multi-pass mode will likely phase the single-pass one out.

Note to developers of public plugins

If your plugin depends on bevy_egui, here are some hints on how to implement the support of both single-pass and multi-pass modes (with respect to the EguiPlugin::enable_multipass_for_primary_context flag):

• Don’t initialize EguiPlugin for the user, i.e. DO NOT use add_plugins(EguiPlugin { ... }) in your code, users should be able to opt in or opt out of the multi-pass mode on their own.
• If you add UI systems, make sure they go into the EguiPrimaryContextPass schedule - this will guarantee your plugin supports both the single-pass and multi-pass modes.

Your plugin code might look like this:

pub struct MyPlugin;

impl Plugin for MyPlugin {
    fn build(&self, app: &mut App) {
        // Don't add the plugin for users, let them chose the default mode themselves
        // and just make sure they initialize EguiPlugin before yours.
        assert!(app.is_plugin_added::<EguiPlugin>());

        app.add_systems(EguiPrimaryContextPass, ui_system);
    }
}

fn ui_system(contexts: EguiContexts) -> Result {
    // ...
    Ok(())
}

ui_render_order: UiRenderOrder

Configures whether egui will be rendered above or below bevy_ui_render(Bevy UI) GUIs.

Defaults to UiRenderOrder::EguiAboveBevyUi, on the assumption that games that use both will typically use Bevy UI for the primary game UI, and egui for debug overlays.

Note: this option take effect only if both bevy_ui and bevy_egui UIs are rendered to the same camera.

bindless_mode_array_size: Option<NonZero<u32>>

Configure if bindless mode for rendering can be used on devices that has support for it.

It is useful in cases where multiple textures are used to render UI and renderer needs to frequently switch between different textures. This avoids the cost of frequently changing bind groups.

Trait Implementations

impl Default for EguiPlugin

fn default() -> Self

Returns the “default value” for a type.

impl Plugin for EguiPlugin

fn build(&self, app: &mut App)

Configures the App to which this plugin is added.

fn finish(&self, app: &mut App)

Finish adding this plugin to the App, once all plugins registered are ready. This can be useful for plugins that depends on another plugin asynchronous setup, like the renderer.

fn ready(&self, _app: &App) -> bool

Has the plugin finished its setup? This can be useful for plugins that need something asynchronous to happen before they can finish their setup, like the initialization of a renderer. Once the plugin is ready, finish should be called.

fn cleanup(&self, _app: &mut App)

Runs after all plugins are built and finished, but before the app schedule is executed. This can be useful if you have some resource that other plugins need during their build step, but after build you want to remove it and send it to another thread.

fn name(&self) -> &str

Configures a name for the Plugin which is primarily used for checking plugin uniqueness and debugging.

fn is_unique(&self) -> bool

If the plugin can be meaningfully instantiated several times in an App, override this method to return false.