Follow up on Retained Rendering

[Trashtalk217]

Merging #15320 leaves behind a couple of gaps that can be easily filled in a follow-up PR(s).

Implement WorldQuery for RenderEntity and MainEntity

When querying &RenderEntity currently from within the main world (or Extract systems in the render world), you constantly have to call .id() on every thing you query, because RenderEntity is a component that contains an entity. This indirection is annoying and makes the migration to 0.15 more cumbersome (more line changes), so we can implement a custom WorldQuery so that this happens automatically (think of querying Entity).

The same is true for MainEntity.

Using required components

There are a couple of places, mainly in bevy_render/src/extract_component.rs where SyncToRenderWorld is automatically added to certain components. This is currently done with observers, but it's much better to do this with required components. This is being tackled in #15582.

Deprecating get_or_spawn

get_or_spawn Is quite often used in extraction systems, given how things used to work. But with a retained rendering world, the entity should always already exist, so just get should suffice.

[hymm]

We should probably also remove the in-engine uses of TemporaryRenderEntity if possible.

[Trashtalk217]

We should probably also remove the in-engine uses of TemporaryRenderEntity if possible.

Yes, definitely a good idea. Although I expect the solutions for that to be more specific to the rendering contexts in which they are used.

[alice-i-cecile]

Spawning a specific entity value is rarely the right choice. Most apps should favor Commands::spawn. This method should generally only be used for sharing entities across apps, and only when they have a scheme worked out to share an ID space (which doesn’t happen by default).

From get_or_spawn's docs. insert_or_spawn_batch has the same warning. Since we're no longer using this internally, we should deprecate this pattern completely as a footgun. Entity should be opaque, and we should not permit users to spawn entities with specific IDs in any way.

[JMS55]

I think we've covered everything but #15704 now?

[chengts95]

Spawning a specific entity value is rarely the right choice. Most apps should favor Commands::spawn. This method should generally only be used for sharing entities across apps, and only when they have a scheme worked out to share an ID space (which doesn’t happen by default).

From get_or_spawn's docs. insert_or_spawn_batch has the same warning. Since we're no longer using this internally, we should deprecate this pattern completely as a footgun. Entity should be opaque, and we should not permit users to spawn entities with specific IDs in any way.

I have a strong motivation to use shared entity ids for multiple worlds. I have no idea why you think this is not needed and all other ECS can spawn entity with specific id. If entities' ids cannot be consistent when I save or load a world, it is a disaster. Please keep the feature available and do not deprecate it. Or you can tell me what is the alternatives.

[alice-i-cecile]

I have a strong motivation to use shared entity ids for multiple worlds

Can you explain this use case? What are you ultimately trying to achieve, and why is this strategy important to do this? The EntityMapper trait is designed for the serialization / networking use cases, and has been how Bevy serializes and deserializes scenes since Bevy 0.1 as far as I'm aware.

[chengts95]

I have a strong motivation to use shared entity ids for multiple worlds

Can you explain this use case? What are you ultimately trying to achieve, and why is this strategy important to do this? The EntityMapper trait is designed for the serialization / networking use cases, and has been how Bevy serializes and deserializes scenes since Bevy 0.1 as far as I'm aware.

  
    clone_entities(app.world(), app2.world_mut());
    reg.clone_world(app.world(), app2.world_mut());

I simply want to clone worlds, the worlds should have identical IDs for multiple algorithm designs, and I want native performance. The serialized and deserialized scenes are too heavy. Generally, bevy relies on reflection to serialize and deserialize, which is an overkill solution. Serialization is not an option for cloning a world for high-performance applications.

I have applications for power system simulation in Bevy. The ECS can become very successful in industrial applications that are not related to video games. Many algorithms such as Monte-Carlo simulation and N-1 stability verification require duplicating the data. In the design i have implemented, I only rely on the Clone trait to duplicate data. If the design permits, I will even choose to aggressively copy the archetype table as a whole and reconstruct the data in a new world.

[Trashtalk217]

As a bit of extra context, because it's not explained in the warning. One of the issues with spawning arbitrary entities is the fact that under the hood, entity information is stored as a

Vec<EntityMeta>

see also https://docs.rs/bevy/0.14.2/bevy/ecs/entity/struct.Entities.html. This works well when your entity range is dense, but if you spawn in entity 1,000,000 out of the blue, you need to allocate a lot of memory for this one vector. This is a bit of a footgun.

Moreover, if you're using this for a save system where you just spawn in the entities by id, this is incredibly brittle when dealing with updating bevy / plugins. If a plugin decides to spawn in an extra entity, you can't load old saves anymore.

These are the primary reasons why we removed / are removing this feature.

EDIT: That's a fascinating usecase btw, I was busy writing while you commented.

[alice-i-cecile]

I'm definitely interested in supporting that pattern! I've created #16559 to discuss how this can be best achieved; let's move this over there.