I am the only one feeling queasy at a system that treats slow-moving as non-moving?
>
) Sleeping is a technique that reduces the cost of simulating objects that are not moving to improve performance. We can tweak it by adding a SleepingThreshold resource:
fn main() {
App::new()
.add_plugins(DefaultPlugins)
.add_plugins(PhysicsPlugins::default())
// These are the default values
.insert_resource(SleepingThreshold {
linear: 0.1,
angular: 0.2
I'm currently using xpbd to work on a physics driven 2d fighting game, and as of right now, I'm really enjoying it! Until now there was only one problem where some collisions would vanish for one frame. But stuff like that can be easily worked around and even better reported and fixed.
XPBD has caught my fascination. I've done a couple trial implementations and put AABB-only XPBD in my latest game jam.
The only thing I haven't gotten to work is rotation. Everything else, the complexity just melts away. Linear algebra? Nope. Just Vec3. Matrix? Solver? You hit your head, it's 1998, just iterate over all the constraints and satisfy them. Collision margins? Skill issue. Broadphase? GJK? Don't over-think it. Throw a modern CPU at it, do the collect_pairs optimization, then realize you were actually malloc-bound and fix that, and it can handle 100 or so objects without blinking. Don't need Bullet.
The velocity fix-up step also threw me off, but having prototyped it for AABBs, I suspect I can translate it back to generic shapes. I skipped it at first and all my collisions were slightly elastic.
I learned a lot about Rust by making games with Bevy and writing down everything I learned: https://taintedcoders.com/
The smaller the game the more likely you are to finish. I usually started with making the movement fun and then developed some game like concepts around it.
I also highly recommend starting by making simulations instead of games as when you're alone they are still a blast to see come alive. Building boids is a fantastic exercise I do in any new engine.
The gist is that instead of partitioning by type you sub partition by usage. Bevy does this by optimizing your storage based on the bundles (groups of components) you create. Flecs does the same but I'm not sure of the exact mechanism.
There are lots of stuff missing on the bevy cheatbook (https://bevy-cheatbook.github.io) and lots more hidden in the Discord that are unsearchable on Google so I hoped this would help fill the gap for teaching some friends.
Its true, Bevy is quite limited with only simple parent/child relationships[0] and much of the community is looking for more structured relations.
As it stands its pretty common to hold a `HashMap<Index, Entity>` and manually manage the data structure through derefs or some system that keeps it consistent. Ideally only using it for lists of entities that remain static like a tilemap.
I started writing when I was teaching newer programmers and I found the amount I didn't know how to explain clearly was staggering. Things I thought I knew so were actually kind of blurry blobs in my mind.
Recently I've been exploring Bevy and rust game development and my learning has been so much better when I create docs for myself: https://taintedcoders.com/
I've been learning about Rust game development with some friends after being a long time Ruby developer and am looking for better ways of explaining the low level stuff to high level rubyists.
I had ended up using ffmpeg a few times for this (i think inspired by the link you gave there) because it's often easier to share video than just audio on mainstream social media
A few details of what worked for me and the output shown here:
An interesting alternative in the Bevy space is Bevy XPBD which I also wrote about: https://taintedcoders.com/bevy/xpbd/