animation Arcturus' animations

[Sotha]

Impressive! Well done!

[Arcturus]

Thanks.

New 'pain_torch' animation:

 

[Springheel]

That's only for AI without a weapon drawn?

[Arcturus]

All pain animations start with idle pose, so there are no special 'pain' anims for alerted guards. Also, alerted NPCs play pain animations only when they don't see you. When they do, they just hit you back until the fight is over.

There's also 'pain_torch2' which is almost identical to the first one, so I might also remake that one.

[Springheel]

Also, alerted NPCs play pain animations only when they don't see you.

 

True, but if you're shooting arrows at them from the dark, they'll play their pain animation when their sword is drawn. I had to change a lot of the pain animations originally to keep AI from shoving their sword through their head when hurt.

 

Btw, just saw the new kneel animation in game, and it looks fantastic! The guard looked like he was actually putting his hand right on the body of his friend while kneeling.

[Arcturus]

Yes, I made sure that sword doesn't go inside the body. Torch version is the same animation, only left hand is different.

[Sotha]

Hm. I wonder if that pain anim could be used as a base for new "blinded" anim?

 

Presently (or actually in the previous version of TDM, haven't examined this since), if AI is blinded they do the following:

walk one or two steps holding hand before their eyes, then stand at stare in idle anim until blindness wears off. Looks very strange when they just calmly idle-stand to wait their vision to return.

 

If this anim was modified so that the AI covers their eyes and rubs them a bit, it might work well.

[Obsttorte]

The anims shown in the videos are definetely an improvement, but seems more like the default animation just running faster. I don't want to play the devils advocate, but it still looks pretty unrealistic imho. Like a slow motion step dance thingy.

[Arcturus]

Currently there are two basic "walk" animations that game picks at random. Walk1.md5anim wasn't made by me. When game switches from idle animation to a walk animation there's certain number of frames when the game blends between the two. Because that particular animations starts at the most extreme pose...

...when animation starts, the right leg quickly slides back:

Simply shifting the cycle so that animation starts at a different pose...

... results in a less jarring transition:

 

[I.C.H.I.]

If you ask me the main problem with animations in TDM in general is that they all look mechanical/robotic/wooden/stiff. So tweaking some frames here and there won't make them look drastically better. The full redesign from scratch is needed. And even if it can take 5 or 10 years it is better to replace them all with something based on the actual motion capture.

Just check this site and see how much better it may look if done right:

https://actorcore.reallusion.com/3d-motion/free

[Arcturus]

@I.C.H.I. 

What I wrote in the previous post would apply to motion captured animations too. In the end they are just a bunch of keyframes, not magic.

You'll be happy to hear that we already have one mocap animation in game already:

It's so heavily edited though that it might as well be original.

Motion captured anims still need to to be heavily edited. They generally need to start and end on the same pose, unless you're doing a cut scene. Animations need to fit arbitrary criteria set by the game, like a predetermined speed. I was told for example that running needs to feel like sprint, when actual in game speed is that of a jog.

Current TDM skeleton is different from a typical standard animation skeleton. It was made in a proprietary software and it took me a lot of effort to retarget it to a rig in Blender. I made it based on imported md5mesh file. Perhaps retargeting the original rig inside Maya would be an easier task.

A lot of bad animation is driven by game systems. The reason why NPCs will sometimes rotate 180 degrees while playing some idle animation is just bad code. The reason why rotating animations look like shit at the moment is because origin bone is driven by code and the speed simply doesn't match the animations.

Well that and the animation is horrible.

Changing rotation speed in code breaks combat, so I'm trying to make animation that matches the code, which is a hack.

Feet still slide because of blending. Without blending it looks like this:

There's still some jittering going on. Any idea why? For details I invite you to internal development forum.

Another example is combat where torso and legs are independent. Combined with crappy animations it makes probably for the most robotic looking part of the game.

A lot of it is just bad art. The default idle animation is just crap. The pose is unnatural, weight is placed on the leg that has a bent knee and is moved back and on top of it has a weird rotation. That's not a relaxed pose, but because it's the default, all other animations need to start and end with it. At least the mechanical looking sway of the idle anim à la Mortal Kombat could be fixed at some point.

Ideally all characters should be ported to a standard rig like Rigify or Blenrig. The rigging itself wouldn't even be the worst part for me. It's setting up .def files and articulated figures (AF) that's the most tedious part. You're expecting a lot from a community who refuses to switch to high dynamic range rendering, even though that shit is already implemented in the game waiting to be used.

I might experiment with mocap more at some point, but I encourage you to try it on your own. When I started working on this mod I new nothing about 3d graphics. Three years later I had a horse completely modeled, textured, animated and with proper rag doll in the game.

 

[Arcturus]

I uploaded "walk.md5anim" animation with fixed elbow issue mentioned here. I managed to completely fix chain clipping on priest's model:

This character's coat is still slightly clipped.

 

"walk1" for comparison:

There are 8 joints in the skeleton for animation of coats.

[Wellingtoncrab]

@ArcturusNot sure what sort of feedback you’d like, but personally I don’t see an issue with you committing things which amount to animation bug fixes, such as the turning one form the dev thread (which I understand is not a perfect fix) or like the walking one above, to the game.

It’s just nice to have someone working on them frankly. And I think them going into dev builds is the only way we will get any kind of scale testing on them.

[datiswous]

On 9/29/2025 at 2:56 AM, Arcturus said:

For details I invite you to internal development forum.

You don't know that non-devs have no access to that forbidden place?

Edited September 30, 2025 by datiswous

[datiswous]

It seems like in the turn/rotate animation the body already rotates at the same time the step is being made (I could be wrong). But it might look better if the feet turn first and the body slightly later.

[datiswous]

On 9/29/2025 at 2:56 AM, Arcturus said:

Changing rotation speed in code breaks combat,

Is it maybe possible to use old animation code only in combat (for now)?

[Arcturus]

@I.C.H.I. I apologize for my little rant.

I take back what I wrote. Turns out, mocap is easy after all

Animations come from: https://www.rokoko.com/mocap/free-mocap-assets

Retargeted in Blender using this addon: https://github.com/Mwni/blender-animation-retargeting

I took my Blender rig for darkmod NPCs and stripped away all constraints. For this demo I used .fbx from the pack with Mixamo skeleton, and manually set up the bone mappings.

I made a separate thread.

On 9/30/2025 at 1:31 PM, datiswous said:

You don't know that non-devs have no access to that forbidden place?

Yeah I know

On 9/30/2025 at 1:52 PM, datiswous said:

Is it maybe possible to use old animation code only in combat (for now)?

I think I will prepare those new animations and let other people decide if that's enough.

[Wellingtoncrab]

@Arcturuswow that awesome and opens up a whole lot of potential!

[Bikerdude]

7 hours ago, Arcturus said:

@I.C.H.I. I apologize for my little rant.

I take back what I wrote. Turns out, mocap is easy after all

WOW!

[chakkman]

On 9/30/2025 at 4:29 PM, Arcturus said:

@I.C.H.I. I apologize for my little rant.

I take back what I wrote. Turns out, mocap is easy after all

Animations come from: https://www.rokoko.com/mocap/free-mocap-assets

Retargeted in Blender using this addon: https://github.com/Mwni/blender-animation-retargeting

I took my Blender rig for darkmod NPCs and stripped away all constraints. For this demo I used .fbx from the pack with Mixamo skeleton, and manually set up the bone mappings.

That's brilliant. Hope some of that ends up in the game.

[Arcturus]

 

[Arcturus]

Notice that NPCs falling to their death make no sound at all. They not only don't scream, but also make no sound when hit the ground. When player drops a body on the ground there is a sound, so it's weird that when NPCs fall on their own there isn't any.

Finished new "idle_turn_90" left and right animations.

I had to set blending to "0" in tdm_ai_base.script file in section:

void ai_darkmod_base::Legs_Idle()

animState( ANIMCHANNEL_LEGS, "Legs_TurnLeft", 0 );
animState( ANIMCHANNEL_LEGS, "Legs_TurnRight", 0 );

With current blending set to 4 frames it looks like this:

It's still buggy, but I don't know how to improve it further.

Origin bone is driven by code. There is also some code that synchronizes legs and torso. Theoretically you could set different blending for torso and legs but I don't know how.

I can commit those changes and let people test it.

[Arcturus]

Uploaded to repository. Blender's md5 exporter writes ton of unnecessary data, hence md5.anim files exported from Blender are multiple times heavier than needed. I wonder how that affects animations that are driven by code, like in this case.

[Arcturus]

Slowest "turn_rate" in tdm_ai_humanoid.def that doesn't break combat seems to be around '135". This is what it looks like with animation that matches the rotation exactly without any workarounds:

Blending set to "4".

[Arcturus]

We shouldn't turn off animation blending. Without it there's annoying jump from one animation to another. We need more blending, not less.

Let's do a different hack. The problem is that origin bone rotation is driven by code and it finishes rotation in 1/3 of a second. We can't make it significantly slower without messing up AI. My first hack was to simply make character move slower than origin. So the origin would finish rotation, stop and then the character would continue moving for the rest of the animation.

But we can animate the origin bone too. Since we want the origin rotation to be longer, we can counter-animate it. So while the game code rotates it 90 degrees one way, we can apply rotation in the animation file the other way to counter it. So we end up with 90-60=30 degrees movement for 1/3 of the animation. Then when the code stops moving the origin, the animation file can continue rotating it for the remaining 60 degress.

We end up with this stupid looking animation:

In the game however origin now rotates for the whole duration of the animation (1 second).

This is what it looks like with blending set to "0" in

float delta = getTurnDelta();
if ( delta > 10 && hasAnim(ANIMCHANNEL_LEGS, "turn_left"))
{
animState( ANIMCHANNEL_LEGS, "Legs_TurnLeft", 0 );
}
if ( delta < -10 && hasAnim(ANIMCHANNEL_LEGS, "turn_right"))
{
animState( ANIMCHANNEL_LEGS, "Legs_TurnRight", 0 );
}

Here's with blending set to "4" (current Dark Mod default). There's some jerkiness.

I applied some more tweaking in Blender to mitigate some of that:

With blending set to "6":

Those values in:

animState( ANIMCHANNEL_LEGS, "Legs_TurnLeft",4

etc., they seem to drive only the "ease in"? I'm a little confused about how they work.