solved [Solved] animation "glitch"

[Snouto]

hey internet dudes

So yeah, still working on this scene, although lately i've been on a different project so haven't been look at my issues with babylon for a little while.

I've got this test scene set up here;

http://snou.to/tests/babylonjs/animation/test4/

From inspecting the html you'll see my super fantastic javascript code that is animating the helicopter (amongst other things).

Some questions for the experts out there:

1) the helicopter has a brain fart at around 9 o'clock on the circular path it is following. Any idea why? It also has a very minor "course correction" at 3 o'clock. No idea why, is it my maths at fault here or something more fundamental?
2) if you click on the helicopter it does a little animation. Intention here was to blend the animations so that the user can interact with the object in a simple manner. Fundamentally it's working, but you'll notice the spin and bounce animations don't end exactly where the circular path is, and so often the helicopter "snaps" back in to position of the initial animation. This is probably a stupid question given the specifics of what i'm trying to do here but is there some technique I can use to ensure the end frame of the blended animation always ends perfectly so that the motion blends in to the original animation without snapping? Right now I'm having to hard code specific frame lengths and speeds and it's imprecise and a PITA, so I feel like there's got to be a better approach. My maths skills are awful though so if anyone can help that would be sweet.

Cheers!

 

[FunFetched]

Just a guess after a quick look at the code, but I'm guessing that the very last point on your path is missing proper tangent information, since it would have no additional points from which to calculate a tangent. Have you tried playing only 29 frames of the animation instead of 30?

[Snouto]

hi thanks for the reply. You suggestion would make sense if the quirk was happening at the start/end of the path but it appears to occur half a way around. Unless you're referring to the "course correction" issue, which makes more sense?

[Snouto]

Ok I've put this in to a PG so peeps can take a look and better understand the dillio

https://www.babylonjs-playground.com/#RVA3F4#2

 

[FunFetched]

Ah! The Playground does help. Check out https://www.babylonjs-playground.com/#RVA3F4#3 . The issue with the glitch in the middle is that you were using Euler rotation instead of Quaternion. Euler sometimes doesn't handle full rotations very gracefully, flipping around madly when the sign of the angle flips; that is, jumping from PI/2 to -PI/2 from one frame to the next as it passes the half way point. Quaternion, on the other hand.... well.... it just does handle that situation, but I couldn't possibly explain why.

As for the spin, you're blending two animations together that share the same mesh. So, say we're at the halfway point again, and you're facing 180 degrees the opposite direction. You want the spin to end at 180 degrees, but the spin animation wants to start and end at 0. These are two separate animations, and the spin animation doesn't inherit anything from the orbit animation.

What you'll want to do here is actually create an empty AbstractMesh to contain the helicopter. Apply the orbit animation to this AbstractMesh, and apply the spin animation to the helicopter mesh directly. That way, your spin animation will affect the local coordinates and orientation of the helicopter mesh only, while the global position and orientation will be controlled by the orbiting animation that controls its parent.

[FunFetched]

Check out https://www.babylonjs-playground.com/#RVA3F4#4. This mostly implements what I'm talking about in regard to the AbstractMesh. It's mostly working at this point. The spin animation is off by 90 degrees, but you'll see that it now behaves in a consistent manner when you click on it. Note that I reset the position of the helicopter mesh itself to 0, so that it would be positioned in the middle of the container.

[Snouto]

Hey thanks for that @FunFetchedI really appreciate the time you put in to helping me with my issue.

The rotation issue certainly appears to be much better now than it was before - there's still a slight course correction going from the end to start frame, but maybe i can do something there along the lines of the previous advice you've given.

The bump and spin issues makes sense as well, although one of the challenges with this animation has been to ensure the helicopter is always facing the direction of travel. With this new scene of course the helicopter _container_ is always facing the right direction, but as soon as the chopper spins - since that is inside the parent - there's nothing to ensure it ends the animation pointing in the correct direction.

I'll take a closer look at your PG and see if I can figure it out. Thanks again for your help

[FunFetched]

No problem! You'll notice that every time you trigger the spin animation, it always ends facing inward, so it is actually following the direction of travel, in a manner of speaking. It just needs to be turned 90 degrees.

[Snouto]

12 minutes ago, FunFetched said:

No problem! You'll notice that every time you trigger the spin animation, it always ends facing inward, so it is actually following the direction of travel, in a manner of speaking. It just needs to be turned 90 degrees.

The issue with that is the animation starts pointing in the correct direction, but ends in the wrong direction, which to my mind means I have to very carefully tweak the rotation logic (speed, number frames etc) to ensure it always fires enough frames to ensure it ends where it starts. This is still a PITA for me, assuming I'm thinking about this correctly.

Perhaps I should reintroduce something like TweenMax to simply give it a start and end position and tell it to tween the animation for all frames in-between. That the helicopter is now parented means I probably just need to ensure the animation always starts and ends at local Z (0), and it'll always be pointing in the correct direction thanks to that logic being in the parent mesh quaternion rotation logic.

[FunFetched]

6 minutes ago, Snouto said:

That the helicopter is now parented means I probably just need to ensure the animation always starts and ends at local Z (0), and it'll always be pointing in the correct direction thanks to that logic being in the parent mesh quaternion rotation logic.

Yep; that!

[Snouto]

I haven't yet figured this out as i've been focused on other areas, but i'll mark as solved because moving to quats solved the glitch issue. Thanks again @FunFetched