Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make physics entity creation more difficult to mess up #475

Closed
JonasAAA opened this issue Aug 1, 2024 · 1 comment · Fixed by #483
Closed

Make physics entity creation more difficult to mess up #475

JonasAAA opened this issue Aug 1, 2024 · 1 comment · Fixed by #483
Labels
A-Dynamics Relates to rigid body dynamics: motion, mass, constraint solving, joints, CCD, and so on C-Usability A quality-of-life improvement that makes Avian easier to use

Comments

@JonasAAA
Copy link
Contributor

JonasAAA commented Aug 1, 2024

I'm using Avian version 0.1.1.

Currently quite a few components for physics entities are added only when the physics systems are run, for example, Mass, and Inertia, LinearVelocity, etc. In my game, I rely on entities being fully formed immediately after they are spawned.
When I add mass properties components manually, I also must not forget to set collider density to 0, otherwise the mass properties from the collider will be added on top. Adding these (and some other issues) up the whole physics entity creation is very easy to mess up in some way.

I have some ideas on how to improve the situation, I can share them if this is something we want to address.

@Jondolf Jondolf added A-Dynamics Relates to rigid body dynamics: motion, mass, constraint solving, joints, CCD, and so on C-Usability A quality-of-life improvement that makes Avian easier to use labels Aug 1, 2024
@Jondolf
Copy link
Owner

Jondolf commented Aug 1, 2024

I plan on switching most of those component initialization systems to use component lifecycle hooks or observers to get rid of the majority of the unnecessary delay. We could/should also use required components once those land in Bevy to make it actually immediate and to avoid unnecessary archetypes. PRs are also welcome for changing the systems to hooks :)

Re: mass properties, they have lots of issues and should be overhauled. There's an issue for this (#443) but that doesn't have that much information. There's a few discussions on Discord though, like here and here. There's a ton of design options and considerations there, and I haven't figured out all the details just yet, but it's in the plans.

I also must not forget to set collider density to 0, otherwise the mass properties from the collider will be added on top.

Pretty much all engines default to colliders (excluding sensors) contributing to mass properties afaik, like Unity and Godot for example. Forcing people to specify mass properties explicitly by default would be much more footgunny and painful. I do agree though that it should be easier to configure mass properties and how colliders should affect them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Dynamics Relates to rigid body dynamics: motion, mass, constraint solving, joints, CCD, and so on C-Usability A quality-of-life improvement that makes Avian easier to use
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants