6 ms·

Why does it seem like bevy has produced far less spectacular results then much newer c++ engines with a fraction of the dev team? Cherno’s engine also comes to

Why does it seem like bevy has produced far less spectacular results then much newer c++ engines with a fraction of the dev team? Cherno’s engine also comes to mind.

capableweb 4y ago
Bevy spend time on more things than just graphics, it's just one part of the framework and engine. The ECS system is vast too, probably a lot of time went into it
widdershins 4y ago
I think bevy is a much more ambitious 'total' framework for making games. Plus, I think by its nature Rust forces you to deal with the really hard questions up front, and get them right first time. In C++ you can punt some of these questions and build a less-than-perfect architecture more quickly. Please don't think I'm disparaging C++, I develop in it for my day job. But I do think there are different trade-offs at different stages of a project's lifetime.
- deleted 4y ago
  [deleted]
elabajaba 4y ago
Bevy has 2 core graphics maintainers, but they're both volunteers with extremely limited time, so there's definitely issues where your submit a PR and have to wait months for it to get reviewed. They've also been working on patching up the core infrastructure of Bevy's renderer (fixing the shader import model, reworking the CPU side to enable batching and preparing for bindless, which are both huge optimizations). WGPU (the low level graphics library that wraps the individual APIs) also has issues with excessive locking of resources, so multithreading draw calls wasn't any faster than single threaded (A core part of Vulkan and DX12 performance is multithreading draw calls), but that should hopefully be fixed in the next few months. In terms of the more "pretty graphics" side, cascaded shadow maps were implemented for distance shadow rendering, there's 95% ready PRs for SSAO (based on GTAO) and PCF (soft shadows), and TAA just got merged. Finally, there's the desire to support all platforms, meaning there's a 10ton weight shackled to the renderer called WebGL 2, which doesn't even support compute shaders (which are the cornerstone of pretty much every new graphics feature from the past decade).
hotpathdev 4y ago
The simple truth is that a single talented, unencumbered (ie, as repo owner you're less encumbered by PR etiquette and feature direction), motivated developer in open source software, especially from what I've seen in the game-engine/framework space where multiple disciplines come into play, is far more effective than a large group of contributors will ever be as far as pushing large new features is concerned. When it comes to picking a smaller open source game engine, it becomes essential to evaluate the hero developers involved: how committed are they to the project? is their effort sustainable ? I think Bevy will work out long-term, because they have structured as a sustainable foundation with solid project management, however the lack of a hero dev that who can contribute to all the sub-crates [1] within the bevy ecosystem also means you have odd quirks in Bevy that will remain longstanding on the issue tracker, like for example setting the texture wrapping mode. For that reason, Fyrox is worth serious consideration if you're constraining to the rust ecosystem of game engines/frameworks. Just one developer, but he's got the old-school experience and dedication, and the framework looks/feels much more familiar to a C++ game developer. It's not the sophisticated beast that Bevy is, but that's a good thing to the kind of person who would even consider these game engines/frameworks in the first place. What really saddens me is that these hero game devs are still choosing C++ instead of rust. There are so many great flash-in-the-pan game engine/frameworks in C++, but they will never take off for a number of reasons. When you look at how game devs approach development in C++, you come to realise that Rust is the language we wanted all along. [1] https://github.com/bevyengine/bevy/tree/main/crates https://github.com/bevyengine/bevy/tree/main/crates

Why does it seem like bevy has produced far less spectacular results then much newer c++ engines with a fraction of the dev team? Cherno’s engine also comes to mind.

capableweb 4y ago

Bevy spend time on more things than just graphics, it's just one part of the framework and engine. The ECS system is vast too, probably a lot of time went into it

widdershins 4y ago

I think bevy is a much more ambitious 'total' framework for making games. Plus, I think by its nature Rust forces you to deal with the really hard questions up front, and get them right first time. In C++ you can punt some of these questions and build a less-than-perfect architecture more quickly. Please don't think I'm disparaging C++, I develop in it for my day job. But I do think there are different trade-offs at different stages of a project's lifetime.

deleted 4y ago
[deleted]

elabajaba 4y ago

Bevy has 2 core graphics maintainers, but they're both volunteers with extremely limited time, so there's definitely issues where your submit a PR and have to wait months for it to get reviewed. They've also been working on patching up the core infrastructure of Bevy's renderer (fixing the shader import model, reworking the CPU side to enable batching and preparing for bindless, which are both huge optimizations). WGPU (the low level graphics library that wraps the individual APIs) also has issues with excessive locking of resources, so multithreading draw calls wasn't any faster than single threaded (A core part of Vulkan and DX12 performance is multithreading draw calls), but that should hopefully be fixed in the next few months. In terms of the more "pretty graphics" side, cascaded shadow maps were implemented for distance shadow rendering, there's 95% ready PRs for SSAO (based on GTAO) and PCF (soft shadows), and TAA just got merged. Finally, there's the desire to support all platforms, meaning there's a 10ton weight shackled to the renderer called WebGL 2, which doesn't even support compute shaders (which are the cornerstone of pretty much every new graphics feature from the past decade).

hotpathdev 4y ago

The simple truth is that a single talented, unencumbered (ie, as repo owner you're less encumbered by PR etiquette and feature direction), motivated developer in open source software, especially from what I've seen in the game-engine/framework space where multiple disciplines come into play, is far more effective than a large group of contributors will ever be as far as pushing large new features is concerned. When it comes to picking a smaller open source game engine, it becomes essential to evaluate the hero developers involved: how committed are they to the project? is their effort sustainable ? I think Bevy will work out long-term, because they have structured as a sustainable foundation with solid project management, however the lack of a hero dev that who can contribute to all the sub-crates [1] within the bevy ecosystem also means you have odd quirks in Bevy that will remain longstanding on the issue tracker, like for example setting the texture wrapping mode. For that reason, Fyrox is worth serious consideration if you're constraining to the rust ecosystem of game engines/frameworks. Just one developer, but he's got the old-school experience and dedication, and the framework looks/feels much more familiar to a C++ game developer. It's not the sophisticated beast that Bevy is, but that's a good thing to the kind of person who would even consider these game engines/frameworks in the first place. What really saddens me is that these hero game devs are still choosing C++ instead of rust. There are so many great flash-in-the-pan game engine/frameworks in C++, but they will never take off for a number of reasons. When you look at how game devs approach development in C++, you come to realise that Rust is the language we wanted all along. [1] https://github.com/bevyengine/bevy/tree/main/crates https://github.com/bevyengine/bevy/tree/main/crates