What are the current plans/aims of the deferred renderer? I seem to recall coming across a GitHub issue in the past (but can't find it now) that mentioned that this wouldn't be an aim of bevy for the foreseeable future. What changed?

This essentially came down to: 1. We've started blurring the lines by having optional depth and normal prepasses (to enable new rendering features) 2. We have renderer devs that are currently experimenting in this space

Whether or not (and how) we embrace deferred will come down to the user experience, effects on the render plugin ecosystem, desired features, perf characteristics, etc. The decision hasn't been fully made yet, but we're going to explore the space.

The latest discussion has happened here: https://discord.com/channels/691052431525675048/111316658507...

I love Bevy, but I feel like it's still more of a Game Development Library rather than an engine. Godot, on the other hand, looks very nice in terms of user experience: great editor and very easy to understand and use. Will Bevy implement a first-party editor, overhaul of game development experience etc or is the goal to only support these things with third-party plugins and crates?

Building an editor is one of our highest priorities. We've been laying the groundwork for this for awhile and we would like to have tangible progress here within the year. We can't commit to specific dates, but know that a full editor experience is a central part of our plan. Code-only will always be an option, but we firmly believe that visual editing is a critical piece of the gamedev puzzle.

A first-party editor is planned and Bevy's UI library and other infrastructure is getting to the point where it might to start to materialise in a few releases. However, I personally love the code-first experience Bevy offers in comparison to something like Godot.

Definitely agree. The UI workflow is godot doesn’t feel good. Bevy does feel boilerplatey, but it’s so much more intuitive imo.

Large amount of work done again! When you get to the ui work in the what’s next part, do you plan to integrate one of the existing bevy ui crates? Or will you learn from them and build a new one? Really looking forward to getting some progress in that area. I feel like contributing (made the PR for swapping Y axis on UI for 0.9) but the status quo is a huge mental block to even get started. Again, awesome project!

This cycle getting UI ready for the editor is my primary focus. I'll be considering all of our options (improvements to the existing system or embracing one of the many community Bevy UI plugins). I can't give much more clarity than that until I've committed more time to the space. But this is next on my plate (right after getting Bevy Asset V2 finalized and merged)

Cool, thanks for your answer! Looking forward to it, and take your time.

I sometimes wonder if the data transformations found in ECS Systems could be constructed through a visual editor. An analogue might be Unity's Shader Graph, where a developer with a less technical background can program a GPU's SIMD architecture.

Do you think that sort of thing could ever be feasible in Bevy?

This is definitely feasible in Bevy (either via Rust codegen, "interpreter-style" node execution, or scripting). And will be even more feasible once we have an official visual Bevy Editor. However I'm pretty skeptical of "visual / node based programming" and I wouldn't personally prioritize that work when we have so many other things to do. That being said, I'm guessing someone will eventually build a 3rd party plugin to do this.

Unreal's Niagara has a visual editor. While it is packaged as an VFX/particle editor, it is in many ways an ECS. Each particle can have custom data structure and modules/systems that drive them. Under the hood the graphs are translated to SIMD-optimized VM bytecode when run on CPU. It can even support translation to HLSL/GPU-acceleration if all modules support it. Not sure if Unity has something similar.

What are your favourite games currently published that are built using Bevy? Any available on Steam?

Molecoole is a fun one on Steam: https://store.steampowered.com/app/1792170/Molecoole/

We're still in the early days of the engine so most games are pretty small in scope. But there are still plenty of fun ones! Lots of games on itch.io: https://itch.io/games/tag-bevy

I'm very excited for Tiny Glade: https://store.steampowered.com/app/2198150/Tiny_Glade. They only use some parts of Bevy (Bevy ECS and Bevy App. They built their own custom renderer).

xyzw is building a beautiful Dwarf Fortress-like: https://twitter.com/xyzw_io/status/1677340923292786689

What're your plans regarding OpenGL support? Is that something you care about or not at all?

The current state being that wgpu supports it, and as such we can already use it in bevy by setting the wgpu back-end env variable, but in bevy it only works for 2D stuff (trying the 3D examples of bevy lead to a Naga error because, IIRC the PBR stuff uses features that cannot work in OpenGL or something like that).

(If you tell me that OpenGL is something you want to support and it's just an oversight, I can file an issue on github with much more details, and would even be willing to contribute)

It is something we care about, but it also isn't our first priority (as it is a "fallback" backend when other newer apis aren't available on a system). Given that we support WebGL (which IS a high priority for us and is an even more limited subset), generally OpenGL breakage is just an oversight / missed bug. Please file an issue as we do want to support as many systems as possible!

While OpenGL support isn't a main target, the fact that it breaks with 3D is unexpected. Many features won't work but it should definitely be able to render the pbr shader in 3d.

Just want to say I’ve had the opportunity to use bevy a fair amount and it’s such a fun experience. I really appreciate the time, effort, and attention to developer experience. I’ve also seen how much the team helps others in the discord etc. Keep up the great work.