Questions about Animatables & Animations

[Wingnut]

Hi guys!

   I decided to ask some questions about Babylon animation, per a request from a friend.    Although I am not currently experimenting with animations, that does not mean others can't.  In this first post, I want to ask some basic questions.  (ok, maybe not THAT basic)  Thanks for input/answers.  Feel free to do long answers.  heh.

1.  No Animation can run without an Animatable? (true/false)

(I realize that Animatables are often automatically-created by easy user-exposed create-an-animation functions)

2.  Animation has no target / targetMesh.  No Animation knows what mesh it is suppose to animate. (true/false)

3.  All Animations get their target (their target mesh) from the Animatable? (t/f)

4.  Animatable.appendAnimations(target, animations)... Can target be a different mesh for each call to this?  (y/n)  (next question is related)

5.  Can a single Animatable have multiple targets?  (multiple mesh, not multiple properties)  (y/n)

6.  Can a single Animation have multiple targets?  (again, multiple mesh, not talking about multiple properties.  I think .targetPropertyPath is for multi-props, maybe:)

7.  Animatable.loopAnimation supersedes/overrides Animation.loopMode?

8.  IF an Animation cannot run without an Animatable's target, Animation.animate(...) is not user-callable UNLESS user has somehow created an Animatable for it.

Extra credit questions:  (I'll gladly take answers, but I feel guilty because I should research it myself)...

9.  Is Animatable.speedRatio related-to framePerSecond in new Animation(name, targetProperty, framePerSecond, dataType, loopMode)?

10.  Is Animatable.speedRatio the same value as Animation.animate(delay, from, to, loop, speedRatio).

Easy-read format, easy to answer, what else could anyone ask-for?    Hey, thanks for helping Wingnut get his head on straight.  (get his crap together).  Advanced animation docs and demos... on the horizon.  (yeah, right).  Did you notice that Animation is not one of the Features demos on the BJS main site?  Yet that feature is VERY important to the future of 3D worlds.

Anyway, here is the most complicated Animation demo I ever made, and it is a fun place to experiment.  aa = animatables, at = animations.  Easing systems ON, for the blue cone (animation #7/7b, far-down in the code).  It looks like animation7b/keys7b has quit working... or I broke it somehow.  It USED-TO rotate the blue cone... with easing.  It seems to have lost its rotor-motor.   

Related to #8, The Blax Maneuver begins at line 145.  149-150... create some Animatables.  Notice 'at1' and 'at2' in arrays as the last param.  I think this is because a LIST of animations can be put there.  I am assuming one animatable can control many animations... but there is a only a single target in the 2nd param.  So, I'll assume no multi-(mesh-) targets allowed.  This begs the question...  is pushing Animations into mesh.animations... necessary?  Or is it simply a convenient storage place?  Extra extra credit questions.    Lastly, notice I did not call Animation.animate(...) in lines 155-156.  I called Animation._animate().  This might be because Animation.animate() did not work in starting those animations.  I can't remember.  Testings allowed.  Please report findings.

Thanks for the answers/discussions, babbers.  Everyone is welcome to comment, of course.  Be well.

[GameMonetize]

1. True: an animatable is a collection of animations + target + start and end keys

2. Correct. Animation animates a value. Animatable are here to use this value and transmit it to a target. Animatable also controls where the animation starts and ends regarding the global animation timeline.

3. True

4. Yes

5. yes: Every animations inside an animatable can have its own target

6. Animations have no target (see #2). 

7. Correct: Animatable.loopAnimation is created from Animation.loopMode

8. Animation.animate is called by the root animatable to interpolate the value managed by the animation. The animatable will then get the interpolated value and give it to the target

9. Correct: the final framePerSecond = speedRatio * framePerSecond

10. Correct

11.is pushing Animations into mesh.animations... necessary?  Or is it simply a convenient storage place? Convenient AND interesting when cascading: if you animate an object, this object can implement getAnimatable() which is a function that returns objects to animate simultaneously. For instance if you start an animation on a mesh, this mesh can have a material, if this material has animations (stored in material.animations) then this animations will be launched as well. If the material has textures which have animations (in texture.animations) they will be started as well.

Thank you for providing a clear list of questions

[gryff]

Now you see why I like using Blender Wingy I just create the animation and the babylon exporter does the rest.

Mind you, now you ask the questions and DK has answered, I guess I should ponder these esoteric issues

But since Jeff, as he puts it, "I am close to finishing (hopefully) a massively improved animation system" - maybe I should not rush.

cheers, gryff

 

 

[Wingnut]

Thanks for all the answers, Deltakosh.  Very nice of you.  It helped me a great amount, and hopefully it helped others, too.  I will leave this thread open for some more time.  I and others might have a few follow-up questions.    Besides, I have not learned where/how to mark a topic as answered.

[GameMonetize]

Small update: I've just commited the first version of animations blending:

So basically, you can now start an animation with enableBlending = true and this animation will interpolate FROM the current object's state.

In this PG, every time you click on the FPS marker, the animation is blended with box's position:

http://www.babylonjs-playground.com/#2BLI9T#2

[Wingnut]

oooookay, about these blendings... (and writing the docs for it)

1.  Can the animation blend (re-factor/re-interpolation) happen DURING another animation run?  It seems yes, when I lightly-tested your FPS-button demo.

2.  If so, can a blend happen during the SAME animation... running?  (Can the blended animation, blend with itself?)

3.  If an animation is continuously running at its last frame (loopmode-constant), does the blend do anything?

4.  Will a blended animation have smaller steps than the original animation, because it has less distance till end frame, yet same amount of keys as original?

5.  If both anim1 [orig] and anim2 [blend] are carried by the same Animatable, and reset() is called on the Animatable, will it reset BOTH?

I could go-on for an hour, yet.  It might be a "simple" feature to you (because you know the animation system well), but for doc writers who are trying to head-off a bunch of forum questions... this is trouble.  In the time it takes to explain all this to me and the forum, you could just add a few vague lines to the animation tutorial, and be done.  We will handle the 500-question fallout on the forum, later, when the users get impatient and grumpy with our less-than-detailed docs on the subject.

If the docs ARE detailed, then the users get grumpy and frustrated because it's too much to read, too much to translate, over-explained by Wingnut, with 35% wrong things written, because Wingy didn't understand it during authoring. 

Wingy TRIES to crawl inside Deltakosh's head, but Wingy doesn't speak French, and DK is very busy and dislikes puppytalk.  Then Wingy tests and tests and tests, until he has at least SOME understanding of what DK was thinking, or the use-case that caused the added feature.

Wingy FINALLY writes a book-worth of text in the animation tutorial, trying desperately to head-off future forum questions.  Then DK and users get discouraged because the Animation docs no longer look "simple"... the way we want BJS to be.

Better to explain it thorough or explain it basic?  Nobody has an answer, because it is un-answerable.  Wingy needs to make that decision himself, about HOW MUCH to explain, and HOW MUCH he is qualified to explain.  Then he must choose the words and phrases that travel best through an auto-translator, and meantime, he forgot what Deltakosh taught him about the new system/feature. 

Wingy then screams.    The whole situation is really not very healthy.  hehe.

Yuh, yuh, yuh.  Truth is, I had to pull back... because it was killing me.  Still is, but I cover it up with smoke screen so nobody notices, and I can get back to making people laugh.

How's that for a purse dump?    I know you want me to get back into these docs, guys, but the stress-causing issues still remain, and I still have to hack source myself to get the understanding I need.  Not just hack source, but build test after test... trying to imagine everything that could go wrong or have far-reaching ramifications (FRR), and writing those warnings into the docs.

The camera tutorial is a perfect example.  There is VERY LITTLE detail in there.  Essentially, here's how to turn on THIS camera and THAT camera.  Not much detail.   How's the forum question-levels regarding cameras?  About 50,000 questions regarding cameras, so far?  *nod*.   Wingy asks in Tutorial Talk "Hey, should we bust-up the camera tutorial into pieces so we can get more detailed?  Answer:  [crickets chirping].

Ain't this fun?  I once did godray demos and sparticle demos and got lots of LIKES.  Where is it all going?  What's the plan?  How do I quit losing sleep over it?  Hey, here is an idea.  Try to keep-up with the high speed of innovation that is happening to BJS ... and try to keep-up with the docs-writing FOR that.  We're talking INSTANT balding. 

[GameMonetize]

1. yes

2.no

3. no

4. Same timing. So same steps

5. yes

And I share your pain here. I feel the same when I write docs..Is it enough? too much? I don't know. But at least there is a doc

[Wingnut]

Hi gang!

I started a little playground.

http://www.babylonjs-playground.com/#1LNWLE#2

My first time using animationEvent, and it seems to be working just fine.  For a long time, I have wanted ANIMATIONLOOPMODE_PINGPONG.  This is when the animation runs forward, then backward, then forward, etc.  It is one of my favorite types of loop-mode, because it continuously "oscillates", and that is very useful (imho).  WAY back, when I built my CSS animator called Jackal, I used ping-pong (pp) and reverse-ping-pong (rpp) often.  (open the motors table).  Boy, those animations sure run MUCH FASTER than they did in the old days. 

Well, today, I decided to play-with accomplishing that.  I used the new animationEvent... on our familiar 4-bone rabbit.  She (he?) has 4 animations on her animatable (called 'able'), one for each bone... 0-3.  Take note that the animation(s) have 100 frames, but have 141 keys.

Pingpong() func attempts to flip-flop (reverse) all 141 keys of all 4 animations, by iterating through each _keys array, and un-shifting them into a new array, and then using that newKeys array to replace the old _keys of each animation.  Unshift is front-pushing, so, in theory, key #140 will be at the beginning of the new array, and key #0... at the end. 

It's a keys flip-flopper.    Note that I am less-than-pro at nested for-loops, so, please help me check my stuff, there.  I use the drill-able object inspector in the Firefox console area... often.  It also allows live-editing (poke values... from within the inspector).  SUPER handy!  To use the FF object inspector, simply console.log(someObject), and then click on that object... in the console.

I think it's actually working, but I have not been able to restart or animatable.reset() the animations.  Perhaps the animations have already stopped by the time I get the new keys installed.  But I am hoping that animatable.reset()... which calls all 4 animation.reset()... would get the job done. 

Also note that I have put the animationEvent on bone0 animation ONLY.  All 4 animations have the same amount of keys, so there is no reason to have all of them trigger animationEvents.  All we need is one.

See line 39?  Loop = false.  That is the only way to get the animationEvent to trigger.  At the 100th frame (141st key) of her animations, Temechon's trusty animationEvent... triggers nicely, calling pingpong().  As you can see (in the console), I have an error.  Perhaps... I need animationLoopMode_constant... on all 4 animations... which seems impossible to accomplish with the simple Boolean loop parameter of animatables.  Instead, I would need to set the animationLoopMode_constant on all 4 animations  (AND then set loop = false on the animatable).

I invite everyone to have a look, see what can be learned, and try to get this pingpong loop mode... activated.  Have fun, thanks for the input and experiments.  Notice that our rabbit... ends-up "thinking outside the box".     ahem.  Rabbit humor.

[GameMonetize]

So...some comments and fixes:

http://www.babylonjs-playground.com/#1LNWLE#3

- By default, the beginAnimation provides a parameter for a callback on animation end.

- You cannot directly invert keys as frame must still be in an ascendant order

- able cannot be restarted because it was already stopped and remove from scene

 

Hope this helps

[Wingnut]

Thanks Deltakosh!  Well done!

[Rupesh Baghul]

Hi there,

We're relatively newer to babylonJS and trying to work on the animations bit.

So the questions pretty simple,

We want to animate multiple targets together.
Do we need to call begin animations on each target separately or is there another way to call animations by timeline and it animates all the meshes in those key frames?

 

Would really apprecieate any help.

Thanks

[Wingnut]

Hiya RB, welcome to the forum. 

BJS animations allow an AnimationEvent.  These can be inserted into an animation, and used to trigger the start of OTHER animations.  Using these, you could use a MAIN animation as the controller for all SUB-animations.  You could also make a master "timeline" animation that contains ONLY animationEvents.  It would be considered your master sequencer/scheduler.  Here's a playground search for animationEvent, so you have some demo code.

There is another way to do "scheduling".  Take a sniff at this:  https://www.babylonjs-playground.com/#HH1U5#72

Notice lines 150-166.  See those big numbers at the end of those lines?  3000 = 3 secs, 7000 = 7 secs, 13000 = 13 secs (elapsed time since scene.isReady), etc.

And, I think there is another timer called engine.deltaTime.  Here's a playground search for occurrences of that.  You could build an animation scheduler based-upon that, too, I suspect.

Hope this helps.  Others may comment soon with different/better ideas.  Be well.