5 ms·

Bevy's creator and project lead here. Feel free to ask me anything!

by _cart 3y ago

Jamustico 3y ago
What did you have for lunch
- _cart 3y ago
  Haven't eaten yet, but I'm planning on having a lentil / beef / mushroom curry I made earlier.
  - stefanos82 3y ago
    That sounds delicious! Recipe please ^_^ !
    - _cart 3y ago
      Pretty straightforward process / I just made it up. Throw some olive oil in an Instant Pot, add beef and sear (no need to fully cook, just brown it), add ~4 cups of water and ~2 cups of lentils (I eyeball these), throw in chopped onions / bell peppers / mushrooms / garlic, add spices (plenty of turmeric + generic store bought "curry powder", garlic powder, dill, cayenne pepper, salt), and the secret ingredient: ~1/2 cup of smooth peanut butter (trust me this is very important ... when in doubt add more). (edit: I keep the Saute setting on while im adding ingredients and occasionally stir. Then I seal it up, turn on the "bean chill" mode on high. And wait 40 minutes for tasty goodness)
      - stefanos82 3y ago
        Sounds delicious! Thank you so much!
hasty_pudding 3y ago
This looks like a really cool project! Is it portable to Browser? Or is that on the roadmap?
- _cart 3y ago
  Yup we support both WebGL and WebGPU browser deployments via WASM
  - hasty_pudding 3y ago
    Glorious. This is exciting. Looking forward to seeing youalls progress
iknowstuff 3y ago
I gotta ask newbie questions. Any concrete plans for a GUI editor? Does stuff like Lumen/Nanite from UE5 have any chance of existing in Bevy?
- james7132 3y ago
  The blog post directly mentions efforts towards a GUI-based editor in the "What's next" section. We can definitely deliver on global illumination in some way, as shown with the irradiance volume support added in this release, though it may not match Lumen 1:1. Nanite is definitely more involved, but worth investigating.
  - jms55 3y ago
    Just to clarify, irradiance volumes (and other forms of GI added this release like lightmaps and reflection probes) are statically baked ahead of time, meaning they'll start showing incorrect lighting as you move objects and light sources around. They take time to bake (slowing down development iteration), and limit how much you can do with them / need careful usage and placement, but are widely supported, and give great results for very cheap runtime costs. Lumen is a fully _dynamic_ GI system. No slow offline baking, and much more flexible (and therefore realistic) lighting, especially reflections. The downside is it's much, much slower (but still barely fast enough to be realtime 60fps), and requires a semi-recent graphics card that support hardware-accelerated raytracing. As for whether meshlets or realtime dynamic GI is harder, well, I'd probably lean towards GI right now. I haven't yet started the (very complex) LOD building system for meshlets though, so maybe I'll change my mind in the future :)
- pcwalton 3y ago
  Here are the plans for the editor prototypes: https://github.com/bevyengine/bevy_editor_prototypes/discussions/1 https://github.com/bevyengine/bevy_editor_prototypes/discuss... As far as Lumen goes, there are a few experimental early-stage projects that add real-time global illumination to Bevy, such as bevy-solari [1]. Most of them rely on hardware raytracing support, as this simplifies a lot of things, and the new baked GI stuff that just shipped in 0.13 is fine for non-RTX. Besides, there's a good chance that hardware raytracing support will be very commonplace by the time any of this reaches production quality. For Nanite, the closest thing that's being actively worked on is meshlets [2]. These actually are pretty close to ready and likely to land in 0.14 (no guarantees of course). These provide some, but not all, of the benefits of Nanite. LOD features can potentially be layered on top of meshlets in the future to provide a solution to roughly the same set of problems that Nanite solves, with some advantages relative to Nanite and some disadvantages. [1]: https://github.com/jms55/bevy/tree/solari https://github.com/jms55/bevy/tree/solari [2]: https://github.com/bevyengine/bevy/pull/10164 https://github.com/bevyengine/bevy/pull/10164
