I am sorry I won't be much help here, I don't use Unity anymore and have no idea how morph targets will work for it. I know that in Unreal the shape keys import with no problem, no idea why the Unity importer wouldn't just give them to you as morph targets.

I have no idea if the .fbx exporter can export the drivers, I only uses drivers to get the animation I need and to pass data from one rig to a other, I have never attempted to export a driver.

I am sorry I won't be much help here, I don't use Unity anymore and have no idea how morph targets will work for it. I know that in Unreal the shape keys import with no problem, no idea why the Unity importer wouldn't just give them to you as morph targets.

I have no idea if the .fbx exporter can export the drivers, I only uses drivers to get the animation I need and to pass data from one rig to a other, I have never attempted to export a driver.

At first I thought that it does not really export the drivers, but somehow bake the vertex deformation into the animation... including vertex deformations caused by the drivers driving the shapekeys.

But then testing it it seems that the Shapekeys, which do get imported as Blendshapes, are not only there, but receiving values from... somewhere. Certainly not from my code. So my guess is now the drivers are baked into the animation as values to set the Blendshapes to at a certain keyframe.

As said, not sure it really is a problem. Given animation Blending works as I think it does (yeah, I am a noob), I just need an animation of the character turning their head in the opposite direction and blend that with the original animation. The opposite shapekey gets triggered in this corrective animation, Driver values get "baked into the animation", the two animation get blended together with the values driving the blendshape... well, I will have to test that later.

Weird anyway to see this working this way in Unity after reading many times that people had to set up the drivers as C# scripts....

But thanks for your help, Scouting Ninja.

When making a rig for a animator, they ask me to add drivers and constraints. However I know that when the model is exported, they remove all the drivers, constraints and IK, because this information doesn't always export or import correctly it depends a lot on the software you use.

All I can recommend is that you check that all animations work with special controls removed, before exporting it. In Blender you can use the "Visual LocRot" option to capture the model as you see it at that frame, removing the drivers and constraints should then not alter the animation.

With .fbx you should capture the animation data on all the bones on the first frame, the fbx exporter ignores bones with no animation or no changes.(My models often loose there toes because I often don't animate them)

If you are in need of motion capture data here: http://www.motioncapturedata.com/2009/04/male-bvh-mocap.html

These are clean but should still be considered raw data, that is you build animations from it and shouldn't use it as is.

Humans get tired so making a looping animations needs some tweaking. Also using the animations on some characters will make the character behave in a feminine way because of the way the body sways, these kinds of things need to be cleaned up on all motion capture data.

Never use shape keys(Morph targets) for rotation animations, they only store direct movement from one point to the other and as such cant rotate around a point.

Yeah, I can relate to removing everything before export after having seen how much problems all these constrainst and IK Setups already cause inside of Blender.

I am currently fighting with getting procedural aniamtions running on top of my exported ones from blender, maybe these constraints are blocking all my attempts?

But most probably I just need to spend more time with Unitys animation classes and learn a little bit more how to juggle all the different ways to blend animations together. After reading different topics on the net it seems the possibilities are staggering (and so is the confusion amongst newbie users)...

Anyway, I'll take a break from animations for now. Will return to some other tasks, trying to setup my speedtrees and working on some environmental stuff. I still need to do a ton of other animations (currently the character is just running and idling), as well as find out why my character doesn't respond to procedural attempts from my scripts. But for now I am happy to have come this far.

As promised, here what I have achieved so far, textured and setup with a basic character controller in Unity:

[attachment=32414:run_animation.gif]

Not perfect, but good enough for the moment.

One interesting question came up yesterday when I talked to a friend about my first steps about animating something in Blender. He asked why I didn't let the Blender physics animate the pouches and grenades hanging from the characters belt (did it by hand with bones).

Well, duh, I didn't even think about the Blender physics (engine?).... is it possible to let Blender calculate the position/rotation of a bone with its physic engine, and capture that position/rotation with "visual locRot" as a keyframe?

Setting up the joints and all might take some time, compare to animating everything by hand it might be worth it though

I don't think it's constraints blocking your procedural animation. I remember that with Unity when I wanted the head to track a target I first needed to stop the bone from animating, it had to stop receiving animation input from the rig before it would target.

Your gif reminds me of the old Commandos games, it's looking good.

You can capture the animations from Blenders physics engine, just remember to check your interpolation in the curve editor it can cause strange problems.

I don't think it's constraints blocking your procedural animation. I remember that with Unity when I wanted the head to track a target I first needed to stop the bone from animating, it had to stop receiving animation input from the rig before it would target.

Your gif reminds me of the old Commandos games, it's looking good.

You can capture the animations from Blenders physics engine, just remember to check your interpolation in the curve editor it can cause strange problems.

Thanks for you answer... yes, I am quite happy how my first try at 3D animations turned out. Not perfect, but not bad for a first I think... as usual, not as quick and easy as I hoped, but nowhere near as much of a pain to animate as I feared :)

Yeah I read something about stopping the bones from animating.... guess that was right. Will read into.

You don't happen to have any expierience in how to also stop the blendshapes from receiving values from the animation? As you said you have never seen this happening before, I guess not, worth asking still I guess :)

Well cannot say the commandos games were that much of an inspiration as I never played them much... but given my current project goes into the direction of commandos (tactical squad gameplay with an isometric perspective), and commandos was THE squad tacticsl isometric game back in the day, it at least draws indirect inspiration from it.

Talking about it now, I definitely should get commandos and play it again... gotta check steam anyway this week, will have a look.

I did struggle with some of the interpolation curves even when doing keyframe animation, had to insert additional keyframes to get the curves back in line. If I understand you correct, I can do this in the curve editor? Interesting, that would certainly save me some keyframes.

Will check the physics engine documentation out... I think that would certainly lessen the work to be done for new animation clips.

I can't remember how you stop the bones from animating and I have no idea how to stop the shape keys, you could remove drivers linked to shape keys I think.

edit: You should look for a head tracking tutorial, it should help you.

If you plan on checking tactical games for inspiration , you should get Jagged Alliance.

There is a weird problem with interpolation in Blender. You can have a person walk up steps perfectly, then a thousand frames later you animate the same character siting down and suddenly it effects the stair climbing animation. To prevent this I convert every finished animation to a NLA action, this way later animations can't effect it directly.

It is a problem the developers know exists and is one of the main reasons that Blender's animation system is getting reworked.