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

Syncing child transforms produces jittery results, which causes further issues #383

Open
AnthonyTornetta opened this issue Jun 13, 2023 · 2 comments
Labels
A-Integration very bevy specific D-Difficult Needs strong technical background, domain knowledge, or impacts are high, needs testing... P-Low question Further information is requested S-not-started Work has not started

Comments

@AnthonyTornetta
Copy link
Contributor

AnthonyTornetta commented Jun 13, 2023

When moving at high speeds, the difference is quite apparent as seen here:
Peek 2023-06-12 22-16
The non parent-child relationship is on the left & the weird parent/child pair is on the right.

The camera follows the buggy child in the right pair, which is why the left pair keeps going up as the right pair slows down and the child eventually phases through the parent.
In this example, the top cube is traveling 1m/s slower than the bottom cube.

I assume the error is located somewhere in writeback_rigid_bodies. Maybe something wrong with the parent transform being a frame out of sync?

Code for the example in the gif: https://gist.github.com/AnthonyTornetta/2a6a4573126071c961eabe3c95aca247

Update:
After more testing, this is also apparent at low speeds. Even with it only moving 2m/s, the jittering is noticeable & they interact poorly with each other.

Video at low speed (2m/s) (ignore my jittery recording software): Peek 2023-06-13 13-43
You can see the left pair behave properly and the right parent/child pair react incorrectly.

@AnthonyTornetta AnthonyTornetta changed the title Syncing child transforms procuces jittery results, which causes further issues Syncing child transforms produces jittery results, which causes further issues Jun 13, 2023
AnthonyTornetta added a commit to AnthonyTornetta/bevy_rapier that referenced this issue Jun 14, 2023
AnthonyTornetta added a commit to AnthonyTornetta/bevy_rapier that referenced this issue Jun 15, 2023
This reverts many commits (fb4f69a - ee5460a).
@Aceeri
Copy link
Sponsor Contributor

Aceeri commented Jul 29, 2023

What is the expected behavior here? A bit confused on what should happen.

Tbh I feel like this is a case where we'd ideally be able to opt out of propagation of transforms

@AnthonyTornetta
Copy link
Contributor Author

From what I saw in the code I believe this is the expected behavior, though this is really a dimforge question. I assumed that objects should behave like they have like fixed joints that can move around as they please. While cartoony, it makes sense they would behave that way since a child will normally move with its parent in bevy.

I wrote up a fix for this in my fork of bevy_rapier https://github.com/AnthonyTornetta/bevy_rapier and found that this is because while it does move the child with its parent, it doesn't sync their velocities. So rapier thinks a 200m/s thing is hitting a -1m/s object, even though it should think the object is 199m/s because it's a child of the 200m/s object.

@Vrixyz Vrixyz added question Further information is requested D-Difficult Needs strong technical background, domain knowledge, or impacts are high, needs testing... P-Low S-not-started Work has not started A-Integration very bevy specific labels May 23, 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-Low question Further information is requested S-not-started Work has not started
Projects
None yet
Development

No branches or pull requests

3 participants