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

Effective coefficient of restitution should be clamped between 0 and 1 #114

Closed
alice-i-cecile opened this issue Aug 8, 2023 · 3 comments · Fixed by #118
Closed

Effective coefficient of restitution should be clamped between 0 and 1 #114

alice-i-cecile opened this issue Aug 8, 2023 · 3 comments · Fixed by #118
Labels
C-Enhancement New feature or request

Comments

@alice-i-cecile
Copy link

Currently, you can set it to e.g. 2.0 (with max combine rule) in the move_marbles example and things will explode.

@alice-i-cecile
Copy link
Author

alice-i-cecile commented Aug 8, 2023

You can observe pathological behavior on the negative end with min combine rule + a value of e.g. -999.

@Jondolf Jondolf added the C-Enhancement New feature or request label Aug 8, 2023
@Jondolf
Copy link
Owner

Jondolf commented Aug 8, 2023

Yeah I think this would be a good idea. I can come up with a few potential use cases for bodies gaining kinetic energy on contact, like a game where a ball gets faster each time it hits something, but this might not be considered good practice due to the explosion risk, and I think it's better to do this manually since it allows for more control.

It seems that Unity clamps each material's restitution coefficient between 0 and 1 regardless of the combine rule, so you can't have e.g. 0.5 and 2.0, which would be 1.0 with CoefficientCombine::Multiply. Instead, it will be automatically changed to 0.5 and 1.0, which would be just 0.5.

The main question is, should we clamp both coefficients individually like Unity does, or just clamp the effective, combined coefficient? The second option allows you to multiply e.g. 0.5 and 2.0 to get 1.0, but the first option might be more explicit in that the restitution coefficients are explicitly set to 1.0 even if you try to use a larger value, instead of internally using a separate clamped value for the effective coefficient of each contact.

For explicitness and clarity, I'm leaning on the first option, but I can see why the second option could be useful as well.

@alice-i-cecile
Copy link
Author

I think we should do the first for explicitness as well. It also lets you move the checks to construction, which should be much faster.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-Enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants