Skip to content

Running the boxes2 example twice gives two different results #305

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

Open
aleksa2808 opened this issue Dec 31, 2022 · 4 comments
Open

Running the boxes2 example twice gives two different results #305

aleksa2808 opened this issue Dec 31, 2022 · 4 comments
Labels
A-Integration very bevy specific D-Difficult Needs strong technical background, domain knowledge, or impacts are high, needs testing... P-High arbitrary important item S-in-progress

Comments

@aleksa2808
Copy link

As stated in the title, running the boxes2 example back-to-back gives two visibly different results. Running the 2D CCD example from the rapier repo gives the same result every time. Is it possible there is a bug in the bevy plugin layer that's causing the difference?

First run:
image

Second run:
image

@sebcrozet
Copy link
Member

That’s likely related to #233

@rparrett
Copy link
Contributor

FWIW, I can reproduce the behavior on an M1 mac.

@aleksa2808
Copy link
Author

That’s likely related to #233

Perhaps, although in the current state of that pull request I'm still getting differing results with the boxes2 example.

@aleksa2808
Copy link
Author

As stated in the Bevy discord's #physics channel, when I add the RapierConfiguration resource with TimestepMode::Fixed (tried with dt = 1.0 / 60.0 and substeps = 1 values) each run is now the same.

The question now is: was I wrong in assuming that two boxes2 example invocations with the default plugin configuration would provide the same result? If so, then there is no bug present and I can close this issue.

@Vrixyz Vrixyz added D-Difficult Needs strong technical background, domain knowledge, or impacts are high, needs testing... P-High arbitrary important item S-not-started Work has not started A-Integration very bevy specific S-in-progress and removed S-not-started Work has not started labels May 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Integration very bevy specific D-Difficult Needs strong technical background, domain knowledge, or impacts are high, needs testing... P-High arbitrary important item S-in-progress
Projects
None yet
Development

No branches or pull requests

4 participants