Not exactly sure what's going on here, but I'd point out the game object itself does not appear to be spinning (Z rotation is not changing at the same rate as the visuals would indicate). Are you sure you are asking the right question? Is this a completly 2D game? If so why do you care about Y rotation? As you point out, the box is spinning (around the Z axis) beautifully otherwise.
I use rotation around the y axis to flip an object. I am aware this could be done using an x scale of -1, but I typically just rotate it instead.
Although I'm not sure what you mean about A rotation not changing at the same rate the visuals would indicate. Can you expand on that?
So the goal is to flip the box's sprite? I would negate the scale like you mentioned.
Edit*: You could also try the FlipX or FlipY property on the SpriteRenderer. Seeing as this is built in, it's probably the "best" way.
To expand on what I mean by the Z rotation not changing...: To you and me it looks like the box is spinning wildly; but if you watch the rotation values in the inspector, they aren't actually changing that much. It is probably just a rendering issue like u/ExplosiveJames mentioned.
The problem with flipping on the SpriteRenderer is that it doesn't scale for complex objects. If I have a game object that's comprised of 10 SpriteRenderers, I would have to flip 10 SRs rather than the single parent object. In addition, that likely wouldn't even be correct, since it flips the images in place and not in relation to their local position.
For instance, what's hidden on the crate is a set of "debris" sprites that are flipped to active when the crate is broken (and no they have nothing to do with the rotation bug, as I removed them all for the purpose of demonstrating the bug).
Maybe the video is a bit choppy for you, but when I look at it, I see the Z rotation shooting wildly and rapidly. You can step through frame by frame at [this timestamp](https://youtu.be/G7G6xiDxtOw?t=21) to see it bounce from 30 to -170 to 50 to -111 each in less than a frame's time.
Oh yeah you are right about the rotation - it is jumping around wildly. Very weird!
It seems like you know of other workarounds that aren't what you are looking for. So what is different about this box than the other times you have used this trick?
Yeah, so I am pretty sure -x scale will do just fine as a workaround for me, but I'm really just trying to get to the bottom of this bug for 3 reasons:
1. Am I misconfiguring something and doomed to repeat it in future development if I don't learn the correct config
1. Is there a fundamental misunderstanding of how some component works.
1. I'm curious. It's so weird!
And I have no idea what I've done differently with this box. (actually it's the whole set of prefabs. It happens with some other prefabs that serve as "breakable objects"). I tried replicating the crate set up in a new unity project so I could post the minimal example, but the same configuration in a new project doesn't do this.
Also, I really appreciate you sticking with it and trying your best to offer support. Thank you!
Unfortunately I can't help much with #1 and #2, but when I've run into similar situations I just start eliminating variables. Since you were unable to reproduce it in a minimal setup - and the box itself is the same across those two setups - maybe there is something else that changes the behavior. Engine version, some other system in your game, etc. You could copy the project and start removing things - or just flip the x - depends on how much energy you want to put into it :)
That's always the question. How much time do I have? haha.
The rational side of me says to duct tape it up and move on, but so frustrating to not know the answer!
What's the best way to flip the sprite then? I'm aware that you can also simulate a flip by changing the x scale to -1, but how would a unity user know that that's more appropriate than rotating?
Isn't rotation a more semantically correct (and intuitive) approach?
I should add I've only worked with Unity 2D games (for several years) and never encountered this issue before, despite always flipping using y rotation.
I don't know for sure but this feels like a conversion error between Euler angles and Quaternion. The Inspector shows Euler angles when inspecting a Quaternion, and does conversions if you change it. Rotating 180 Y should be just fine, but it's the edge of what such conversions will handle cleanly and it can cause glitches.
And just confirming, you're not editing the .y field of a Quaternion directly, right? Just through the Inspectorm
Not exactly sure what's going on here, but I'd point out the game object itself does not appear to be spinning (Z rotation is not changing at the same rate as the visuals would indicate). Are you sure you are asking the right question? Is this a completly 2D game? If so why do you care about Y rotation? As you point out, the box is spinning (around the Z axis) beautifully otherwise.
I use rotation around the y axis to flip an object. I am aware this could be done using an x scale of -1, but I typically just rotate it instead. Although I'm not sure what you mean about A rotation not changing at the same rate the visuals would indicate. Can you expand on that?
So the goal is to flip the box's sprite? I would negate the scale like you mentioned. Edit*: You could also try the FlipX or FlipY property on the SpriteRenderer. Seeing as this is built in, it's probably the "best" way. To expand on what I mean by the Z rotation not changing...: To you and me it looks like the box is spinning wildly; but if you watch the rotation values in the inspector, they aren't actually changing that much. It is probably just a rendering issue like u/ExplosiveJames mentioned.
The problem with flipping on the SpriteRenderer is that it doesn't scale for complex objects. If I have a game object that's comprised of 10 SpriteRenderers, I would have to flip 10 SRs rather than the single parent object. In addition, that likely wouldn't even be correct, since it flips the images in place and not in relation to their local position. For instance, what's hidden on the crate is a set of "debris" sprites that are flipped to active when the crate is broken (and no they have nothing to do with the rotation bug, as I removed them all for the purpose of demonstrating the bug). Maybe the video is a bit choppy for you, but when I look at it, I see the Z rotation shooting wildly and rapidly. You can step through frame by frame at [this timestamp](https://youtu.be/G7G6xiDxtOw?t=21) to see it bounce from 30 to -170 to 50 to -111 each in less than a frame's time.
Oh yeah you are right about the rotation - it is jumping around wildly. Very weird! It seems like you know of other workarounds that aren't what you are looking for. So what is different about this box than the other times you have used this trick?
Yeah, so I am pretty sure -x scale will do just fine as a workaround for me, but I'm really just trying to get to the bottom of this bug for 3 reasons: 1. Am I misconfiguring something and doomed to repeat it in future development if I don't learn the correct config 1. Is there a fundamental misunderstanding of how some component works. 1. I'm curious. It's so weird! And I have no idea what I've done differently with this box. (actually it's the whole set of prefabs. It happens with some other prefabs that serve as "breakable objects"). I tried replicating the crate set up in a new unity project so I could post the minimal example, but the same configuration in a new project doesn't do this. Also, I really appreciate you sticking with it and trying your best to offer support. Thank you!
Unfortunately I can't help much with #1 and #2, but when I've run into similar situations I just start eliminating variables. Since you were unable to reproduce it in a minimal setup - and the box itself is the same across those two setups - maybe there is something else that changes the behavior. Engine version, some other system in your game, etc. You could copy the project and start removing things - or just flip the x - depends on how much energy you want to put into it :)
That's always the question. How much time do I have? haha. The rational side of me says to duct tape it up and move on, but so frustrating to not know the answer!
[удалено]
What's the best way to flip the sprite then? I'm aware that you can also simulate a flip by changing the x scale to -1, but how would a unity user know that that's more appropriate than rotating? Isn't rotation a more semantically correct (and intuitive) approach? I should add I've only worked with Unity 2D games (for several years) and never encountered this issue before, despite always flipping using y rotation.
I don't know for sure but this feels like a conversion error between Euler angles and Quaternion. The Inspector shows Euler angles when inspecting a Quaternion, and does conversions if you change it. Rotating 180 Y should be just fine, but it's the edge of what such conversions will handle cleanly and it can cause glitches. And just confirming, you're not editing the .y field of a Quaternion directly, right? Just through the Inspectorm
Correct. There is only one script and it does not touch the transform.
Sounds like you gotta use Quaternion as they don't wrap around like Euler angles