Incorrect draw order

[edeetee]

I have two, possibly related, issues with UI ordering

1. Cables are above nodes

Cables should render behind nodes. As you can see, if they are in front, it can look pretty janky.

2. Attempting to select a node selects most back node when layered

If I click on the title "ObjRender", it brings the "Expression" node to the front.
I expect the UI to reflect what I can interact with. "Expression" should only be selected if I click where I can see it, on the left.

[setzer22]

Hi! Thanks for reporting.

I have tried multiple workarounds to get this fixed, but I haven't been able to find a way to fix this without changing egui. The two issues you're reporting come from the same place. Egui doesn't give us enough options to control the rendering order of things. Right now, the order in which things are drawn is controlled by their LayerId:

• First, layer ids are sorted by the very coarse-grained Order field which is user-editable, but not useful, since it's an enum with 5 hard-coded values.
• Then, some LayerIds are sorted by their relative positions inside the the ctx.memory().areas.order list. This list is only used for Areas and is inaccessible to end users behind several private or pub(crate) fields. Even if it were, the list is only meant to be used for Areas and would cause trouble if used for other purposes (such as making sure nodes are drawn in the right way).

Due to this limitation (layer ordering being inaccessible), when I wrote this library I wrote a parallel mechanism in node_order to make sure nodes always get processed in the same order. The problem there is that egui is immediate mode, so if make the calls to draw nodes bottom-to-top, things will get rendered in the right order, but mouse interaction will be wrong, because nodes on bottom will steal focus.

In my opinion, the right solution here would be to modify egui so that this layer sorting mechanism is better exposed to end users, and detached from areas when possible. I think I have a clear enough picture of the code that I could make a PR for that, but I'm not sure if it would be welcome upstream. With this, we'd be able to define a draw order that is different of the order in which the calls to draw nodes is made.

Another solution would be to use Areas for the nodes. The problem with that is that the Area mechanism (which is the base for egui::Window) does not allow things like accessing area positions or programatically moving the areas. We also don't want the nodes to actually behave like areas (in the sense that a node should never be on top of a floating window, or be able to escape its window, in case you're drawing the node editor inside a window). There's not even support for moving an area to the top. So going that way would require even more changes in egui and I don't think it's a good direction to focus on.

Long story short, solving this issue in the right way needs changes inside egui, which means it will take a while. I'm going to report this upstream and propose a fix and post here when that happens 🙂.

I would like to suggest a workaround in the meantime, or build some hacky solution on my end that I could ship right now on my end, but I can't find any way to do this that doesn't require messing with egui internals.

PS: By the way, @edeetee this application looks really cool! Is this some sort of shader graph editor? I'd love to see more about it 😄