-
We're pretty close to supporting it out of the box. Basically we just need to merge this pr and then adapt one of the existing skeletal animation proposals. I've implemented skeletal animation in previous engines, so there aren't really any unknowns here. Baseline skeletal animation is very simple to implement (and we're prioritizing getting something simple merged asap). After that, we'll develop a more holistic property based animation system, which will take a lot more time + R&D.
-
CodeRabbit
CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
-
You can check out my in-progress RFC for dynamic queries here. It has been frozen for a while after my first draft as my professional workload has increased, but I plan on doing a more thorough second pass soon™. Take a look, any thoughts would be appreciated.
-
Could you make a PR to https://github.com/bevyengine/bevy-website so we can clean up this misleading statement?
-
The integration mentioned here can be found at https://github.com/Seabass247/bevy-kajiya
-
awesome-bevy
A collection of Bevy assets, plugins, learning resources, and apps made by the community
This is to be expected at this point. Bevy is just over a year old. We don't make any stability guarantees (and actively warn against using Bevy in serious projects unless they are willing to get their hands dirty). Godot has been in development since 2007. Unity was released in 2005. In many ways, I consider us to be "ahead of schedule". By the end of the year, I expect Bevy to be much "stabler" with a more complete feature set. As the year progresses, I think we will see an uptick in "more serious projects". That being said, there are already plenty of interesting projects on itch.io and Bevy Assets.
-
I know nothing about game engines/programming/design, but I have recently read about https://github.com/EmbarkStudios/kajiya and wondered if bevy could benefit from it?
-
If you've seen the Diataxis documentation model, I would argue that the official book will be solidly focused on Explanation, while the Cheatbook straddles Explanation and How-To-Guides. The docs.rs doc comments are the reference quadrant, and then tutorials will be filled with the new tutorials and the existing excellent community tutorials.
-
InfluxDB
InfluxDB high-performance time series database. Collect, organize, and act on massive volumes of high-resolution data to power real-time intelligent systems.
-
For a GUI, you might consider egui which has an integration for bevy.
-
bevy_egui
This crate provides an Egui integration for the Bevy game engine. 🇺🇦 Please support the Ukrainian army: https://savelife.in.ua/en/
For a GUI, you might consider egui which has an integration for bevy.
-
Regarding rollback networking, there is bevy_ggrs, which I think works really well.
-
In theory, it should also be possible to support browser-native crossplay that way. I did some work on supporting that, but I'm currently stuck on an issue with webrtc-rs.
-
I haven't actually got to the point of trying to implement it in my fighting game engine but Backroll rs is a rust implementation of GGPO https://github.com/HouraiTeahouse/backroll-rs
-
I've seen PsichiX experimenting with this in RAUI! I'd start there :)
-
There's a few critical subtasks here: - determine the data flow model we'd like to use for our UI. We'd like to integrate tightly into the ECS, but need to figure out how to reduce the boilerplate and improve reliability around working with hierarchies. - swap our layout library. Our current dependency stretch implements the flexbox algorithm, but is unmaintained and has critical bugs :( The three main options here are to fork flex, move to the new morphorm crate, or write a layout library from scratch - consider rearchitecting our UI to be more flexible and compositional: splitting the massive Style component into several parts and moving to a "UI is a collection of behaviors" paradigm - build out more widgets! - more docs and examples!
-
There's a few critical subtasks here: - determine the data flow model we'd like to use for our UI. We'd like to integrate tightly into the ECS, but need to figure out how to reduce the boilerplate and improve reliability around working with hierarchies. - swap our layout library. Our current dependency stretch implements the flexbox algorithm, but is unmaintained and has critical bugs :( The three main options here are to fork flex, move to the new morphorm crate, or write a layout library from scratch - consider rearchitecting our UI to be more flexible and compositional: splitting the massive Style component into several parts and moving to a "UI is a collection of behaviors" paradigm - build out more widgets! - more docs and examples!
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives