Upstream and use bevy_mod_picking #12365
Labels
A-Dev-Tools
Tools used to debug Bevy applications.
A-Editor
Graphical tools to make Bevy games
A-Input
Player input via keyboard, mouse, gamepad, and more
A-Picking
Pointing at and selecting objects of all sorts
A-UI
Graphical user interfaces, styles, layouts, and widgets
C-Enhancement
A new feature
D-Complex
Quite challenging from either a design or technical perspective. Ask for help!
X-Blessed
Has a large architectural impact or tradeoffs, but the design has been endorsed by decision makers
Why we need picking (and raycasting)
To be glib,
bevy_mod_picking
by @aevyrie allows users to point at things and click on them.Picking is the pattern of turning pointer events (like mouse clicks or touches) into the hover/selection/deselection of objects (meshes, sprites, UI...) via hit testing, of which raycasting is one common form.
Bevy needs an equivalent set of tools for:
Interaction
component and focus handlingbalanced breakfastscene editor or interactive debuggerWhile the first application can and currently is solved by relying on an external crate, this is still limiting because:
main
, as it's not part of our CI.For the remaining use cases, we simply can't rely on an external crate that relies on Bevy due to circular dependencies which present severe technical and organizational challenges.
Why we should upstream rather than re-implement
Of course, the next question is "why should we upstream a crate, rather than simply building it ourselves!".
After all, it wasn't invented here, for a very narrow definition of "here".
However, as I previously discussed in bevyengine/rfcs#63, reinventing rather than upstreaming popular, functioning crates is both risky and wasteful.
While this functionality may seem simple at first glance, hard-won experience shows that there are a large number of ergonomic, design and performance concerns that must be carefully navigated.
bevy_mod_picking
is a stable, beloved part of Bevy's ecosystem. While it may not be perfect in its current form, it decidedly works: with good performance, a lovely API and a generally low-bug experience. Building our own equivalent will take longer, involve dramatically more controversy, and leave us at a worse starting point.Organizational strategy for upstreaming
I've been working closely with @aevyrie and other members of the community to plan this migration.
As part of that, we have a pair of junior volunteers from Purdue: Avi and Xavier who are helping us with this work (this issue is a sibling to #12349). Please be patient and kind with them as they work, but remember that they're here to learn and improve.
During this discussion, we've outlined a few key strategies to minimize the pain of this complex migration:
The essential problems to avoid are:
If you have breaking concerns or ideas, please, please open issues to record them (and link this issue). We want to hear them, and to improve all areas of the engine: we just don't want the migration to fall into disarray :)
Technical pathway to upstreaming
bevy_eventlistener
, a reactive programming solution used to dispatch and bubble events up hierarchies that is used bybevy_mod_picking
.bevy_event_dispatch
by @viridia has won the bikeshed contestbevy_mod_picking
to the new version ofbevy_event_listener
bevy_mod_picking
's components into a newbevy_picking
cratebevy_mod_picking
Interaction
bevy_event_dispatch
bevy_picking
Ideas for breaking improvements
bevy_event_dispatch
over to observers (Generalised ECS reactivity with Observers #10839) to enable endlessly loopable reactivity as discussed hereRelated work
ui_focus_system
#4264The text was updated successfully, but these errors were encountered: