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

Why does my Transform::translation immediately get NaN values? #366

Open
tliron opened this issue Jun 1, 2024 · 2 comments
Open

Why does my Transform::translation immediately get NaN values? #366

tliron opened this issue Jun 1, 2024 · 2 comments

Comments

@tliron
Copy link

tliron commented Jun 1, 2024

I've spent hours tried to debug this, but am stuck and need some help. Using bevy_xpbd_2d.

I tried to naïvely (following the documentation) add a RigidBody to an existing SpriteBundle entity. But then the Transform::translation x y values immediately go to NaN and the sprite of course disappears. Actually rotation also becomes Quat(0.0, 0.0, NaN, NaN), I'm confident those are related.

I've tried so many things! Different types of RigidBody (including Static) have the same effect. Removing all gravity, including inserting a GravityScale of 0, same effect. LockedAxes::ALL_LOCKED, same effect. Explicitly adding a Position at 0, same effect. Adding colliders and MassPropertiesBundle, same effect.

I just don't know what could possibly be causing this. Is it applying some velocity or force from something else? Is the sync between Position and Translation going wrong? There are no debug messages at all from bevy_xpbd_2d.

@tliron
Copy link
Author

tliron commented Jun 2, 2024

I made some progress on this. Through trial and error I discovered that the NaN problem pops up when I change the Transform::scale. I'm not really sure why it would have this effect. Does the Transform::scale affect collider sizes or other associated components of RigidBody?

@tliron
Copy link
Author

tliron commented Jun 14, 2024

Another discovery. The scale cannot have 0 in its z axis. This is surprising because we are working in 2D. But apparently something in the calculation still takes the z axis into account.

I would consider this a bug. At least it's something that should be documented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant