No Assumed Skill: Making and Implementing Your Own Animations with FREE Software

[Papa Lazarou]

This is a tutorial which aims to tell readers how to make new animations and get them working in-game. The tutorial was written for version 1.011 of the original Mount & Blade, but the process will also work for the Warband expansion. I don't pretend that my methods are the best, but if you follow them, you will be able to make and implement your own animations, regardless of your prior modding experience. You can do this even if you know nothing of modding and nothing of animating. I did!

Using the methods detailed in this tutorial, I made the ready positions that can be seen in this thread, as well as the halfsword swing and block on the right side in this video. [And more recently, I used this method to make the animations for my Combat Animation Enhancement Mod for Warband.]

This tutorial is quite long (it took me several days of casual writing), and will be spread over the first 3 posts of this thread.


Part One

Introduction

So, you have no modding or animation ability, no modding or animation software, and no money, and you want to make some animations for Mount&Blade from scratch and get them working in-game? Then this tutorial is for you!

What follows is a set of ridiculously detailed, step by step instructions, written on the assumption that you know nothing about modding and nothing about animating. We will be using FREE software from start to finish (FREE must always be written in capitals). Some of the detail might seem excessive and boring, because I’m writing down every step, and explaining any relevant things that I eventually discovered while learning to get my own animations into M&B. So hopefully you won’t have to deduce as much as I did. Be warned, the process might be a bit fiddly from time to time, but you should be able to do it eventually if you follow the steps. It’s also freaking long, as you can see. It will probably take you several hours, so I’d suggest doing it over a few sessions. If when you're trying it you run into any problems, or something I've left out, let me know and I'll do my best to clear it up for you. Note that this tutorial was written for 1.011, but that it is now possible to make new animations for Warband, and the process is much the same (i.e., if you follow this you'll be able to make and implement animations for Warband). With that out of the way, let's start!

Things you’ll need to have

Firstly, the program I use to make the frames for M&B animations is called Softimage XSI Mod Tool 7.5. It's FREE, as long as you're not making money from the things you make. You can also use other programs (like 3ds Max), but to my knowledge XSI Mod Tool is the best thing for modelling and animating that you can legally get for FREE forever.

NOTE: The forumite Outlawed said that he ran into problems with the 64-bit version of XSI Mod Tool (apparently it does not work correctly with the SMD importer/exporter we will be using). So, avoid the 64-bit version and get another one instead.

You'll also need OpenBRF, the module system and Python. This tutorial will tell you how to set up the module system, and how to get and install Python. You don’t need to know how to use Python, because I’ll tell you exactly what to do with it.

Next you'll need to make your own new module by making a copy of the folder called “Native” in the “Modules” folder. Call your copy “New Animations” or whatever, and put it in the “Modules” folder. When you launch M&B, you should see your module appear in the dropdown list, though obviously it will be identical to Native at this point.

Finally, you’ll need a plug-in for XSI Mod Tool that allows you to import and export “SMD” files. I believe you can get it here. Plugins in XSI are installed in a simple, if slightly unusual, way. What you need to do is open a scene in XSI Mod Tool 7.5 and then drag and drop the file called “ValveSource.6.02.xsiaddon” on to one of the viewports. You will be told that “You need to restart XSI…” to complete the installation. Close, and then re-open XSI. You should now have a dropdown menu at the top of the window called “ValveSource”. It’s from this menu that you will be importing and exporting your animations.

Using OpenBRF to view animations

The first thing to do is make a backup copy of the file called "skeletons.brf", which is in the "CommonRes" folder in your Mount&Blade folder or your Mount & Blade Warband folder if you're modding Warband. Since the "skeletons.brf" file is used by all modules including Native (the standard game), and we'll be editing it (somewhat precariously) using OpenBRF, you really want to have an untouched backup copy of it! If you back this up, it should be impossible for this process to destroy your game - yay.

Right, so now that you've backed up "skeletons.brf", we can open it with OpenBRF and have a look at the animations that are in M&B 1.011. To do this, double click on the "openBrf.exe" that you got when you downloaded OpenBRF. You should get a window with light grey panels on the left, and a darker grey panel on the right. All of the panels will be empty at the moment. Click on "File" at the top left of the window, and select "Open" from the dropdown menu. You should be looking in “CommonRes” (OpenBRF finds this automatically I think, but it's just in your Mount&Blade or Mount&Blade Warband folder). You should see a mass of files ending in ".brf". Double click on “skeletons.brf” to open it.

Make a magical tinkling sound of your choice, and observe that the OpenBRF window is now full of wonders. The panel on the far left should now show a thing called “skel_human”, and have two tabs above it – the open tab is “Skeleton”, and other tab is “Animation”. The panel on the far right displays whatever you currently have selected. Most likely it shows the bones (things which define the shape of the mesh) of M&B’s human skeleton arranged in the T pose. Finally, the middle grey panel should have two boxes – called “Data” and “View”. The “View” box has a dropdown menu labelled “Skin”. Click on the arrow and select “Mesh-set A” (the only option apart from "none"), and the skeleton in the panel on the right should acquire a ghostly set of equipment. Whether you have the skin on or not makes no difference – pick whichever you like for viewing it at the time.

Right, now click on the “Animation” tab near the top left of the window, above the white space on the left panel. I believe the unedited version shows only one animation, called “anim_human”. Left click on this to select it (it’s probably selected already), and you should see the skeleton start doing a bunch of actions. The way the game was made means that all the human animations are together in a single item – the game is told which animation to play when by “interval” numbers which OpenBRF displays in the “Data” box in the middle panel. To see what I mean, right click on “anim_human”, and select “Split via action.txt” – I think it’s the third option from the bottom of the dropdown menu. This operation creates a very large text file (2 gigs), and can take a while. Feel free to skip this step, I'm only getting you to do it because it helps explain the workings of animations in M&B. If you click the wrong thing at this point, just remember to click “Discard” when you close OpenBRF, or you’ll destroy the universe (of M&B). You’ll be discarding any changes you make here, except when you’ve imported a new animation and are happy with it. Never save your work in OpenBRF if you have split "anim_human" - I've never done this but I expect it would break things. To repeat, "anim_human" must remain intact in any saved version of "skeletons.brf" that is in the "CommonRes" folder.

Anyway, after clicking on “Split via action.txt”, a window will open asking you to select the appropriate text file from a module folder (by default I think it will be looking in your “Native” module folder). Double click on “actions.txt” here (or in the new module folder that you created), and you should see that you now have 108 items in the “Animation” tab in the OpenBRF window. A new text file will also be created in the folder alongside "actions.txt" - ignore it. Back in OpenBRF, selecting animations from the list, you’ll see the skeleton on the right performing them in a loop. You can start or stop this, or step through it frame by frame using the buttons in the “View” box, or the “time of frame” thingies in the “Data” box. If you select an attack animation (for example, “anim_human_release_slashright_twohanded”), you’ll see that it has interval information in the “Data” box, which is used to tell the game when to play this animation. (In Python, as you’ll see later, there’s a line that says ‘“anim_human”, 25710, 25734…’ under “release_slashright_twohanded” that tells the game which bit of “anim_human” to play for a two-handed attack from the right.)

