Euler property animation on game object (DEF-1636) (SOLVED)

Bugs
1

Hi guys,

I have been struggling during my last couple of coding sessions with a strange behavior I have discovered (Defold -1.2.81).
In a nutshell, when animating the euler property on the z-axis, if you go over 90 deg. (using go.animate) and apply any other animation (such a going back to 0 deg.), the rotation applied will be the opposite of what would be expected.
I would expect this kind of behaviour when going 180 deg. not 90.

I’ve bundled together a test collection in a debug project that you can easily reproduce this. Please find it here:

It’s also interesting to notice that when using go.get() to retrieve the current value of “euler.z”, it gives strange result and visuals when the game object is over 90 and less than it’s final rotation value.

Please advise.

Thanks,
Nicolas.

2

Can you provide a repro case for this?

3

Hi Sicher,

the github link provided points to a defold project that showcases this issue.
Or It can be reproduced quite easily by applying to a game object the following:

go.animate(".", “euler.z”, go.PLAYBACK_ONCE_FORWARD, -120, go.EASING_LINEAR, 1)

then

go.animate(".", “euler.z”, go.PLAYBACK_ONCE_FORWARD, 0, go.EASING_LINEAR, 1)

when the first animation is done. Instead of rotating back to its initial position it goes to 180 deg.

4

Thanks. I did a quick test like you suggested. I’ll investigate what’s going on here. Looks like a bug.

5

Yes, a bug. As you said, if the first rotation is below +/-90 degrees, it works as expected. Reported.

DEF-1636

6

Where we can see all of this DEF-XXXX?

7

Great thanks Sicher.
And yes, that would be great to have a public board of your jira trackers.

8

You can’t. It’s King’s internal Jira that is used for all development. Not only Defold.

9

Hi guys,

I believe this issue is a duplicate of DEF-1636. Might be good to flag it.
Do you have any update regarding this by the way?
I’m still hoping I could use euler rotation at some point :slight_smile:

10

Correct- DEF-1883 has been closed in JIRA as a duplicate of DEF-1636. I’ve updated references to DEF-1883 on the forum as well.

No update on this issue though.

11

Hi britzl, thanks for the update.

Is this issue has any change to get into a sprint before the end of summer?

12

Hi guys,

Not sure if I’ve missed an update regarding this issue?

2 Likes
13

I too wonder this, I’m not sure I’m hitting this bug or not but I’m trying to rotate stuff by animating euler.z and I have unexpected behaviour when going past 90 degrees.

14

Solved in Defold 1.2.123

2 Likes
15

Best news ever. Thanks!

4 Likes
16

Hey, I’d like some details on this.
If I use the following code with the latest version of Defold, the animation is still bugged:

local target_rotation = vmath.quat(0, 0, rotation_z, rotation_w)
go.animate(".", "rotation", go.PLAYBACK_ONCE_FORWARD, target_rotation, go.EASING_LINEAR, 0.1, 0)

or

go.animate(".", "euler.z", go.PLAYBACK_ONCE_FORWARD, rotation_z*180, go.EASING_LINEAR, 0.1, 0)

(happens when rotation_z was equal to -1 and then goes to 1 after a 360° rotation)

Thanks.

1 Like
17

Animating the “rotation” property animates the rotation quaternion linearly with no normalization. This will cause all sorts of artifacts like scaling. You should use vmath.slerp().

1 Like
18

Well, using vmath.slerp() along with set_rotation() works, but not using animate() like:

local rot = vmath.slerp(1, go.get_rotation(), target_rot)
go.animate(".", "rotation", go.PLAYBACK_ONCE_FORWARD, rot, go.EASING_LINEAR, 0.1, 0)

Sorry if I should have made another forum topic. I’ve seen lots of messages about this but none of them helped. I can understand if it’s a bit more complex than just using that snippet of code above.

19

No, exactly. go.animate() linearly interpolates which “messes up” the quaternion adding scale and such to it.

2 Likes
20

What went wrong with this line? This should work in the current version.