mochathoughts 3y ago
In two / three years, where do you see the project?
- _cart 3y ago
  Core pillars (including WIP things like Scene, UI, Editor, Audio) are in place. Partial or full engine stability (see my "partial stabilization discussion: https://github.com/bevyengine/bevy/discussions/9789 https://github.com/bevyengine/bevy/discussions/9789). More than a few fully released quality games. More than a few fully released quality non-games / tools (we're already seeing Bevy being used as a foundation for things like CAD software and modeling tools).
mattcanhack 3y ago
No question, just want to say thanks! I've had a lot of false starts trying game tutorials but the ones I found for Bevy were really easy to follow. I was working two versions behind and the changelog for Bevy was so well done that I was able to figure out most of what changed. Bevy was also just straightforward to use.
gaganyaan 3y ago
Are there any good "end to end" examples that show things like a splash screen, main menu, pause menu, video settings, that sort of thing?
- _cart 3y ago
  We don't have a "complete" official example of those things, although the "game menu" example has some of that: https://github.com/bevyengine/bevy/blob/main/examples/games/game_menu.rs https://github.com/bevyengine/bevy/blob/main/examples/games/... I recommend checking out Bevy Jam games (which are pretty much always open source) for more complete / real world examples: https://itch.io/jam/bevy-jam-4 https://itch.io/jam/bevy-jam-4 Definitely a bit of a gap in our official learning material. Hopefully we can close it soon!
CrimsonCape 3y ago
Any idea why the example image in the OP link appears to be running at sub-optimal framerate? What is the expected ECS overhead per frame (not including graphics interaction, i.e. code specifically in the ECS model)? Since an ECS is typically a flattened scene graph, is there still a game loop? Wouldn't be necessary, correct? You only need to respond to the inputs...
- _cart 3y ago
  That is a size-optimized webp / gif that isn't running at 60 fps. The game is butter smooth in practice: https://twitter.com/jarl_game https://twitter.com/jarl_game
- _cart 3y ago
  I would say that the systems in the ECS _are_ the game loop. The ECS overhead per frame is kind of hard to measure / it depends on the scale of usage. To establish the scale of operations: Random single-entity ECS data accesses are a sparse array lookup to find the table the entity is in, and then an array lookup to find the component in the table. Iterating components in a query is roughly the same as iterating an array / is very cache friendly. Running individual systems is _slightly_ more expensive than a function call. Scheduling systems in parallel does introduce some overhead (which is currently higher than we'd like / we're working on optimizing it), but when you pay that cost you get the benefits of everything running in parallel.
- james7132 3y ago
  There is still a game loop that runs every tick. The engine wouldn't work so well if we only responded to inputs as they come in, event pub-sub style. As for ECS overhead, I've made it one of my top priorities to eliminate it wherever possible since it underpins the entire engine. We're at the point where most optimizations are saving a few tens or low-hundreds of microseconds per frame in your average game/app (i.e. lowering context switch costs from parallel system execution). If you're pushing below 60 FPS in your app, chances are the performance issues are not coming from the ECS, but some other part of the engine, or the app's own code.
- SkiFire13 3y ago
mrec 3y ago
> The built-in collection of primitives is already quite sizeable And yet no teapot! Literally unusable.
vacuity 3y ago
I can't help but feel that between events and commands, and especially with all the parallelism, there's no clean, powerful solution to manage all manner of inter-system interactions. Having .before(), .after(), .chain(), different schedules and whatnot is great, but I think there's something lacking in the model to round it all out. Granted, I'm a novice in these matters and I understand that concurrency brings many hard problems. Could you spare your thoughts on the matter? Thanks!

Bevy's creator and project lead here. Feel free to ask me anything!

by _cart 3y ago

Bevy's creator and project lead here. Feel free to ask me anything!

Jamustico 3y ago

What did you have for lunch

_cart 3y ago
Haven't eaten yet, but I'm planning on having a lentil / beef / mushroom curry I made earlier.
- stefanos82 3y ago
  That sounds delicious! Recipe please ^_^ !
  - _cart 3y ago
    Pretty straightforward process / I just made it up. Throw some olive oil in an Instant Pot, add beef and sear (no need to fully cook, just brown it), add ~4 cups of water and ~2 cups of lentils (I eyeball these), throw in chopped onions / bell peppers / mushrooms / garlic, add spices (plenty of turmeric + generic store bought "curry powder", garlic powder, dill, cayenne pepper, salt), and the secret ingredient: ~1/2 cup of smooth peanut butter (trust me this is very important ... when in doubt add more). (edit: I keep the Saute setting on while im adding ingredients and occasionally stir. Then I seal it up, turn on the "bean chill" mode on high. And wait 40 minutes for tasty goodness)
    - stefanos82 3y ago
      Sounds delicious! Thank you so much!

hasty_pudding 3y ago

This looks like a really cool project! Is it portable to Browser? Or is that on the roadmap?

_cart 3y ago
Yup we support both WebGL and WebGPU browser deployments via WASM
- hasty_pudding 3y ago
  Glorious. This is exciting. Looking forward to seeing youalls progress

iknowstuff 3y ago

I gotta ask newbie questions. Any concrete plans for a GUI editor? Does stuff like Lumen/Nanite from UE5 have any chance of existing in Bevy?

james7132 3y ago
The blog post directly mentions efforts towards a GUI-based editor in the "What's next" section. We can definitely deliver on global illumination in some way, as shown with the irradiance volume support added in this release, though it may not match Lumen 1:1. Nanite is definitely more involved, but worth investigating.
- jms55 3y ago
  Just to clarify, irradiance volumes (and other forms of GI added this release like lightmaps and reflection probes) are statically baked ahead of time, meaning they'll start showing incorrect lighting as you move objects and light sources around. They take time to bake (slowing down development iteration), and limit how much you can do with them / need careful usage and placement, but are widely supported, and give great results for very cheap runtime costs. Lumen is a fully _dynamic_ GI system. No slow offline baking, and much more flexible (and therefore realistic) lighting, especially reflections. The downside is it's much, much slower (but still barely fast enough to be realtime 60fps), and requires a semi-recent graphics card that support hardware-accelerated raytracing. As for whether meshlets or realtime dynamic GI is harder, well, I'd probably lean towards GI right now. I haven't yet started the (very complex) LOD building system for meshlets though, so maybe I'll change my mind in the future :)
pcwalton 3y ago
Here are the plans for the editor prototypes: https://github.com/bevyengine/bevy_editor_prototypes/discussions/1 https://github.com/bevyengine/bevy_editor_prototypes/discuss... As far as Lumen goes, there are a few experimental early-stage projects that add real-time global illumination to Bevy, such as bevy-solari [1]. Most of them rely on hardware raytracing support, as this simplifies a lot of things, and the new baked GI stuff that just shipped in 0.13 is fine for non-RTX. Besides, there's a good chance that hardware raytracing support will be very commonplace by the time any of this reaches production quality. For Nanite, the closest thing that's being actively worked on is meshlets [2]. These actually are pretty close to ready and likely to land in 0.14 (no guarantees of course). These provide some, but not all, of the benefits of Nanite. LOD features can potentially be layered on top of meshlets in the future to provide a solution to roughly the same set of problems that Nanite solves, with some advantages relative to Nanite and some disadvantages. [1]: https://github.com/jms55/bevy/tree/solari https://github.com/jms55/bevy/tree/solari [2]: https://github.com/bevyengine/bevy/pull/10164 https://github.com/bevyengine/bevy/pull/10164

mochathoughts 3y ago

In two / three years, where do you see the project?

_cart 3y ago
Core pillars (including WIP things like Scene, UI, Editor, Audio) are in place. Partial or full engine stability (see my "partial stabilization discussion: https://github.com/bevyengine/bevy/discussions/9789 https://github.com/bevyengine/bevy/discussions/9789). More than a few fully released quality games. More than a few fully released quality non-games / tools (we're already seeing Bevy being used as a foundation for things like CAD software and modeling tools).

mattcanhack 3y ago

No question, just want to say thanks! I've had a lot of false starts trying game tutorials but the ones I found for Bevy were really easy to follow. I was working two versions behind and the changelog for Bevy was so well done that I was able to figure out most of what changed. Bevy was also just straightforward to use.

gaganyaan 3y ago

Are there any good "end to end" examples that show things like a splash screen, main menu, pause menu, video settings, that sort of thing?

_cart 3y ago
We don't have a "complete" official example of those things, although the "game menu" example has some of that: https://github.com/bevyengine/bevy/blob/main/examples/games/game_menu.rs https://github.com/bevyengine/bevy/blob/main/examples/games/... I recommend checking out Bevy Jam games (which are pretty much always open source) for more complete / real world examples: https://itch.io/jam/bevy-jam-4 https://itch.io/jam/bevy-jam-4 Definitely a bit of a gap in our official learning material. Hopefully we can close it soon!

CrimsonCape 3y ago

Any idea why the example image in the OP link appears to be running at sub-optimal framerate? What is the expected ECS overhead per frame (not including graphics interaction, i.e. code specifically in the ECS model)? Since an ECS is typically a flattened scene graph, is there still a game loop? Wouldn't be necessary, correct? You only need to respond to the inputs...

_cart 3y ago
That is a size-optimized webp / gif that isn't running at 60 fps. The game is butter smooth in practice: https://twitter.com/jarl_game https://twitter.com/jarl_game
_cart 3y ago
I would say that the systems in the ECS _are_ the game loop. The ECS overhead per frame is kind of hard to measure / it depends on the scale of usage. To establish the scale of operations: Random single-entity ECS data accesses are a sparse array lookup to find the table the entity is in, and then an array lookup to find the component in the table. Iterating components in a query is roughly the same as iterating an array / is very cache friendly. Running individual systems is _slightly_ more expensive than a function call. Scheduling systems in parallel does introduce some overhead (which is currently higher than we'd like / we're working on optimizing it), but when you pay that cost you get the benefits of everything running in parallel.
james7132 3y ago
There is still a game loop that runs every tick. The engine wouldn't work so well if we only responded to inputs as they come in, event pub-sub style. As for ECS overhead, I've made it one of my top priorities to eliminate it wherever possible since it underpins the entire engine. We're at the point where most optimizations are saving a few tens or low-hundreds of microseconds per frame in your average game/app (i.e. lowering context switch costs from parallel system execution). If you're pushing below 60 FPS in your app, chances are the performance issues are not coming from the ECS, but some other part of the engine, or the app's own code.
SkiFire13 3y ago

mrec 3y ago

> The built-in collection of primitives is already quite sizeable And yet no teapot! Literally unusable.

vacuity 3y ago

I can't help but feel that between events and commands, and especially with all the parallelism, there's no clean, powerful solution to manage all manner of inter-system interactions. Having .before(), .after(), .chain(), different schedules and whatnot is great, but I think there's something lacking in the model to round it all out. Granted, I'm a novice in these matters and I understand that concurrency brings many hard problems. Could you spare your thoughts on the matter? Thanks!