Abrupt animation transitions

[zoot]

Currently, transitions between animations are very sharp, like so:

Would it be feasible to make smoother transitions, preferably without having to make a ton of new animations (one for each pair to transition between)? Perhaps with some IK?

[Pureon]

I can't think of an easy way to fix this, but the case above is caused by the deer going from an idle state to a movement state.

[quantumstate]

I think IK would be unnecessary for this. A simple blend between the two states with forward kinematics should be enough, I think this should work ok without hitting nasty things like singularities. It would need some significant changes to the animation code however. Zaggy was interested in having the possibility of manual transition animations as well, I think there is a rough patch on trac for this.

[historic_bruno]

The animation system should support interpolation between the last frame of one animation and the first of another, along with a specified transition time. That is for cases where a custom transition animation isn't needed, for anything more complex (an animation state machine), I would like to see the logic moved out of UnitAI if posible.

[Pureon]

The animation system should support interpolation between the last frame of one animation and the first of another, along with a specified transition time.

That's an interesting suggestion. It might not work for animations such as wheel rotations (they may interpolate the wrong way), but for skeletal movements like those above that could work sufficiently well.

I don't see this as a high priority issue to fix though. I would much rather see turning circles added for siege units and ships - http://trac.wildfiregames.com/ticket/940

[zoot]

Zaggy was interested in having the possibility of manual transition animations as well, I think there is a rough patch on trac for this.

Any idea where this patch may reside? I only found this ticket, but no patch: http://trac.wildfiregames.com/ticket/1195

[quantumstate]

That's an interesting suggestion. It might not work for animations such as wheel rotations (they may interpolate the wrong way), but for skeletal movements like those above that could work sufficiently well.

I don't see this as a high priority issue to fix though. I would much rather see turning circles added for siege units and ships - http://trac.wildfire....com/ticket/940

With sufficiently clever maths (not particularly clever) it should be possible to use the shortest transition, so with a wheel there may be 1 rotation of 30° and another of 330°, the correct choice here is clearly 30°.

[Pureon]

Any idea where this patch may reside? I only found this ticket, but no patch: http://trac.wildfire...com/ticket/1195

It was committed I believe. See the peacock.xml actor file and its idle_transition, feeding_transition, and walk_feeding animation states.

[zoot]

It was committed I believe. See the peacock.xml actor file and its idle_transition, feeding_transition, and walk_feeding animation states.

Oh, nice. I wonder what those animations transition to, though. Maybe some generic pose.

[Pureon]

Oh, nice. I wonder what those animations transition to, though. Maybe some generic pose.

I believe so, yes. It's not an ideal solution because it requires so many animations. Interpolated transitions would be preferred

[leper]

I think #1192 is related to that, but the idea/system explained in #1195 is better.

[Zaggy1024]

Pureon: I never committed any code to make the peacock have transitions. That's what the patch in the ticket leper mentioned is supposed to do. The XML in the peacock's actor isn't the way I'd want it to work, though.

The XML in ticket #1195 is more ideal, but since then, I've come up with better ideas about how it should be done (which will hopefully make basically anything possible with respect to animations, except automatic transitions): Actors should choose a JS script to control what animation is playing, using some variables of the unit (like what state the unit is in, and what state it used to be in). I'll come up with an example of how the code would look later if you guys want one.

[zoot]

I'll come up with an example of how the code would look later if you guys want one.

Yeah, please do.

[Pureon]

Pureon: I never committed any code to make the peacock have transitions. That's what the patch in the ticket leper mentioned is supposed to do. The XML in the peacock's actor isn't the way I'd want it to work, though.

So just to be clear, the transition states in the peacock's current actor file aren't functional?

If there's a way to make the transitions less abrupt without requiring new animations (which we don't have the time or manpower to do), that's what we should go for.

[Zaggy1024]

So just to be clear, the transition states in the peacock's current actor file aren't functional?

Yep.

If there's a way to make the transitions less abrupt without requiring new animations (which we don't have the time or manpower to do), that's what we should go for.

Definitely, but having a script able to control which animation is playing would be extremely useful too.

About the peacock's XML, "feeding_transition" is a transition from idle to feeding (which, for the peacock, is actually showing off), and "idle_transition" is from feeding to idle. The "walk_feeding" animation is just the peacock walking while "feeding".

An example of what I have in mind for the script may take a while, because I have studies to do, but I'll try to get it done as soon as I can.

[Zaggy1024]

Bump. Sorry, guys, I totally forgot I was going to post on here (which is funny because I was excited to see what you guys thought of my idea).

Actor XML:

<?xml version="1.0" encoding="utf-8"?>
<actor version="1">
<castshadow/>
<group>
  <variant frequency="100" name="Mesh">
   <animations>
    <animation file="quadraped/peacock_idle.dae" name="idle" speed="15"/>
    <animation file="quadraped/peacock_idle_transition.dae" name="idle_trans" speed="60"/>
    <animation file="quadraped/peacock_feeding.dae" name="feeding" speed="15"/>
    <animation file="quadraped/peacock_feeding_transition.dae" name="feeding_trans" speed="60"/>
    <animation file="quadraped/peacock_walk.dae" name="walk" speed="25"/>
    <animation file="quadraped/peacock_walk.dae" name="run" speed="30"/>
    <animation file="quadraped/peacock_walk_feeding.dae" name="walk_feeding" speed="25"/>
    <animation file="quadraped/peacock_death.dae" name="death" speed="75"/>
   </animations>
   <mesh>skeletal/peacock.dae</mesh>
   <textures><texture file="skeletal/animal_peacock.png" name="baseTex"/></textures>
  </variant>
</group>
<group>
  <variant frequency="100" name="Idle"/>
  <variant name="death">
   <props>
    <prop actor="props/units/blood_01.xml" attachpoint="root"/>
   </props>
  </variant>
</group>
<material>basic_trans.xml</material>
<anim-scripts>
  <anim-script order="1" feedingTime="3" feedingTimeRandom="10">feeding_transition.js</anim-script>
  <anim-script order="2">auto_transition.js</anim-script>
</anim-scripts>
</actor>

The "order" value in the <anim-script> tags is to tell which order to fall back to others script in (this may not actually be workable, but it would save code if it is).

Script:

var transTimer = new timer()
transTimer.reset()

var prevState;
var state;

var feeding = false;
var feedingTime;

function getAnimation(actor)
{
    var variant = actor.getVariant(this.variant);

    if (feeding) {
        if (state == "idle") {
            if (feeding) {
                if (transTimer.getTime() < variant.getAnimation("feeding_trans").getLength()) {
                    return "feeding_trans";
                } else {
                    return "feeding";
                }
            } else {
                if (transTimer.getTime() < variant("idle_trans").getLength()) {
                    return "idle_trans";
                } else {
                    return "idle";
                }
            }
        }
    }

    if (!feedingTime) {
        feedingTime = getAnimationValue("feedingTime") + math.random(getAnimationValue("feedingTimeRandom"));
    } else if (transTimer.getTime() > feedingTime) {
        transTimer.reset();
        feeding = !feeding;
    }
}

function onStateChange(unit, actor)
{
    prevState = state;
    state = unit.getState();
}