-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Next Generation Bevy Scenes #20158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: release-0.17.2
Are you sure you want to change the base?
Next Generation Bevy Scenes #20158
Changes from all commits
d5882d4
ab73319
e4a6170
fbae074
22a2731
40e6f12
62e3c6e
8ee8f16
a34bb51
7117b03
696f4a2
ecab5a1
0c78073
4940d1c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -147,6 +147,7 @@ default = [ | |
"bevy_picking", | ||
"bevy_render", | ||
"bevy_scene", | ||
"bevy_scene2", | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @3xau1o I'm converting your top level comment to a thread (please read the PR description)
BSN does not currently support reactivity (please read the PR description). There have been many investigations into both fine grained and coarse reactive solutions (both diff-ing and signal-based) / we are well versed in the space at this point. The goal for this phase is to (if possible) build BSN in such a way that it can support both paradigms. Then we can iterate / have an ecosystem (potentially even cross-compatible) where ideas can compete. From there if a winner arises, we can bless it as the "go-to" / default solution. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can confirm there's multiple people in the community who I know are planning to experiment with different approaches. I'm looking forward to building a coarse-grained diffing system, and I'll bet @viridia will build a fine-grained solution. I'm really pleased with this reactivity-agnostic approach, let's us avoid a big bikeshed and do more incremental exploratory work. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On one hand:
On the other hand:
Can a diff-based system be the foundation of an efficient implementation of fine-grained reactivity? The suggestion seems to be that this is supposed to be a neutral foundation, but I'd argue that it is not. You can't build a (true) reactive system on top of a diff-based system without many compromises. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think you may be confusing two different things: Inheritance and reactivity. Patches are just for inheritance. Personally, I don't see how they relate to reactivity (or incrementalization) at all. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @NthTensor Uhh... Gotcha. They're more like layers then, right? Maybe the confusing "patch" terminology could be avoided. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
this is only possible if BSN is only a DSL syntax like JSX which is used in both Reactjs and Solidjs there is also the need to realize that
they're so different, mostly opposite, that's why Vue.js vapor was mostly a rewrite instead of an upgrade from Vue.js 3 vdom, Vue Vapor and Vue3 are not compatible, they only use the same vue syntax, same as React and Solidjs use JSX There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I think you might be mixing up unrelated things. The compilation you're speaking of in e.g. SolidJS is compiling away the framework into plain JS functions. This has no relevance to the Bevy / Rust case... There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. i think you are missing the point, which is that signals allow update effects to be known as a directed graph, that's why brute diffing like React does it's unrequired, instead fields are simply directly updated when deps change without recomposing the tree There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I view BSN as being a DSL like JSX. We're all familiar with how signals work, there's about five to ten different implementations for bevy already (and five to ten diffing incrementalism implementations). Both will be possible using BSN, and in fact people in the bevy discord have already demonstrated some prototypes of signal-like systems using this PR. |
||
"bevy_image", | ||
"bevy_mesh", | ||
"bevy_camera", | ||
|
@@ -178,6 +179,7 @@ default = [ | |
"wayland", | ||
"debug", | ||
"zstd_rust", | ||
"experimental_bevy_feathers", | ||
] | ||
|
||
# Recommended defaults for no_std applications | ||
|
@@ -240,6 +242,9 @@ bevy_render = ["bevy_internal/bevy_render"] | |
# Provides scene functionality | ||
bevy_scene = ["bevy_internal/bevy_scene"] | ||
|
||
# Provides scene functionality | ||
bevy_scene2 = ["bevy_internal/bevy_scene2", "bevy_asset"] | ||
|
||
# Provides raytraced lighting (experimental) | ||
bevy_solari = ["bevy_internal/bevy_solari"] | ||
|
||
|
@@ -612,6 +617,7 @@ bevy_image = { path = "crates/bevy_image", version = "0.17.1", default-features | |
bevy_reflect = { path = "crates/bevy_reflect", version = "0.17.1", default-features = false } | ||
bevy_render = { path = "crates/bevy_render", version = "0.17.1", default-features = false } | ||
bevy_state = { path = "crates/bevy_state", version = "0.17.1", default-features = false } | ||
bevy_scene2 = { path = "crates/bevy_scene2", version = "0.17.1", default-features = false } | ||
# Needed to poll Task examples | ||
futures-lite = "2.0.1" | ||
futures-timer = { version = "3", features = ["wasm-bindgen", "gloo-timers"] } | ||
|
@@ -622,6 +628,7 @@ event-listener = "5.3.0" | |
anyhow = "1" | ||
accesskit = "0.21" | ||
nonmax = "0.5" | ||
variadics_please = "1" | ||
|
||
[target.'cfg(not(target_family = "wasm"))'.dev-dependencies] | ||
ureq = { version = "3.0.8", features = ["json"] } | ||
|
@@ -2824,6 +2831,14 @@ description = "Demonstrates loading from and saving scenes to files" | |
category = "Scene" | ||
wasm = false | ||
|
||
[[example]] | ||
name = "bsn" | ||
path = "examples/scene/bsn.rs" | ||
|
||
[[example]] | ||
name = "ui_scene" | ||
path = "examples/scene/ui_scene.rs" | ||
|
||
# Shaders | ||
[[package.metadata.example_category]] | ||
name = "Shaders" | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ValorZard I'm converting your top-level comment into a thread (please see the PR description):
The idea is that
.bsn
will be the subset ofbsn!
that can be represented in a static file. In the immediate short term, that will not include things like theon
function, as we cannot include arbitrary Rust code in asset files.The primary goal of
.bsn
will be to represent static component values editable in the visual Bevy Editor. In the future we might be able to support more dynamic / script-like scenarios. But that is unlikely to happen in the short term.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Drat. I thought I did the comment thing correctly.
but otherwise that makes sense. So .bsn and bsn! Aren’t fully equivalent. Interesting.
I guess Bevy could support something like Godot’s callables in the future maybe, and have some sort of id sorted in the .bsn file that could be converted to a function? Idk
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, function reflection + a registry should make stringly-typed callbacks defined in assets very feasible.