Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Fair enough, thanks. I don't think there's a pressing/mainstream ask that justifies the maintenance burden that I imagine this would cause. I've seen people mentioning sparingly that they'd like to use Bevy for Xbox and Playstation development. Another cool use case was to use Bevy with crankstart to develop games for the Playdate with Rust. Again, probably not sufficient demand beyond curiosity or a hobby.
I suppose this is already being discussed within the community and they're capturing the same concern you're bringing up: https://github.com/bevyengine/bevy/pull/6581
* I've left this for last, but the explicit binding model sucks. WebGPU is fairly high level, but keeping explicit binding instead of requiring binding arrays is awful. Every time you want to add a texture/buffer/etc to your shader, you need to modify the bind group layout, modify the bind group, and then modify the shader, and keep those definitions in sync. When you have multiple pipelines, bind groups, shaders, and modular systems that only need certain resources under different conditions or certain parts of different shaders, it's just awful to keep track of. The ergonomics are terrible. I wish WebGPU would've required binding arrays and just accepted losing support for some older devices. In Bevy we plan to write an abstraction that acts more like binding arrays and falls back to explicit bindings where needed, but that's still a lot of work.
Overall, I generally think wgpu was/is the right choice for Bevy. The ergonomics could still use work, we leave performance on the table, we don't get all the advanced and new features, and the growing pains were (and still are, to a lesser degree) real. But we still get better ergonomics compared to other options, WebGPU support for browsers, 1 rendering backend vs at least 3 (Vulkan/Metal/WebGL2), and the rest of the issues are fixable over time and with more work done on both Bevy's side and the library and tooling side.
Sometimes I wish we went with just Vulkan+Metal and could drop down to lower level stuff, get access to new features, and just generally not have to deal with extra layers and immature tooling. But I still think it's the right choice for the project overall. Discalimer: just my own opinion, I don't represent the project.
> Also, have you thought of teaming up with anyone who is explicitly teaching webgpu / wgsl? Seeing someone create a rust perspective course on learning webgpu could be nice.
Learn wgpu (https://sotrh.github.io/learn-wgpu) provides a nice intro to WebGPU/WGSL. I don't think there's really anything Bevy specifically would be able to provide. Once you wrap your head around the APIs themselves, generally the hard part of graphics programming is dealing with the boilerplate, and the actual 3D rendering techniques themselves irrespective of the API you write in.
That said, there's a few improvements I've though about contributing to learn wgpu to cover the more advanced side of things (compute shaders, storage resources, alignment rules, etc), but I haven't had time lately.
Intriguing development! It's quite refreshing to witness Bevy hopping onto the WebGPU bandwagon. I can't help but wonder about the complexity involved in transitioning an existing codebase from WebGL to WebGPU in such a compressed timeline.
On a similar note, Ambient (https://github.com/AmbientRun/Ambient) has been on my radar for their utilization of WebGPU, though they seemingly lack a tangible web demo. Anyone have any insights or comparisons to share?
When do think bevy will support entity-entity relationships ? https://github.com/bevyengine/bevy/issues/3742.
Flecs ECS already supports this: https://github.com/SanderMertens/flecs/blob/master/docs/Rela...
Thank you! I just started with bevy this week, and it's a bit overwhelming, but in a weird and mostly good way. The way components and systems work is fucking magic, the kind of stuff you'd expect of Rails or Django, but not in a real-time framework in a systems programming language.
The good is that whole applications can be written in just a handful of mostly declarative code, which is absolutely amazing! The bad is that with all the magic being handled by macros and back-end event processing loops, it can be a little intimidating and how to see how it is constructed under the hood. I would love to see a class diagram showing both the extant objects and their types, and the control flow during a frame update.
But anyway, thank you for all your hard work and for the response. Now I know where to go first in the source code to do what I need to do.
> If you want to build a wgpu-based renderer, you have a couple of options depending on what kind of rendering you need. You can plug in your own custom renderer instead of bevy_pbr using bevy_core_pipeline. You can still use bevy_pbr and just add your own render nodes on top of it.
I actually have my own wgpu-based renderer done (https://github.com/atomCAD/atomCAD/), so maybe that's the first thing to try. Thanks!
> I encourage you to join Bevy's discord channel and discuss your project in the #rendering channel, it's much easier to provide help and give info than over a forum.
Will do.