bevy 0.15 rc

[Vrixyz]

Something is rendering! but still mostly broken.

Analysis

• Retain Rendering World (adopted) bevyengine/bevy#15320 broke Update to bevy 0.15 vladbat00/bevy_egui#309

Entities are used all over bevy_egui to refer to items:

• EguiPipelines
• EguiNode
• EguiRenderToTextureNode (let's ignore that for now)
• EguiPass

To me, it seems that most entities should refer to render world's.

But the source to get these Entities are sometimes ExtractedWindows, which is from main world:

• https://github.com/mvlabat/bevy_egui/blob/main/src/render_systems.rs#L254-L270

Questions:

Which world should our key entities be from ?

RenderEntity

Since most operations are from the render schedules, I think it makes sense to be on RenderEntity.

Not blocking: We can't use RenderEntity as a key because Eq and Hash are not derived. We could reimplement our own but it's an annoyance.
This should be fixed by bevyengine/bevy#16191

Blocking (?): When in queue_pipelines_system, our window doesn't have a RenderEntity, so it's difficult to add a RenderEntity key.

TODO: ? we could try to replace the window extract (which I believe comes from bevy), to create our own extraction logic which would occur earlier, but I fear this would result in surprises for users. (and I'm not sure it's possible).

MainEntity

So if I can´t rely on RenderEntity, let's try to rely on the Entity from main world:

EguiRenderToTextureNode::render_to_texture_target is split into 2 entities, to keep links at all times.

unfortunately this doesn´t work, I'm not sure where the error is.

I'll hunt for error handling in case of entities not found and add more debug while I think of better debugging strategy 🤔

Debugging attempt

• I notice that EguiNode::update() is never called, I guess that suggests a wrong use of bevy's API.
  • changelog from https://bevyengine.org/learn/migration-guides/0-14-to-0-15/ mentions UINode changes, related to parent/child, it doesn't seem relevant to our use case :(

[Vrixyz]

EguiTextureId::Managed is actually checked in a main world schedule ; so this should be window_entity_main !