bevy-inspector-egui: Custom Inspection for Bevy

What bevy-inspector-egui Adds to a Bevy Application

bevy-inspector-egui is an inspection layer for applications built with the Bevy game engine. Its purpose is to expose reflected data through egui controls rather than requiring a separate editing workflow outside the running application. The crate can display individual Reflect values, associate editor options with fields and enum variants, and provide utilities for inspecting Bevy resources, entities, and assets.

The main audience is a Bevy developer who needs a runtime debugging panel, an in-game configuration editor, or a larger editor assembled from egui. The plugin can also help during development when seeing a resource's current value is more useful than adding temporary logging.

The crate provides two levels of use. Quick plugins add standard inspector windows with little application code. They cover a whole world, one resource, an application state, or an asset collection. The manual API exposes the same general machinery to systems that construct their own egui windows. This distinction matters because the quick plugins do not allow customization of their presentation and content. Projects that need a different layout should copy or replace that implementation, as the README suggests, rather than trying to configure a fixed plugin.

Reflection, Registration, and Inspector Data Flow

The central mechanism is Bevy reflection. `reflect_inspector` supplies general machinery for displaying `Reflect` values, while `bevy_inspector` adds utility functions for world resources, entities, and assets. A type must therefore be compatible with reflection before the generic inspector can represent it. The resource example derives both `Reflect` and `InspectorOptions`, applies `#[reflect(Resource, InspectorOptions)]`, initializes the resource with `init_resource::<Configuration>()`, and registers it with `register_type::<Configuration>()`.

That sequence matters. `ResourceInspectorPlugin` will not initialize the selected resource, and registration is required for the example type to be displayed. Built-in resources can also be selected when they implement `Reflect`, which the README demonstrates with `Time`.

Field metadata changes the generated controls without separating the value type from its editor configuration. In the example, `#[inspector(min = 0.0, max = 1.0)]` constrains the editor associated with `option`. The options system can attach arbitrary options to fields and enum variants, while `InspectorPrimitive` allows an application to replace the default presentation for a type. Such custom type data must be registered with `register_type_data::<T, InspectorEguiImpl>()`.

For manual UI, the application obtains the primary egui context from `World`, creates an `egui::Window`, and calls project-specific helpers. `ui_for_world` corresponds to the world quick plugin, `ui_for_assets::<StandardMaterial>` renders an asset view, and `ui_for_world_entities` renders the entity section. This is ordinary egui composition, so layout code such as `ScrollArea`, headings, and `CollapsingHeader` remains under application control.

Starting With WorldInspectorPlugin

The README does not provide a Cargo installation command, and the repository information shown here does not document a package version to pin. Examples are located under `crates/bevy-inspector-egui/examples`, so a new user should start from the repository's example application and its crate configuration rather than inventing a dependency declaration.

The smallest documented world inspector requires Bevy's default plugins, `EguiPlugin`, and `WorldInspectorPlugin`. This example adds the standard Bevy plugin set, installs the egui bridge, creates the world inspector, and starts the application:

use bevy::prelude::*;
use bevy_inspector_egui::{bevy_egui::EguiPlugin, quick::WorldInspectorPlugin};

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .add_plugins(EguiPlugin::default())
        .add_plugins(WorldInspectorPlugin::new())
        .run();
}

The plugin is described as displaying the world's entities, resources, and assets. Its UI should be treated as a development tool rather than a finished product surface. The README explicitly presents it as the option for simple use cases and says customization requires copying its implementation or building the UI manually.

There is no documented command in the repository information for launching this example. The exact Cargo invocation must therefore come from the example's own manifest or standard Cargo workflow rather than from an invented project-specific script.

Inspecting One Registered Bevy Resource

A focused resource editor is useful when the application only needs one reflected value. The following is the README's complete configuration example. It defines a resource with a field-level range option, initializes that resource, registers its type, and installs inspectors for both the custom type and Bevy's `Time` resource.

use bevy::prelude::*;
use bevy_inspector_egui::prelude::*;
use bevy_inspector_egui::quick::ResourceInspectorPlugin;

#[derive(Reflect, Resource, Default, InspectorOptions)]
#[reflect(Resource, InspectorOptions)]
struct Configuration {
    name: String,
    #[inspector(min = 0.0, max = 1.0)]
    option: f32,
}

The application setup then has two independent requirements. `init_resource::<Configuration>()` creates the resource because the plugin does not do that. `register_type::<Configuration>()` makes its reflected type available for display. The final plugin call binds the UI to that type:

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .init_resource::<Configuration>()
        .register_type::<Configuration>()
        .add_plugins(EguiPlugin::default())
        .add_plugins(ResourceInspectorPlugin::<Configuration>::default())
        .add_plugins(ResourceInspectorPlugin::<Time>::default())
        .run();
}

