How to change RetainedGizmos (occasionally)?

[LTstrange]

Im trying to use the retained gizmo to render 10k+ orbits. These orbits will not change in most of the time, but I still need some way to create/remove some orbits.

When program started, orbits are created from data. Then some orbits may be created/removed by user through some python code.

So I need a way to efficiently add a batch of orbits, remove some orbits, even add/remove a sequence of orbits one by one.

The first solution I thought was recreate Gizmo component whenever a orbit is created, but performance may be a problem.

Then I tried to attach every orbit entity a Gizmo component, still, the performance is bad than immediate gizmos.

Is there any way to solve this problem?

[Henauxg]

The first solution I thought was recreate Gizmo component whenever a orbit is created

This is the intended usage of retained gizmos. You create an Entity when you need to draw one, and despawn the Entity when you don't need it anymore. You can optionally not despawn the Entity and just update the Gizmo Component.

Then I tried to attach every orbit entity a Gizmo component, still, the performance is bad than immediate gizmos.

This seems weird, performances were worse with all orbits as retained gizmos compared to drawing them all as immediate gizmos ?
Also I'm not sure that I understand correctly. What is the difference between recreate Gizmo component whenever a orbit is created and Then I tried to attach every orbit entity a Gizmo component ?

Note: If line gizmos performances really end up being a problem you could be interested by https://github.com/ForesightMiningSoftwareCorporation/bevy_polyline. Beware it is still on Bevy v0.15.0 though.

[LTstrange]

Thanks for your detailed reply! It really helps clarify some of my confusion.

To elaborate a bit more on what I meant by the two approaches:

1. Recreate Gizmo component whenever an orbit is created

This means there's only one shared Gizmo component that draws all orbits collectively. Every time a new orbit is added (or an existing one removed), the entire Gizmo asset is recreated to reflect the current set of orbits.

Example:

fn setup(mut commands: Commands, mut gizmo_assets: ResMut<Assets<GizmoAsset>>) {
    // Create a single Gizmo asset that will be used to draw all orbits collectively
    let mut gizmo = GizmoAsset::default();
    for i in 0..10_000 {
        let angle = (2.0 * PI * i as f32) / 10_000.0;

        let iso = Isometry3d::from_rotation(Quat::from_rotation_y(angle));
        gizmo.circle(iso, 1.0, Color::srgba(1.0, 1.0, 1.0, 0.01));

        commands.spawn(Orbit);
    }
    // Spawn the Gizmo component outside the loop after all orbits are added to it
    commands.spawn(Gizmo {
        handle: gizmo_assets.add(gizmo),
        ..Default::default()
    });
}

Then, when adding or removing orbits dynamically, we'd update this single Gizmo asset accordingly. This was my initial idea, but I worried about performance due to constant recreation/updates.

2. Attach every orbit entity a Gizmo component

This means each orbit gets its own dedicated Gizmo component and asset. While conceptually simple, it turns out to be inefficient — especially with tens of thousands of orbits.

fn setup(mut commands: Commands, mut gizmo_assets: ResMut<Assets<GizmoAsset>>) {
    for i in 0..10_000 {
        // For each orbit, create a dedicated Gizmo asset
        let mut gizmo = GizmoAsset::default();
        let angle = (2.0 * PI * i as f32) / 10_000.0;

        let iso = Isometry3d::from_rotation(Quat::from_rotation_y(angle));
        gizmo.circle(iso, 1.0, Color::srgba(1.0, 1.0, 1.0, 0.01));

        // Attach the newly created Gizmo component to the orbit entity
        commands.spawn((
            Orbit,
            Gizmo {
                handle: gizmo_assets.add(gizmo),
                ..Default::default()
            },
        ));
    }
}

This approach ends up being slower than drawing everything using immediate mode gizmos.

Also, thanks for pointing me to bevy_polyline, I'll definitely take a look!

[Henauxg]

Oh my bad, you should definitely try the approach 1, it might end up just fine if your updates are infrequent enough (human interactions).

If updates take too long, try batching your gizmos in a few batch entities, and tweak the batch size (10,100,1000, ...). This way you'(d have a best of both worlds: fast rendering with a few gizmos entities, but fast updates due to only updating a few batches instead of every gizmos.