Jump to content

Parallel animations blending


Recommended Posts

Hello guys,
I'm moving on with my scene and I got stuck on skeleton animations. I have situation when my soldier model is running and while running animation is playing (or any other animation) he is being hit. The results of such situation is that running animation is stopped and hit animation starts playing, while my model is still moving forwards. So I have few different options here:

  • Stop model movement and continue run animation when hit animation finishes
  • Blend two animations with different weights. I know that this is possible with Three.js' animation mixer but I could not get it to work with babylonjs is this even possible?
  • Any other thoughts?

I was going thought this forum but I only found topics on blending when one animation changes other animation.

Link to comment
Share on other sites

Luknei, was your question answered?

I think Deltakosh was talking about blending SERIAL animations, and you are talking about blending PARALLEL.

Perhaps parallel animation blending is not yet possible, in BJS.

Let's look at your example.  Pretend player is running, and has classic arm movements of a runner (arm swing opposite each other).  THEN... arrows start arriving, and running player must raise shield to block arrows.

When it is time for player to do the "raise shield animation", you would start that animation.  But another animation is still running... which is the "running player animation".

You will now have two animations doing a tug-o-war over WHICH animation is the boss of the arm.  The running player animation... wants to move the armature ONE way.  The "raise-shield animation " wants to raise the arm/shield to block inbound arrows.

You want the two animations to "average" or "share" the arm bones.  But, I do not think you will like the results... attempting to do this.  I think... if two animations are fighting over the same bones, both arm animations will not be smooth.  It will be a "mix" (blend) of running arm... and shield-raising arm, and it might look like crap.  :o

If I were a game coder... (I'm not), I would write a "player running animation"... with NO arm bone animations at all.  Then, swap in/out... separate arm-bone animations.  Sometimes you will do the shield-raise/shield-lower animation, and when not doing that, somehow restart the "running player" arm animation, and somehow try to sync it with the already running-player animation.  That re-sync will likely be a "challenge"... to do.  Got aspirin?  :)

Generally, a running player's arms are out-of-phase (moving opposite directions).  When left arm is forward, right arm is back, and the opposite, too.  SO... when it is time to end the shield-raise/lower animation, then (if possible)... you will start monitoring (watching/peeking) the position value... of the OTHER arm. 

Let's pretend we are raising the shield with the RIGHT arm. 

When the LEFT arm is forward all the way, THEN re-start the "running player right arm" animation (in the arm-back position).  After that, the two arms are should be animating opposite-of each other, once again.  The two arms of the running player... returned to proper sync... because your "animation manager code" waited for the left arm to be fully forward... and THEN re-started the right arm running animation.  Perfect "arm animation" insertion/injection.  :)  Soon you will have 5,10, 20 different "arm bone animation modules"... and your animation manager can swap them in/out at lightning speeds and ease. 

Luknei's Arm-bone Animation Modules, Inc.  Each 200 frames, plug'n'play into any Luknei Limp-Armed Skeleton/Armature.  :)

Does this make any sense?  I could be COMPLETELY 100% wrong, too... totally full of crap.  Been there, done that.  :)

But, I thought there might be a misunderstanding about "What is blending?"  (and about serial blending vs. parallel blending).  Not sure... just checking.  Party on, guys!

Link to comment
Share on other sites

That might be difficult, @Deltakosh.  We have no facilities for @luknei to repro this.  The QI system might be the closest we have, and it is barely alpha, I suspect.  I will attempt to describe, using common example.

While player-is-walking animation:
Possibility#1:  player's arms gently swing at player's side - no weapons.
Possibility#2:  player's arms gently swing at player's side - holding sword and shield.
Possibility#3:  one arm... animating to position where shield can block inbound shot.  Other arm swinging.
Possibility#4:  one arm... animating to position where sword can block inbound shot.  Other arm swinging.
Possibility#5:  both arms raise sword and shield to block shots from two directions

Now... SAME 5 possibilities are needed when player is RUNNING.  Running is a different animation from walking.  Legs change shape differently and arms are bent at elbow and are "pumping" and not "swinging".

AND... the same 5 possibilities with... perhaps... "trotting" (a slow run).

This is why I thought @luknei should use 2-3 primary animations... one running, one trotting (if needed), and one walking... but all with NO ARM ANIMATION. Then, plug'n'play the arm animations.

This is NOT parallel blending, or QI, but it is "hot swapping" the arm animations.  Sync would be a challenge... when hot-swapping arm animations.  Luknei would always have 3 animations running at the same time.  1. legs/body animation (cycling), 2. left arm animation (cycling if not raising/lowering a weapon), 3. right arm animation (cycling if not raising/lowering a weapon).  The arm animations would need to be "swapped-out" for every arm-event trigger.

Not an easy thing to show in a simple playground scene.  :)

Luknei, I think QI (Queued Interpolation) will be your solution, when it is ready.  POV is rather interesting.  I'll invite @JCPalmer to make sure I don't say stupid/wrong things, here.  :)

POV stands for Point Of View... and the animations done with Queued Interpolation (QI) are POV animations. The movements are a deviation-from the normal point of view of the mesh/bone being animated.  In other words, the values in an eventSeries... are "differences from normal position" or "differences from normal rotation" (or scaling).  NASA would call these "deltas"...  something different from the normal... a tweaking... an offset from normal... an adjustment... a bias.

So... let's pretend your walking left-arm animation... takes 10 frames to move from straight down... to maximum forward swing.  Then another 10 frames to return-to straight down, then another 10 frames to swing backwards, then another 10 frames to return to straight down again.  One entire arm-swing requires 40 frames. 

Now pretend your raise/lower-shield arm animation requires 10 frames to raise, is held raised for 20 frames, and 10 frames to lower. 

Here, you have a perfect syncPartner-able eventSeries.  Since the shield-raise/lower animation takes exactly the same amount of frames as one walking-arm swing, it is easy to program the eventSeries.  No need to swap-out the entire skeleton animation just to raise and lower a shield.  Instead, you would parent the shield to the player hand-bone, and then "run" the QI eventSeries named "shieldRaiseHoldLower"...  a pre-programmed series of (delta/offset) values to ADD TO the normal arm-swing animation.  It is an "on-the-fly" adjustment to the normal animation, calculated from the original animation's point of view.

How was that, JC?  Did I make a mess of introducing the QI system and way of thinking?  I hope not.  I hurt my OWN brain, doing it, though. heh.

Those that learn to drive POV animation eventSeries and QI... will have the best skeletons, ever.  We have NEVER seen computer-operated puppet strings... like these.  :)  I hope I've helped someone.

Link to comment
Share on other sites

Sorry for not responding for so long. I solved my problem with changing game logic a bit, to not get stuck on this problem.
I'm using serial animations blending and it works fine, but i was talking about parallel animations. I found Three.js demo of such thing: https://threejs.org/examples/webgl_animation_skinning_blending.html


Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...