Bug: too noisy graph displayed

[ThierryBerger]

I'm not sure if the bug is originating from this crate or bevy, but it seems weird that system_no_set is linked to system_in_child_set2 (green arrow should not exist).

Real project example

• From Split RapierContext dimforge/bevy_rapier#585

• Current output from bevy_mod_debugdump:

• Expected output (obtained with this PR):

[ThierryBerger]

as of 49d21ca ; the output looks like that:

Real project example output

More context

I tried to use functions from petgraph but was only greeted by difficulties:

• The graph we use not implementing IntoNeighbours, maybe avoidable by reconstructing a different graph from that one, not too sure...
• NodeId not implementing petgraph::IndexType...
  • bevy's NodeId not being Default, which is a problem for petgraph::IndexType, not a total blocker I think, but would need petgraph approval
  • bevy's NodeId being an enum which can't be built from an u32/usize ; that's the most problematic one.

I dropped the idea of using petgraph "correctly" and focused on getting somewhat of a progress

[ThierryBerger]

This might benefit being an option, or fix within bevy (chain() logic which might be the original culprit, but needs a lot more investigation so I'd make that a follow up only if needed.)

[jakobhellermann]

I've rewritten the code a bit and merged the PR as 7f8c5d3

Now without petgraph since bevy doesn't expose it anymore, but I think my toposort implementation should be right. The bevy schedules all look fine, with two or so of them having clarity improvements.

I've made the transitive pruning configurable, but on by default, as I expect most people would prefer that.

[ThierryBerger]

Cool, thanks! as a heads-up, I think bevy is considering re-using petgraph, so there might be a little back and forth churn again, but we'll see when it comes :)