We don’t need to insert our animations into this “anim_human” item and use fancy interval numbers to replace things. Instead we’ll be importing our animations (or single animation) so that the list shows “anim_human” as well as whatever else we’ve imported, and then saving the new “skeletons.brf”. That is, we’ll be adding new animations to “skeletons.brf”, leaving “anim_human” untouched. For our module, we’ll then just reference the new animations in Python by name, and by whatever interval numbers we’ve decided to give them. Native will remain completely unchanged, since it won’t be referring to any of our new animations. We’ll be adding things to “skeletons.brf”, then telling our new module to look at them. The things Native looks at will be exactly the same.

Exporting the M&B skeleton so that we can import it into XSI Mod Tool

We’ll export the M&B skeleton from OpenBRF, then import it into XSI Mod Tool. So, open the OpenBRF window and open “skeletons.brf” from “CommonRes”. Look in the “Skeleton” tab, right click on “skel_human”, and click on “Export skeleton with skin” in the dropdown menu. Select “Skin A” when prompted (not that there are other options!), and export it to wherever (I find the desktop is an easy place). Once you have exported it, rename the file so that it ends with “.smd” rather than “.SMD”. For some reason XSI refuses to import SMDs unless the suffix is in lower case (this quirk almost killed me when I first tried importing).

Setting up and controlling the camera in XSI Mod Tool 7.5

Open XSI Mod Tool 7.5. You’ll see the screen divided into 4 camera views. In the top right corners of each view, next to the text that says “Wireframe”, you’ll see a little symbol of a small square inside a bigger square. Click on this. You should now have a single camera view. Now, in the top left of your view, there’s a coloured tab that says “Top” or “Right” or “Camera” or something like that. Click on this and then click on “User” in the dropdown menu. You should now have a nice view of the empty scene with its grid. (This is the view I work with at the moment, but you can manipulate the views however you like and it may help you to use more than one.)

Hold down the “S” key on your keyboard and use the mouse buttons to manipulate the camera. With “S” held down, holding down the left mouse button lets you pan the camera, and holding down the right mouse button lets you rotate it. The mouse wheel zooms the camera, as does pressing the middle mouse button or mouse wheel while holding down "S". Pressing “A” makes the camera look at everything in the scene. Pressing “F” makes the camera look at whatever you have selected.

Importing the M&B human skeleton into XSI Mod Tool 7.5, and manipulating it

Now, in the bar at the top, click on “ValveSource” and then click on “Import SMD…” in the dropdown menu. In the window that pops up, click on the three dots to the right of the field labelled “Import File”. Browse for the SMD that we exported from OpenBRF and double click on it. Now press “OK”. Press “A” to view everything, make another magical tinkling noise, and see that the man from OpenBRF has appeared in the scene with a polygon mesh for skin and a bunch of cross thingies for bones. Note at this point that you can change the appearance of the character – go up to the “Wireframe” dropdown menu at the top right of your view, and check out the various options for viewing the skeleton. After that, set it back to wireframe, and select a bone by clicking on it. If you select the wrong thing, just click, drag and release the mouse in empty space to deselect, or press “Ctrl+Z” on your keyboard (which undoes most things, including selections). With a bone (a cross thingy) selected, tap “C” on your keyboard (without holding it down) and you’ll see some rotation axes appear. The position of the mouse determines how the selected item will be rotated. Hold down the left mouse button and move the mouse and the item will rotate accordingly!

You can also tap “V” to bring up translation axes, or “X” to bring up scaling axes. You’ll notice again that scaling, rotation and translation depend on where the mouse is pointing. For example, you can translate objects on one axis, within the plane of two axes, within the plane of your view, or freely through all axes. Similar variations apply to the other transformations. You'll notice that translation and scaling don't work on the bones of this skeleton, except on the so-called "abdomen" bone.

Note at this point that the mesh (the wireframe stuff) may deform strangely when you rotate a bone – vertices in unrelated areas of the mesh might move and make the mesh look jagged. Also, when you select the mesh, you’ll see lots of coloured dots on the surface, at the corners of the polygons. Technically this doesn't matter - it's just ugly and might make it a bit trickier to picture how the character will look in-game. To fix this, you can try exporting the skeleton (with skin) from OpenBRF again, and importing the new export into XSI Mod Tool. For some reason I had to try several times before it would deform properly. You’ll know whether it’s deforming properly or not just by looking. A working mesh also shouldn’t show any coloured dots when you select it. Save the scene once you find a skeleton that works so that you can just open it again without having to export and import. (But to restate, it's fine to use a dodgy mesh - it shouldn't affect the animation since no mesh-related data is exported later.) I've also uploaded a basic scene with a properly-deforming mesh here.