This approach is a poor fit if the desired editor needs a custom hierarchy, additional controls, or a different window structure. `ResourceInspectorPlugin` handles a single resource window, whereas the manual API can combine resources, assets, entities, and arbitrary egui widgets in one application-owned interface.

Building a Custom Egui Inspection Window

Manual UI construction is the appropriate route when the inspector must become part of a larger editor. The README's example adds `DefaultInspectorConfigPlugin`, schedules a system in `EguiPrimaryContextPass`, obtains the primary `EguiContext`, and composes inspection helpers inside an `egui::Window`.

The application part of the example is:

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .add_plugins(EguiPlugin::default())
        .add_plugins(bevy_inspector_egui::DefaultInspectorConfigPlugin)
        .add_systems(EguiPrimaryContextPass, inspector_ui)
        .run();
}

`DefaultInspectorConfigPlugin` supplies default options and `InspectorEguiImpl` implementations. Without those defaults or project-specific replacements, a custom system does not automatically receive the same presentation data as the quick plugins.

The system then handles missing primary context by returning. If the query succeeds, it clones the context and draws project-selected sections:

egui::Window::new("UI").show(egui_context.get_mut(), |ui| {
    egui::ScrollArea::vertical().show(ui, |ui| {
        bevy_inspector_egui::bevy_inspector::ui_for_world(world, ui);
        bevy_inspector_egui::bevy_inspector::ui_for_assets::<StandardMaterial>(world, ui);
        ui.heading("Entities");
        bevy_inspector_egui::bevy_inspector::ui_for_world_entities(world, ui);
    });
});

The documentation also points to an `egui_dock` integration example. That is an example composition pattern rather than a required dependency of the crate.

Features, Compatibility, and Maintenance Boundaries

The default `bevy_pbr` feature registers default options for `bevy_pbr` types. Projects that do not use that module are directed to disable it to reduce the dependency footprint. Two other Cargo features have narrower jobs. `bevy_gizmos` enables inspection of `GizmoConfigGroup`, while `highlight_changes` highlights changed values every frame.

The `highlight_changes` option has a documented design limitation. It is implemented as a Cargo feature rather than a runtime setting because the author describes runtime configurability as a stopgap solution. Enabling change highlighting therefore requires a build-time feature choice. The README does not document a runtime configuration key for it.

Compatibility is tied closely to Bevy's release cycle. The support table maps Bevy 0.19 to bevy-inspector-egui 0.37, Bevy 0.18 to 0.36, Bevy 0.17 to 0.35 and 0.34, and older releases to their listed crate versions. Because the workspace declares `egui = "0.34"` and `bevy_egui = "0.40.0"`, its egui integration also has a specific dependency boundary.

The repository is not archived, and its last push was on 2026-06-20. It has no GitHub releases, so adoption decisions should use the changelog and version table rather than assume a GitHub release artifact exists. The project is primarily identified as Apache-2.0 licensed, while the repository also contains `LICENSE-APACHE.md` and `LICENSE-MIT.md`. An organization should inspect those files and its dependency licenses for its own compliance requirements. The license files do not by themselves confirm compatibility with a particular distribution model.

Where a Custom Editor or Simpler Logging Fits Better

The clearest alternative is to build an editor directly with `bevy_egui` and egui when the application does not need reflection-based inspection. The manual example still uses bevy-inspector-egui helpers because those helpers already know how to present Bevy entities, resources, and assets. A project that merely needs ordinary egui widgets around application-owned data can use the egui bridge directly and omit this crate.

For debugging, adding targeted logging can also be sufficient when the requirement is to observe occasional values rather than edit them interactively. The repository does not document such logging as a feature, but it does establish that these inspectors are based on reflected values and editable-looking field controls. A logging-only workflow therefore avoids maintaining registration and custom inspector data when persistent interactive presentation is unnecessary.

The reverse boundary is equally important. bevy-inspector-egui does not remove the need for reflection. A type that is not registered cannot be assumed to appear, and a field-specific constraint such as `min` and `max` does not make an otherwise unsupported type inspectable. Likewise, `ui_for_value` is convenient for a single reflected value, but the README notes that values such as `Handle<StandardMaterial>` cannot display the referenced asset's value through that route. Asset context requires a different utility or inspection path.

Editorial conclusion

Adopt bevy-inspector-egui if your Bevy application needs reflected resource editing or a runtime view of entities and assets. Do not choose it merely for a polished preset, because the quick plugins deliberately restrict presentation customization. Before adopting, verify that your installed Bevy and bevy-inspector-egui versions match the support table, then confirm that every type to inspect derives Reflect and is registered with Bevy.

Frequently asked questions

Official sources

1. Issues
2. jakobhellermann/bevy-inspector-egui on GitHub
3. License: Apache-2.0
4. README