I've always been confused about game physics, this is such an amazing resource. Thanks as always for the high quality tutorial, really appreciate this!
It's often better to use the existing engine but I wouldn't always recommend it. Some games have very limited needs or special properties where a simple hand done system might be better suited. Physics engines add a lot to the feel of the game.
Thank you! I'm glad to see your still working on Bevy Basics as well, bevy is super cool and more people need to learn about it and have ways to figure out how to use it :)
This is so cool! I would like to see a use of that in more detailed video! Good Job! I'm currently working on Bevy project with use of Rapier. Your video really got in handy.
I have a major problem with the engine collision system, because I don't have direct access to the collision system I can't order the collision confinement system to be after the movement system for my player. This makes my player to momentarily go through the collider and then bounce back in this weird artifacting when running continuously into a wall.
Yeah ordering plugins is something I wish we could do in bevy. I usually work around this by using the rapier character controller (which has improved) or their movement methods. Otherwise you can move your character controller earlier in the schedule but that is also suboptimal
No if you use rapiers movement functions you can pretest the movements and only apply the part of your target movement that doesn't collide. I think you should look into the rapier context resource
I would consider it. The problem is it branches out in many directions and it would be hard to tie it all together. If you join the discord (in description) and pitch me what the demo would look like or what you'd want to see we can discuss it there.
by default, sensors will block your characters movement. I'm kind of thinking that shouldn't be a default. I wonder if this is a way to force people to know (or remind them) that these settings are there ...
I was thinking through a scenario of having a car drive through a wall, or something similar. Would you make all the "pieces" as "static rigid bodies" until the collider of the aggregate parent object is hit, then change all the pieces to dynamic so that the physics can take over? Does that sound reasonable. Also, do you happen to know the relationship between "instances" and physic settings for that instance? (Do all instances have to have the same physics settings?) thanks for any thoughts
How is the performance of Rapier? How many instances can it support at most. I tested it before and felt that the performance was not very good, so I switched to the physics engine.
That is a delicate question, I have notice it preforms well on my machine but I have seen it start to tank in certain situations running in wasm. It is designed in a modern way and uses simd/parallel processing so I would assume it is comparable to any modern physics engine (sparing it being relatively young). The constraints on what it can support will be very machine specific and you would need to profile it on the target platform with the load you are expecting to really get a clear idea what it's performance would be. What physics engine did you swap to?
I've always been confused about game physics, this is such an amazing resource. Thanks as always for the high quality tutorial, really appreciate this!
Thank you. It is better to use an already done physics than reimplementing it from scratch
It's often better to use the existing engine but I wouldn't always recommend it. Some games have very limited needs or special properties where a simple hand done system might be better suited. Physics engines add a lot to the feel of the game.
been floating the idea of trying rapier for over a year.... thanks so much
It's gotten much better in the past year! Highly recommend giving it a chance
love the work. really nice to see more people making bevy tutorials really helps spread the word about some cool plugins
Thank you! I'm glad to see your still working on Bevy Basics as well, bevy is super cool and more people need to learn about it and have ways to figure out how to use it :)
This is so cool! I would like to see a use of that in more detailed video! Good Job!
I'm currently working on Bevy project with use of Rapier. Your video really got in handy.
Your tutorials are great and update to bevy 0.9 is something I appreciate a lot!. Thank you!
Thank you for this overview and tutorial!
Very cool review 🎉
I have a major problem with the engine collision system, because I don't have direct access to the collision system I can't order the collision confinement system to be after the movement system for my player. This makes my player to momentarily go through the collider and then bounce back in this weird artifacting when running continuously into a wall.
Yeah ordering plugins is something I wish we could do in bevy. I usually work around this by using the rapier character controller (which has improved) or their movement methods. Otherwise you can move your character controller earlier in the schedule but that is also suboptimal
@@logicprojects Is the only way to "work around" this is by making my own collision system?
No if you use rapiers movement functions you can pretest the movements and only apply the part of your target movement that doesn't collide. I think you should look into the rapier context resource
@@logicprojects Ok thank you, I really didn't want to delve into that (:
i love this video! thank you for the time you put in to make this video. Will you consider making an advanced Rapier video?
I would consider it. The problem is it branches out in many directions and it would be hard to tie it all together. If you join the discord (in description) and pitch me what the demo would look like or what you'd want to see we can discuss it there.
@@logicprojects sounds I'll join tomorrow ☺️ thanks
by default, sensors will block your characters movement.
I'm kind of thinking that shouldn't be a default.
I wonder if this is a way to force people to know (or remind them) that these settings are there ...
I was thinking through a scenario of having a car drive through a wall, or something similar.
Would you make all the "pieces" as "static rigid bodies" until the collider of the aggregate parent object is hit, then change all the pieces to dynamic so that the physics can take over? Does that sound reasonable.
Also, do you happen to know the relationship between "instances" and physic settings for that instance? (Do all instances have to have the same physics settings?) thanks for any thoughts
I guess you want them as dynamic all the time because the engine will make them sleep when not interacted with.
Could you please review Lapce? It is a text editor written in Rust
I haven't heard of it before but I'll look into it!
Good video but some of the dark code text on the dark background is hard to read
yes and also i cannot see the red ball at all, only after it turns dark red 🥲
How is the performance of Rapier? How many instances can it support at most. I tested it before and felt that the performance was not very good, so I switched to the physics engine.
That is a delicate question, I have notice it preforms well on my machine but I have seen it start to tank in certain situations running in wasm. It is designed in a modern way and uses simd/parallel processing so I would assume it is comparable to any modern physics engine (sparing it being relatively young). The constraints on what it can support will be very machine specific and you would need to profile it on the target platform with the load you are expecting to really get a clear idea what it's performance would be. What physics engine did you swap to?
Rapies