Note (added 27.7.11) - It turns out that the jaggedness is caused by a problem with the ValveSource SMD importer. I believe there is currently no way to fix the importer, but you can solve part of the jaggedness problem by re-rigging the mesh. To do this, click on the coloured drop-down menu near the top-left of the screen (which is probably labelled "Model" at this point), and select "Animate". Then, select the mesh, click on "Point" in the top-left to make the vertices selectable, and select the vertex that is deforming incorrectly. Then, in the panel on the left, click "Envelope" then "Reassign locally". Click on the bone that you want the vertex to track with, and then right click in an empty spot to confirm the assignment. The vertex should snap into its proper place and then move according to the bone you selected. I think this is only an approximate fix (you'll still get some strange deformation), but it will stop the worst of the jaggedness and you should have no problems animating after making this correction.

Animating in XSI Mod Tool

So we have the skeleton in our scene, we know how to move the camera, and we know how to pose the skeleton. To make an animation then, all we need to do is pose the skeleton for each frame of the animation that we want to make. For attack animations, we’ll only need between 5 and 10 frames, because XSI Mod Tool (and the game itself) will fill in the gaps and blend the frames together to make a smooth movement. More frames will allow you to define the movement more thoroughly.

So let’s make some frames. You’ll see at the bottom of the window there’s a timeline-looking thing. By default I think it goes from 1 to 100. There’s a red vertical line at 1. You can click on this red line and drag it around on the timeline. To see what this is for, set the timeline to frame 1, select the entire skeleton and mesh, press “C” to bring up the rotation axes (but don’t actually rotate anything), then press “K” to set a keyframe. When you select items, red squares will appear on the timeline to show where information for that item has been keyed. By pressing “K” with the rotation axes up, we’ve set this pose (the T pose) for the first frame. Next, move the red vertical in the timeline all the way over to the 100th frame. Now, select a single bone (I suggest a hip, knee, or elbow), press “C” to bring up the rotation axes, rotate the bone about 90 degrees, then press “K” to set another keyframe. Now, press the play button that’s beneath the timeline, make the obligatory magical tinkling noise, and watch the character move smoothly between the two positions.

In fact we won’t be making the animation in such a way that it looks smooth when viewed in XSI Mod Tool. We just want the information for maybe 5 or 10 frames – what those frames look like when played in XSI Mod Tool is irrelevant. The frames we make here will be fed to the game in an SMD, along with information about the timing of those frames so that the game can blend them together properly. For example, for an animation with 7 keyframes, our timeline in XSI Mod Tool would be only 7 frames long, and we would fiddle with the SMD animation file after exporting it to make those frames blend together with proper timing in-game. This is not as difficult as it sounds, and I’ll tell you exactly how to do it later.

When you're actually making an animation, remember a few things. First, you must bring up the rotation, translation, or scaling axes before you can make a keyframe (it will "key" the information for whichever transform you are doing). Second, always key the position you’re working on before moving along the timeline to work on a new frame - the program won't just remember where you left things if you don't key. Third, save your scene all the freaking time, and use multiple saves as you make progress so that you have points to fall back to. When animating, I usually go to the frame I'm doing in the timeline, pose the whole skeleton as I want for that frame, select the whole skeleton (or even everything in the scene), press "C" and then "K" to key rotation information for everything, then press "V" and then "K" to key translation information for everything. This way I don't accidentally move the timeline without keying something and lose my work. Also, I save at the start when I have set up the scene for animating, then I make a "working" save that I can just overwrite to keep updated regularly, and then I also make permanent saves at various milestones (after finishing each frame for example). This method isn't appropriate for all kinds of animation work, and may sound excessive. But, I tell you now, it really makes you want to cry sometimes when you lose 20 minutes of careful posing just because you forgot to key something before moving the timeline, or because XSI crashed instantly to desktop without warning (which it does to me from time to time).

Exporting an SMD animation file from OpenBRF

Shifting gears for a moment, let’s look at SMD files. Open OpenBRF, and open “skeletons.brf”. Click on the “Animation” tab, right click on “anim_human” and then split it via the “actions.txt” file like before. Now, scroll down the list of animations until you find one called “anim_human_ready_slashright_twohanded”. This is the animation that plays when you hold down the attack button for an attack from your right side with a two-handed weapon. Right click on this in the list, and then click on “Export animation” in the dropdown menu and send the file wherever you like (I recommend the desktop). Remember to “Discard” the changes when you close OpenBRF, because we need anim_human to remain intact in any saved version of “skeletons.brf”.

Continued in the next post...

[Papa Lazarou]

Part Two

Reformatting the SMD we exported from OpenBRF, or: stealing my reformatted SMD

REVISION: Apparently this reformatting step is unnecessary with some text programs (including Microsoft Word). I used "notepad" and so needed to reformat my SMD files from Mod Tool. However, forumite mtarini tells me that most text programs will see a nicely formatted SMD already. So, if you use a program other than "notepad", you may find that you don't need to reformat your SMD file after exporting it from Mod Tool.

Now open the SMD animation file that you just exported from OpenBRF. You’ll see a hideous mass of text which extends several metres to the right. Animation files exported from M&B with OpenBRF don’t know how to do paragraphing it seems. So, like a narky forumite, we’re going to reformat this SMD so that it’s easy to read and work with. This will help us later on when we export our new animation data from XSI Mod Tool. In fact I’ll just give you the reformatted version – since we only need to have one properly formatted file from M&B, you don’t need to know how to reformat them. We need it because – at least with the way I do it – XSI Mod Tool exports SMDs with some redundant information, and a nicely formatted SMD from the game can help us fix them up quickly.

So, here’s the reformatted “anim_human_ready_slashright_twohanded.smd”. We’ll use this to tidy up whatever animations we export from XSI Mod Tool – don’t worry if you exported some other SMD from OpenBRF, this one will do just as well.

(click to show/hide)

version 1
nodes
0 "abdomen" -1
1 "thigh.L" 0
2 "calf.L" 1
3 "foot.L" 2
4 "thigh.R" 0
5 "calf.R" 4
6 "foot.R" 5
7 "spine" 0
8 "thorax" 7
9 "head" 8
10 "shoulder.L" 8
11 "upperarm.L" 10
12 "forearm.L" 11
13 "hand.L" 12
14 "item.L" 13
15 "shoulder.R" 8
16 "upperarm.R" 15
17 "forearm.R" 16
18 "hand.R" 17
19 "item.R" 18
end
skeleton
time 0
0 0.002980 -0.048350 9.104100 0.000000 -1.570796 1.570796
1 0.628640 1.089370 -0.408870 3.141591 -0.086538 3.141591
2 4.649140 0.006280 -0.152480 0.000000 0.006659 0.000000
3 4.724810 0.000000 0.000000 -0.000382 -1.565503 -3.141211
4 0.615950 -1.120970 -0.411960 3.141591 -0.081798 3.141591
5 4.669700 0.025960 -0.151690 0.000000 0.020869 0.000000
6 4.698490 0.000000 0.000000 -0.000136 -1.556099 -3.141457
7 1.972170 0.012830 0.000000 -0.030366 0.000000 -0.006836
8 1.985240 0.001840 0.000060 0.006341 -0.000196 0.006335
9 2.705030 0.000240 0.000000 0.008152 -0.000346 0.014506
10 1.758180 0.692770 0.008290 -1.777310 -0.023953 1.647033
11 1.454170 0.000000 0.000000 0.108582 0.052931 0.010999
12 2.770650 0.000000 0.000000 -0.021798 0.032954 0.003188
13 2.720050 -0.001310 0.011070 0.139929 -0.013553 0.017038
14 0.642300 0.121820 0.167370 -0.022679 0.034877 1.539277
15 1.758870 -0.686840 -0.024860 1.773674 0.023954 -1.646038
16 1.454170 0.000000 0.000000 -0.108581 0.052931 -0.010999
17 2.771110 0.002230 -0.003730 0.018988 0.030166 -0.002914
18 2.717440 0.001100 0.009450 -0.126333 -0.000301 -0.023219
19 0.647860 -0.124370 0.170260 -0.010578 0.018687 -1.544341
time 25701
0 -1.005780 0.439990 7.513610 2.868206 -1.532449 -1.822081
1 0.628640 1.089370 -0.408870 2.564335 0.637867 2.805891
2 4.649140 0.006280 -0.152480 0.037756 1.245160 0.035694
3 4.724810 0.000000 0.000000 0.666617 -1.139397 2.383906
4 0.615950 -1.120970 -0.411960 -2.854918 0.087993 -2.627975
5 4.669700 0.025960 -0.151690 0.258195 0.941168 0.207119
6 4.698490 0.000000 0.000000 -0.111493 -1.091705 -2.604735
7 1.972170 0.012830 0.000000 -0.410736 -0.018571 -0.095328
8 1.985240 0.001840 0.000060 -0.448526 -0.023778 -0.186137
9 2.705030 0.000240 0.000000 1.352829 -0.075965 0.262798
10 1.758180 0.692770 0.008290 -2.048966 0.934497 1.395724
11 1.454170 0.000000 0.000000 -1.065424 -0.578745 1.199236
12 2.770650 0.000000 0.000000 -0.203261 0.088308 0.521817
13 2.720050 -0.001310 0.011070 1.101839 0.944529 0.282864
14 0.642300 0.121820 0.167370 -0.100639 -0.021199 1.602711
15 1.758870 -0.686840 -0.024860 2.439766 0.022927 -1.316669
16 1.454170 0.000000 0.000000 1.302205 -0.924201 -1.150749
17 2.771110 0.002230 -0.003730 1.402306 0.002712 -0.216053
18 2.717440 0.001100 0.009450 -0.088075 -0.039083 0.356886
19 0.647860 -0.124370 0.170260 -0.010685 0.019148 -1.546891
time 25711
0 -1.005780 0.439990 7.513610 2.868206 -1.532449 -1.822081
1 0.628640 1.089370 -0.408870 2.564335 0.637867 2.805891
2 4.649140 0.006280 -0.152480 0.037756 1.245160 0.035694
3 4.724810 0.000000 0.000000 0.666617 -1.139397 2.383906
4 0.615950 -1.120970 -0.411960 -2.854918 0.087993 -2.627975
5 4.669700 0.025960 -0.151690 0.258195 0.941168 0.207119
6 4.698490 0.000000 0.000000 -0.111493 -1.091705 -2.604735
7 1.972170 0.012830 0.000000 -0.410736 -0.018571 -0.095328
8 1.985240 0.001840 0.000060 -0.448526 -0.023778 -0.186137
9 2.705030 0.000240 0.000000 1.352829 -0.075965 0.262798
10 1.758180 0.692770 0.008290 -2.048966 0.934497 1.395724
11 1.454170 0.000000 0.000000 -1.065424 -0.578745 1.199236
12 2.770650 0.000000 0.000000 -0.203261 0.088308 0.521817
13 2.720050 -0.001310 0.011070 1.101838 0.944530 0.282862
14 0.642300 0.121820 0.167370 -0.100639 -0.021199 1.602711
15 1.758870 -0.686840 -0.024860 2.439766 0.022927 -1.316669
16 1.454170 0.000000 0.000000 1.302205 -0.924201 -1.150749
17 2.771110 0.002230 -0.003730 1.402306 0.002712 -0.216053
18 2.717440 0.001100 0.009450 -0.088075 -0.039083 0.356886
19 0.647860 -0.124370 0.170260 -0.010685 0.019148 -1.546891
end

Copy this text over the text of your unformatted smd (or into a blank text file for that matter), then save the file as “Reformatted anim_human_ready_slashright_twohanded.smd” or whatever. Import the reformatted version into OpenBRF (in OpenBRF, “Import” -> “Skeletal Animation" -> [the reformatted SMD]), and you should see that it works normally. If it doesn’t you’ve probably made a mistake in your reformatting or when you copy-pasted the text from this post (I checked, and copy-pasting it from here works).

Now I’ll tell you how to interpret it!

Interpreting the content of SMD animation files

This is pretty obvious once you understand it. At the top is a list of the skeleton’s bones (here called “nodes” apparently). You’ll see that there are 20 of them, just like OpenBRF says in the “Data” box, numbered 0-19 (for some bloody reason). Their names are pretty much self-explanatory – for example, “item.R” is the item held in the right hand (the oldschool bastard sword held by the mesh).

Below this list is a line which reads “time 0”. The 20 lines below this refer to the 0th frame of animation. It’s the T pose that skeleton’s stand in by default, and I have no idea why it exists, but it’s in all the animation SMDs I’ve looked at. We’ll leave it here, because it doesn’t hurt, and I don’t know what happens if it’s removed.

You’ll see that the rest of the file is the same sort of stuff repeated. There’s “time 0” and 20 lines of stuff, then “time 25701” and 20 lines of stuff, and finally “time 25711” and another 20 lines of stuff. The last two “times” are actually identical for ready positions (again, I don’t quite know why but we’ll leave it). You can see that these “time” values are the interval values that you can see in the “Data” box in OpenBRF when you look at the relevant animation after splitting “anim_human”. In a full movement with many frames, each frame has a time value. This value tells the game when within the overall animation the frame occurs. So, if you have an attack animation with an interval of 0-10, and some information under the heading “time 5”, the game will put the skeleton into the position defined by that information half the way into the animation. As far as I know, the length of the interval is irrelevant – a longer interval will not make a longer animation. The only relevant thing is the positioning of the frames within the interval. For example, an animation with an interval of 0-10, with frames at 0, 5, and 10 would be identical to an animation with an interval of 0-100 with frames at 0, 50, and 100. After all, the temporal length of the animation is defined elsewhere (and then modified by the weapon speed value and the character’s proficiency). Getting the time values right for your frames is important, because they determine the rate of the various stages of the animation. If this is impossible to understand, don’t worry, it’ll become clearer later when I give an example.

The rows of information under each “time” heading define the positions of the skeleton’s bones within 6 axes – the 3 axes of translation, and the 3 axes of rotation. You’ll see there are 6 columns, 3 for translation first, and then 3 for rotation. Only the “abdomen” bone actually uses translation information as far as I know. If you try translating this bone in XSI Mod Tool, you’ll see that the whole mesh moves with it. You’ll often want to translate this bone, for example when lowering the character’s stance. The other 19 bones use only rotation information. The mesh is not rigged to deform properly when you translate any of these other 19 bones.

As a piece of trivia, the units of rotation used in the SMD files are radians. One hundred and eighty degrees are equal to pi (3.14blah) radians, so 90 degrees are equal to 1.5707… or some bloody thing. This becomes slightly relevant later when we discover that SMD files exported from XSI Mod Tool are off by 90 degrees of rotation in the abdomen!

Exporting an animation SMD from XSI Mod Tool 7.5

Now let’s open up XSI Mod Tool again. We’ll be making a few frames, exporting them as an SMD, tidying up said SMD, and then importing that SMD into OpenBRF. If you get an animation into OpenBRF you can be pretty confident that the game will accept it.

So let’s just make a simple one like before. Indeed we will put this animation in game for lols. And once we’ve done that, you’ll know how to make and implement new animations from scratch! First, move to frame 1 on the timeline, select the everything by dragging a selection box around the whole mesh, press “C” then “K”, then “V” then “K” again. Now the T pose is keyed at frame 1. Next, move to frame 30 on the timeline, select one of the hip bones, press “C”, rotate the bone about 90 degrees, so that the leg is sticking straight out, and press “K” to key this. Now, still on frame 30, select the knee of that leg and rotate it so that the lower leg is pointing towards the ground, then key that. (It may look a bit silly because he’s basically wearing a skirt.) Now move to frame 100, rotate the knee bone so that the leg is straight again, and key that. When you press play, the character should lift his knee, then straighten his leg. It will look extremely unnatural and stupid, and you can fiddle with it however you like, as long as there are only keyframes at 0, 30, and 100. Well really, key however the hell you like, but beware that the detail of my super-specific instructions may no longer apply to you (gasp). Just don’t actually try to animate the movement you want yet, because you need to know a bit more about interval numbers to get the timing right. Save your freaking scene right now. 

Now, if you have things keyed at frames 1, 30, and 100 to make a recognisable movement, click on “ValveSource” in the bar at the top of the window, and click on “Export SMD…” in the dropdown menu. In the window that pops up, look in the “Options” box, select “Skeletal Animation (.SMD)” as the file type, and untick all the boxes below. Then click on the three dots next to the field labelled “File”, name your SMD file (“Test animation” or whatever), choose a location for it (I recommend the desktop), press OK in the browsing window, and then OK in the other window. A little loading bar should pop up and fill, and your SMD should have appeared on the desktop. Double click on it to open it, notice the familiar format and be horrified until you read the rest of this sentence wherein I tell you that we won’t actually be working with this SMD.

Exporting an SMD with only the necessary frame information from XSI Mod Tool 7.5

If you scroll down in the SMD we just exported from Mod Tool, you’ll see that it has 100 “time” values. It gave us all 100 frames of information, instead of just the three keyframes that we need - 1, 30, and 100. Remember, the game blends keyframes together itself – it doesn’t need the intermediate frames. So, we’ll use Mod Tool to shift our keyframes into the 1st, 2nd, and 3rd positions on the timeline so that the SMD will contain only the necessary information.  We’ll then insert the correct time values into the SMD so that the game will blend it together with proper timing.

So, open your animation in XSI Mod Tool 7.5. Select everything and press “0” (zero on the keyboard). Behold the function curves. Be not afraid. Notice the timeline at the bottom of this window. All the colours and positions of the lines mean stuff, but we don’t really care! Drag a selection box from the top to the bottom of the lines (or the bottom to the top if that’s how you choose to live your life), to select them all. They should turn white, and you should see little coloured squares appear on some of the lines at the 1st, 30th, and 100th positions on the timeline. With the lines selected (white), drag another selection box around the squares at the 30th frame. They should turn red and become flanked by black squares. Now press “Ctrl+X” to “cut” this information, move the timeline in the f-curve window to frame 2 (the position immediately after the first set of coloured squares), and press “Ctrl+V” to paste the information in at that point. Now, repeat the process for the information at frame 100, cutting it from there and pasting it in at frame 3. If you find it hard to see things, you can scroll through the f-curve window by dragging the red vertical in its timeline past the visible ends, and you can zoom in and out using the mouse wheel. All the coloured squares should now be above the first 3 frames in the timeline. Now close the f-curve window.

If you select the character now, you’ll see the keyframes are at 1, 2, and 3 on the timeline. When you press play, he’ll snap his leg out like a maniac, but this is okay because we just want the frame information – we’ll be telling the game where to place the keyframes so that they have proper timing. The last thing to do here is to resize the timeline so that it includes only frames 1 to 3. On the far right of the timeline is a dark grey box with “100” in it. Click on this, and enter 3. Done! Your timeline should now have only 3 frames, all with nice little red squares on them when you select the character.

Now, export the SMD for this animation as before. Remember to untick the 3 boxes in the export window. Now have a look in the SMD file. It should look the same as before, but it’ll have only 3 time values. Now we have to reformat it a bit.

Fixing up SMD animation files exported from XSI Mod Tool 7.5

Make sure you have my reformatted SMD from the spoiler in this post, and that you’ve checked that it works by importing it into OpenBRF. (If it does work, you should see the static pose held by the character before a two-handed attack from the right – there will be no actual movement.)

Open the SMD file we just exported from XSI Mod Tool. You’ll notice that its contents are slightly different from the reformatted file. For one thing, it has 22 bones in the list at the top – numbered 0-21 – and 22 lines of bone information for each time value. This is because XSI Mod Tool has given us the information for the skin and an extra node between the feet. This information is strange and incomprehensible and will cause OpenBRF to become paralysed with fear. So we have to remove it and make the file look like the reformatted version. The bones also have funny names, since beings from XSI Mod Tool are all descended from and named after the almighty Thigh. You can probably work out the equivalents of all these names, but you don’t need to.

So to fix it up, open the reformatted SMD that I put in this post, and open your new animation SMD with the 3 time values. In the reformatted SMD, select everything above “time 25701” and press “Ctrl+C” to copy it. Now, in the SMD for your new animation, select everything above “time 1”, and press “Ctrl+V” to paste the stuff from the reformatted SMD over it. If you want to save your new SMD as you work on it, I suggest saving it under a new name in case you make some invisible mistake (my favourite kind). Now your new SMD has a proper list of bones at the top, the T pose information at “time 0”, as well as the information for your 3 keyframes. Now we need to renumber the other time values, and remove the information for the two redundant bones (“0” and “1”, also known as “thigh.mesh” and “thigh” [peace be upon him]). Lastly, we’ll renumber the remaining bones, which are already in the right order, so that they run from 0-19.

So, for times 1, 2, and 3, delete the top two rows of bone information. That is, delete the rows beginning with 0 and 1. Now, acquire carpal tunnel syndrome by renumbering all the remaining rows so that they are numbered from 0 to 19 under each time value. I recommend using the keyboard – replace a number, then use the arrow keys to get to the next row, replace that, and so on. It doesn’t take long once you get the hang of it. Obviously, each number needs to be 2 lower than it is – so 2 becomes 0, 3 becomes 1 and so on. You must renumber them manually, because the information beside these numbers is unique, so you can't just paste over it (though there might be some fancy way of replacing them en masse which I haven’t thought of). Now replace the time values so that the 4 time values for the whole SMD are, in order: 0, 1, 30, and 100.

Don’t freak out about spaces at the ends of lines and stuff like that. As far as I know, SMDs are pretty tolerant of that stuff. I mean, we made some pretty big changes when we reformatted the animation exported from OpenBRF.

Anyway, once you’ve finished tidying up the SMD, save it under a new name (in case you made a mistake). Now import this SMD into OpenBRF, note that the character has been rotated forwards by 90 degrees, and behold the whacky movement!

To fix the orientation of the character, open your SMD again (the one that you just tested in OpenBRF). Copy the “0” line of information from “time 0”, and paste it over the “0” lines in all the other time values. Like I said before, for some reason SMDs from XSI are off by 90 degrees of rotation in the abdomen. Copying the information from “time 0” – the T pose taken directly from M&B – will fix that. You can also subtract 1.570796 (half pi to 6 decimals) from the second column of rotation information in all the frames taken from XSI. You’ll probably need to do this subtraction for more advanced animations, since you may well want to rotate the “abdomen” (really the hips) for some movements. It’s possible that you can also fix the rotation by moving the character around in XSI before exporting, but I haven’t tried that properly.

The hard way to fix the orientation of the character is to change the rotation information for the abdomen bone directly in the SMD. The easy way is to rotate the abdomen bone in Mod Tool backwards by 90 degrees of global rotation. To do this, at each keyframe select the abdomen bone, select global, as opposed to local, rotation in the panel at the right, then hold down shift and move the mouse to rotate the bone in regular steps until you’ve rotated it back 90 degrees. Key this rotation at each keyframe before you export the animation, and the orientation of the character will be correct in OpenBRF and (later) in the game.

In fact, XSI throws off the translation of the abdomen as well. You can probably fix this in XSI Mod Tool like you can with rotation, but at the moment I fix it by going into the SMD and swapping the second and third rows of translation information for the abdomen bone at each frame, and then changing the sign of the second colomn (i.e., make a positive number negative and vice versa). Of course, if your character’s hips don’t move in the animation, you can just copy the information from an earlier row rather than making the same adjustment over and over.

By fiddling with the SMD, then viewing it in OpenBRF, you can work out what rows and columns affect what and by how much – I’ve actually fixed hand positioning and footwork on some of my animations by fiddling with the text of the SMDs directly. (If you haven’t been put off this animation method by now, I’ll make you a batch of cookies or something.)

Test your SMD after doing these fixes (import the animation into OpenBRF), to make sure it works. If the character is upside down or has moved in the wrong direction, it means you rotated the abdomen the wrong way in XSI Mod Tool, swapped the wrong columns in the SMD, or inserted/deleted a minus sign in the wrong place. Just fiddle around and observe the results of each act of fiddling until you work out what does what. It’s all sickeningly logical.

Adding a new, properly formatted animation SMD to “skeletons.brf” so that it can be referenced to appear in the game

Finally! We’re up to the last stage before you can make your own animations from scratch and get them into M&B! For FREE!

Open OpenBRF, and open “skeletons.brf”. Click on the “Animation” tab. The list should show “anim_human” and nothing else, yet. Click on “Import” in the bar at the top of the window, and click on “Skeletal Animation” in the dropdown menu. Select your new, properly formatted SMD that you tested successfully in OpenBRF before. Now, the list should show “anim_human” and your new animation. Click on it and it should play in a ridiculous looking loop. The “Data” box should say that there are 20 bones, 3 frames, and that the interval is 0-99. It subtracts “1” from all the time values for some reason, don’t worry about it. If you move through the “time of frame” thingy, it should show 1 as 0, 2 as 29, and 3 as 99.

If everything is correct here, and “anim_human” is intact, save the file. Don’t change the destination or anything like that, we want to overwrite the “skeletons.brf” that’s in CommonRes.

Using Python to replace an existing animation with our new animation for our new module

This is very simple. Make sure you followed Armagan’s tutorial for setting up the module system so that it targets your new module folder. I recommend that you also backup any Python files that you mess with, and put them somewhere where you’ll know what they are. Though of course, if you set up the module system correctly, Native will be unchanged because the module system will not be targeting the Native folder.

When you’ve done all that, open your module system folder, right click on “module_animations.py”, and click on “Edit with IDLE” in the dropdown menu. I think two windows will open. We’re after the one with the red text and hashes at the top, and we can close the other. You can read the text at the top if you like.

We’re going to replace one of the game’s “ready positions” with our new animation. So, press “Ctrl+F” to search for text, and search for “ready_thrust_onehanded”. Under this is some text that says “[ready_durn, “anim_human”, SOME NUMBER, SOME OTHER NUMBER, blend_in_ready],”. I can’t remember exactly what it says, because I’m looking at an edited version! Anyway, all you need to do is change the text that says “anim_human” here to the name of your new animation that you saved in “skeletons.brf”. Then, you change the interval numbers to the numbers that were shown in the “Data” window of OpenBRF. You can also change “ready_durn” if you wish. This defines the duration of your animation, and I recommend changing it to a specific time (maybe half a second or a whole second), so you can see that interval length makes no difference to animation speed.

You also need to remove the text from the top line that says “acf_parallels_for_look_slope”. This line tells the game that the ready position changes depending on the pitch of the camera. I don’t actually know how to animate so that it will change with the pitch. I think you need to make more animations, one for highest pitch and one for lowest, and reference those somehow so that he game blends between them depending on the camera pitch. Anyway, we’ll just delete it so that our animation will look the same regardless of camera pitch.

So, after all that, the relevant text in Python should look something like this:

(click to show/hide)

 ["ready_thrust_onehanded",   acf_thrust|acf_anim_length(100)|acf_rotate_body|acf_enforce_rightside,
   [1, "Test_animation2", 0, 99, blend_in_ready],

I named my animation “Test_animation2”, as you can see, and gave it a duration of “1” (1 second). This text should be properly formatted – I copied it from my post into Python and it was identical.

Done! Now save the file and close it. Then, in your module system folder, double click on “build_module.bat” to build your new module. Once this has finished, assuming there were no errors, you can fire up M&B and have a look at your new animation in-game. If you replaced the same animation as I did, you can see your new animation by holding down the attack button for a thrust attack with a one-handed sword. It should look quite hilarious.

Conclusion

That concludes this part of the tutorial. Assuming I wrote it properly, you now know how to replace animations in M&B with your own new animations. The same procedure can be used for attacks and ready positions, and you can probably do much the same for other animations, including walk-cycles and so on, though I haven’t made any of these myself.

In the next post, I’ll (more briefly but still comprehensively) show you two methods for animating movements and getting them in-game with proper timing. One of these methods involves making and using visual references and is (luckily for us) essentially foolproof.

[Papa Lazarou]

Part Three

Introduction

In this last part of the tutorial, I’ll be talking about how to actually make a reasonable looking animation. I’ll give a few specific tips, and describe in detail a few general ways of making animations, including how to make and use visual references. (I'd actually recommend reading this tutorial in full before you start, so that you can plan the process properly in advance.)

One way of working is to make your animation by eye, using the timeline normally so that the animation plays smoothly in Mod Tool, and then fiddle with the SMD a bit to put in appropriate time values so that the game blends it properly in-game. In other words, just make the animation in Mod Tool, using as much of the timeline as you like, then condense it down so that the keyframes come one after the other before exporting and tidying up the SMD and putting the keyframe numbers from the full timeline in as the SMD's time values. Or just export the full SMD, delete all the non-keyframe time values, then tidy it up. This way the animation you get in-game will have the same timing as the animation you saw in XSI Mod Tool.

Another way is to make picture references from a video (of a real human – probably you – performing the movement), put them into Mod Tool as textured “grids” of the right size, line them up with the skeleton, line up the camera, and then match the skeleton to the pictures to make each frame. I’ll even tell you exactly how to capture stills for this, since if you’re trying to animate without knowing that you’re probably the coolest ever.

This second method is the one I’ll be describing in detail. At the end of the tutorial I’ll also give some tips for the actual animating process.

Since it's hard to describe in text, here’s a picture of the scene I used when animating the halfsword attack from the video in the first post.

(click to show/hide)

It’s a bit time consuming and might well be laughed at by proper animators, but it’s also a pretty much foolproof way of making realistic and properly timed human animations. Plus, I say it’s time consuming, but once you have the process down you can bust out realistic attack animations in like 3-5 hours of working time [That was at the time of writing - I'm now down to 2 hours in total to make and implement an attack animation]. That includes the whole process, from filming the references to having a realistic animation working in-game. I’d say 3 hours for that isn’t half bad really. Of course, don’t expect your first to be so quick!

Although, to make the process quicker, you can probably just use images from one angle (the front or the side), then just pose the skeleton to match those at each frame, and tidy up the other angle by eye. I’ll talk more about this later, but I’d suggest filming both angles anyway, and probably using stills from both at least for your first animation.


Things you’ll need to make visual references for animating

First, you’ll need a camera and the ability to upload video from it to your computer.

You’ll also need to be able to perform the movement you want to animate (so no flying, and most likely no triple backflips).

Next you’ll need some program to view the video you upload so that you can get screen captures of it at known points within the video. Preferably the video program would have a timeline that can display frame numbers (though time in fractions of a second is sufficient). I now use Adobe Premiere, but I have used Windows Movie Maker before. You could even use QuickTime or RealPlayer or something like that. We just need something to view a video of the movement which tells us an exact time or frame value so that we know where the frame we capture should go in the animation.

Finally you’ll want some picture editing program so that you can tidy up your screen captures. I expect you could do a good enough job with MS Paint. The images do not need to be high quality at all – just enough that we can see the positions of joints and limbs.

Filming the video reference

All you need to do here is film the movement. The most thorough version of this method involves filming the movement twice – once from the front, and once from the side. So, perform the movement once while looking at the camera, and again after turning 90 degrees to the side (try to be exact, but don’t freak out about it). Obviously, the more consistently you can perform the movement, the better (but again, don’t freak out). It also helps to have props that will be clearly visible (for a polearm you might use a broom or dowel, wrapped with A4 paper at each end for visibility. And yes I have done this and you can see how dignified I am). Think about the background and you’re clothing too – it helps if your body has a clear outline. So tuck your shirt in and no baggy pants, you freaking hippie. Or you could do it naked.

For attack animations, I’d suggest that you do not include a large step. If the whole character moves much in the actual attack animation, other things get messed up. A small step would probably be okay – the main thing is that the character should not move very far (that’s what the movement controls are for after all). Also, for attacks, make sure that you stand in the “ready” position for a short time before you start moving. Also make sure that you end the movement properly – I’d suggest pausing at the end for a moment (rather than flowing back into a guard for example). This will make things easier later when capturing stills, and also give you a free ready position for the attack (which, in my opinion, should be a comfortable position that you could hold for a fair while).

You could also stand in the T pose and film that from the front, so that you can scale the pictures easily later.

My advice is to stand far away from the camera, and zoom in a lot so that you fill the frame. Ideally the camera will be positioned such that maximum zoom has you filling the frame. Having the camera far away reduces the harmful effects of perspective and will make things a bit easier when you’re posing the skeleton later. Filling the frame just means that your images will be larger and you’ll lose less detail (not that you need that much anyway).

The idea of this process is to directly copy the movement that you are performing. Therefore, your animation is likely to be only as good as your physical performance [and may be worse, or at least different according to biases in your animation technique - my animations tend to look less committed than my actual performances for example]. Taking attack animations as an example, I’d suggest performing the move as you want it to appear in-game, but at a realistic speed – if it’s too fast for gameplay we can always slow it down in Python later. I’d suggest that you don’t perform the move in slow motion, since that’ll probably just end up giving you a strange looking animation.

Getting images from the video to be used as references in Mod Tool

All we need to do here is take stills from the video at the points which will be our keyframes. That is, we’ll be capturing the stills that will be our keyframes in Mod Tool, the stuff under the time values in the SMD, and the frames that appear in OpenBRF.

There are a few ways of doing this. One way is to just capture stills at regular intervals (for example, a still every 3 frames in the video, or every 100 milliseconds). Another way is to look at the movement (probably stepping through it frame by frame, or in small, regular time units), and decide which frames or time-points to capture at. This second method is the one I used to make the halfsword swing from the right that you can see in the video in the first post. The advantage of the second method is that you ensure that you have certain important parts of the movement – for example, the point at which the weapon is highest, lowest, or furthest to the side, the point where it hits the target, where the hips or other bones start or stop moving, whatever.

Also, I’d recommend capturing about 5 to 10 frames per second. My halfsword swing for instance was made with 7 keyframes, and therefore 7 stills taken from each angle.

If you are capturing from both angles (and I recommend that you do for your first animation with this method), you’ll need to make sure that you’re capturing the same points in the movement. If you performed the move consistently, this shouldn’t be too difficult.

For the actual capturing itself, write down the number of the keyframe for which you're getting a reference (1st, 2nd, 3rd… 10th, whatever), and its position in the video (either in frames or a time value). You’ll need its position in the video so that you can enter the correct time values in the SMD, or so you can animate the move over a timeline of the right length in Mod Tool. If you have no idea how to get stills, you can just press the “PrtScr” or “Print Screen” or whatever button on your keyboard while you’re looking at the frame you want in the video, then open an MS Paint file, press “Ctrl+V”, then save the image.

 I’ll use the example of my halfsword swing to describe this. I had access to frame information when I captured from the video, but time would do just as well. For my 1st frame, I captured the point in the video immediately before I started moving, and I recommend that you do the same. This first frame will be the ready position for your attack, and the first frame of the attack itself. In my video (after I’d trimmed out the excess), this was actually the 3rd frame. Therefore, to get the proper time values for all the keyframes, I had to subtract 2 from their frame number in the video. For example, my 4th frame of animation used a still from the 16th frame of the video. Therefore the time value in the SMD for this frame was 14. I really hope you understand this! (If not, PM me.)

Since interval numbers don’t determine the length of the animation, you can do exactly the same thing with time-points from the video instead of frames. If your first frame for animating was at 500 milliseconds in the video, all you’d need to do is subtract 500 milliseconds from all subsequent frames. Then you’d enter the corresponding values into the SMD as time values. You might get an SMD with time values in the hundreds, but I think it would still be fine as long as their relative positions were the same as in the video (and indeed real life). After all, the duration of the animation is defined in Python (as we saw in my earlier posts).

Make sure that your stills for the keyframes match each other if you’re taking them from both angles as I recommend. So, if it’s an attack animation, make sure frame 1 for both is the ready position, and that the weapon is fully extended at the same frame and so on. Just do your best, it probably won’t match exactly. If the match isn’t very good, just make sure you pick one angle (I recommend the side view) to be the one you follow exactly, and just use the other one to help you tidy it up.

If you edit your picture references (cropping them or whatever), make sure that they all end up the same size, without stretching. This isn’t strictly vital, but will make things easier later for reasons that you can probably imagine. Freaking hell, try thinking for yourself for once. Write down how big they are in pixels – you can see this if you hover your mouse over the files, and I think if you right click on them and look in properties. I'll tell you why later!

Finally, in paint or photoshop or whatever, draw frame numbers onto the corners of your stills (like you can see I did in the picture of my animating scene), so that you know which is which when you’re in Mod Tool. [I now recommend marking each still with its keyframe number, and the number that will be its eventual time value in the SMD.]

Put all your numbered picture references (along with the video) into a known folder. It’ll probably be more convenient if they’re in a folder rather than on the desktop, since there are a lot of them, and they need to stay where they are for when we import them into our scene for animating.

Getting the stills into Mod Tool so that you can match the skeleton to them

Alrighty! We’re past the hard part, and now we just need to import the stills, scale and position them, and start animating! Easy easy easy!

Open XSI Mod Tool 7.5. Open the scene that has the working M&B skeleton in it. In the bar on the left of the window, in the “Get” box, click on the button marked “Primitive”, move to “Surface” in the dropdown menu, and click on “Grid” in the menu that pops up. In the window that pops up, change the “U” length and “V” length so that they are some fraction of the proportions of your images. For example, my images were 1024X576, so I changed “U” length to 10.24, and “V” length to 5.76. Next, change the “Subdivisions” to 1 on both “U” and “V”. Now close the window and you should have a rectangle of the same proportions as your pictures.

Now we’ll texture it. Fear not, it’s easy. Select the rectangle, and click on “Material” in the bar at the side (it’s under “Primitive” that we clicked on before). Click on “Phong” in the dropdown menu. Fancy mathematical techniques are often named after people, like spells in Dungeons and Dragons. I expect that’s what this is. It could be called Phong’s Projection, and would probably make enemies reveal their internal psychological state metaphorically through their behaviour. Anyway, after clicking on “Phong”, you’ll see a window with coloured bars in it and some other stuff. Notice the little fork-looking thing to the right of the top set of coloured bars, and click on it. Click on “Image” in the dropdown menu. A window pops up. Near the bottom is a box labelled “Texture Projection”. Click on “New” next to this, and click on “Planar XZ” in the dropdown menu. Nothing happens! That’s because I forgot to tell you to change the thingy at the top right of the window from “Wireframe” to “Textured Decal”. Do that, and the grid should become multicoloured. (If it doesn’t, repeat this bit from the start with it set to “Textured Decal".) Now, in the “Image” box in the window, click on “New”, then “New From File…”. Now select your first frame (or the T pose if you filmed that), and it should appear on the grid!

Right, now rotate it and move it so that it’s in the right spot relative to the skeleton. Hold “Shift” while you rotate it so that it moves in regular amounts and you can get nice 90 degree rotations. Now press “X” to bring up the scaling axes, and scale the grid on the relevant plane until the image of you is the same size as the skeleton. When scaling, I suggest that you have the grid positioned so that it is very close to or even clipping with the skeleton – this way you won’t mess up due to perspective.

Once you’ve scaled this, we’ll clone it and repeat the texturing process. Then we’ll keep cloning and texturing until we have all the picture references in!

So, if you’ve finished scaling, select the grid and press “Ctrl+D”, then press “V” and translate straight back or forwards. A clone of the grid should slide into existence. Weird things may happen with cloning later (we already knew that I guess) – the clones may appear in different places in the scene, I’ve no idea why, but you’ll just need to move them. Once you have the new grid, just select it and texture it with your next picture reference.

When you’ve done that for both sides, you should end up with a scene that looks pretty much like the picture I posted at the start of this post.

Conclusion, and some tips for animating

So we’re finished! All you need to do now is pose the skeleton to match each picture at the relevant frame in the timeline, keying everything on rotation and translation as you go, and saving all the freaking time. Remember that you can only translate the abdomen – all other bones must be rotated.

Move the stills closer or further away while you’re working with them, and use the lines on the scene’s grid to check that you’re viewing your work straight on. You need to be viewing whatever limb you’re working on in a straight line to match it properly – to reduce perspective effects. This is why you’ll want to move the still up very close to the skeleton when matching. Depending on how you’ve arranged the scene, you can also change the view from “User” to “Front” or “Right” to get an view with essentially no perspective effects. You may want to check this out first actually, so that you can film your reference and set up your scene to take advantage of this view. Personally I don’t use it, because I can just use the gridlines to ensure that I’m viewing things straight on, but whatever, it’s your life.

If you match well, you can slide the still slowly through the skeleton and it will look really freaking scary. I recommend doing this to match the head size and position – you can get your own face into the character’s helmet and it’s hilarious.

Also note that you’ll want to switch between “Wireframe” and “Textured Decal” so that you can select the bones easily and then see the picture to match them.

Just a quick note on anatomy. Try to think about how movements really work when you’re animating. The skeleton works pretty much like a human. For an example, think about raising your arm out to the side. Which bones of your own skeleton are actually moving? Anatomically, if you only move at the shoulder joint, your arm can only go up about 90 degrees, like in the T pose in fact. To raise your arm high, you actually move your collar bone as well. So if we were raising the character's arm high to the side, we'd move the rotate the collarbone (to raise the shoulder) and then rotate the shoulder bone (to raise the upper arm).

For another example, think about a deep(ish) fighting stance. In a position like this, your femurs (bones of the upper leg) are actually rotated outwards. So when animating a leg like this, you’d rotate it at the hip, then bend it at the hip and knee.

 I hope these examples are making some sort of sense, but basically, just try to think about what’s really going on when you move – which joints are actually moving to position a limb, how is the ribcage angled, how is the pelvis angled, how much bend is there in the shoulder, how much rotation in the upper arm, how much in the forearm, etc etc.

Think about these things, but don’t be afraid to break anatomical rules as long as no one can see that you’re doing it. In many of my animations I’ve moved the elbow as if it had a ball-and-socket joint, but no one can tell the difference between that and a rotation of the upper arm (which I couldn’t use because the mesh deformed too much). Also, in Mod Tool, you’ll often rotate the wrist or hand, even though, anatomically, most of this rotation occurs in the forearm.

Anyway, that’s the end of the tutorial. If you have any questions or improvements to suggest, please post. It’s quite possible that I’m doing things inefficiently at various points, or that I’ve been unclear or left stuff out. Let me know and I’ll fix it up.

Happy animating!

[Lumos]

This. Is. Awesome.
Great work and great tutorial.

[ares007]

Yes Awesome.

Once I'm done with a few things, I'll probably try my hand at some animations.

Thanks Papa, I think a lot of people will appreciate this (maybe should be stickied?)

[Arch3r]

Very nice, awesome tutorial.

[Lord Leoric of Wercheg]

Bookmarking. Just in case I want to try my hand at animations.

Thanks for the tutorial.

[Papa Lazarou]

Thanks everyone! I half expected to be told it was redundant.

Glad you found the thread, Ares. I forgot to PM you again haha.

[Wu-long]

Yes Awesome.

Once I'm done with a few things, I'll probably try my hand at some animations.

Thanks Papa, I think a lot of people will appreciate this (maybe should be stickied?)

+1 Very awesome now i can try it thanks a bunch

[Buziah]

Awesome! I'll have to try this on friday.

[CryptoCactus]

This looks like a badass tutorial. I always assumed animation was just one of those things I should never even try, but this kinda makes me feel like I could do it.

[Papa Lazarou]

You totally can! It took me like a week of casual fiddling to learn (including figuring out hellish things from scratch), and I got better at working with skeletons just by practising. If you follow my tutorial you should be able to animate in no time.


I've posted the final part of the tutorial, in which I describe my own method for making human animations. This involves making visual references for each frame, getting them into Mod Tool, and then matching the skeleton to them. It's in the third post in this thread.

Merry Christmas!

[AWdeV]

Shit, this is awesome. Great stuff, I'll try it out right away! 

Wait crap, it says a three button mouse is a minimum requirement for the autodesk gizmo but I've got one of those rollerball things. Does that still work?

[Papa Lazarou]

You should still be able to use it with a mouse that has only two buttons and no wheel.

The third button or mouse wheel is used for zooming the camera. I can only imagine that you must be able to recalibrate the controls, so that a button on the keyboard would allow you to zoom. I'll look in to this a bit later.

[GetAssista]

Many thanks, Papa! This is some awesome piece of work