How does it do that then? Advanced animation techniques for X-Plane object development.

A tutorial by Propsman

I'm discovering that the process of analyzing one’s own work for the purpose of writing about it can be quite revealing. I have found myself wondering why on earth I did some things the way I did when I know at the time it all seemed perfectly clear and logical to me! Ah well, we are always wiser with the benefit of hindsight. I think it’s probably better not to change things half way through this tutorial, but I’ll mention the alternative methods at the relevant moments, if only to save you from wondering why I chose to make things difficult for myself!

So let’s take a closer look at this back axle assembly (f igure 2.0).To recap, we have an armature with eight bones, two which revolve the wheels, two which rotate the back axle around the z-(longitudinal) axis, two which rotate the axle around the x-(transverse) axis centred on the front spring attachment lugs, and two which rotate the prop-shaft around the x-axis where it joins the differential housing. In hindsight it would have been simpler to dispense with the third pair of bones, and just add a vertical translation to the second pair of bones instead - in fact the resulting motion would have been more accurate, but this system we have works too, so we’ll persevere.

PART 2

vertical axle motion

axle rotation

wheel rotation

prop-shaft rotation

Figure 2.0

By the way, I tend to think in terms of X-Plane object-format axes - i.e. with a vertical y-axis - even when working in blender, which uses a vertical z-axis. This can get a bit confusing at time admittedly, but I find it less confusing then having to jump from one system to another when switching between blender and text-editing the object. While working in Blender, I just use whichever axis looks right. I know that it isn’t very systematic, but it works for me. Therefore, in this tutorial:

wheel rotation

red is

the x-ax

is

gree

n is

the

y-a

xis

blue is the z-axis

Why pairs of bones?

Why do we need two bones to rotate something around a single axis? The reason is that the most convenient way of attaching a dataref to a bone is to name the bone after the dataref, which is the method Marginal uses in his export script. Obviously a bone can only have one name, so if we want to use more than one dataref to animate our axle, even if it is an identical transformation like we have here, we must use more than one bone, and join them together. The situation doesn’t arise that often anyway, so the system works perfectly well.

Building the armature

Once we’ve decided on what bones we need, we can add our new armature, I’m assuming that you’re familiar with the basic techniques of adding bones, so I’ll just add a few tips which you may find helpful. Although it isn’t essential to do so, I find it’s convenient to move each object’s centre to the point about which it will rotate, by locating the cursor at that point and in object mode pressing the ‘center cursor’ button. Then, when it comes to building the armature, we can add bones in exactly the right place by first selecting the object and typing SHIFT - S - 4 to snap the cursor to the object’s centre. I don’t always remember to do this, and the results are long dotted relationship lines stretching across the screen... Always make sure that your view is aligned to (or perpendicular to) the axis of rotation of the object before adding each new bone so that it’s easy to manipulate them when it comes to posing the armature.

Another practice I find helpful when attaching multiple bones to one object is to align them in opposing directions. I used to align them all in the direction of the next ‘joint’ in the armature, but it makes selecting the different bones rather tricky, since they’re all lying on top of one another. So now I have them point in whichever direction makes them easier to grab and manipulate. Also, selecting ‘x-ray’ in the buttons/object/draw tab makes them much easier to see behind all the mesh.

Naming the bones

Once we’ve added our bones, we need to name them, and for that we need to know what datarefs we’re going to use. For the back axle, we’re going to use the following four datarefs:

sim/flightmodel/parts/tire_vrt_def_veh[2] … … … the vertical compression of the .acf strut for wheel #2sim/flightmodel/parts/tire_vrt_def_veh[3] … … … the vertical compression of the .acf strut for wheel #3sim/flightmodel/parts/tire_prop_rot[2] … … … the angular displacement in degrees for wheel #2 (i.e. How far it has turned around it’s axis)sim/flightmodel/parts/tire_prop_rot[3] … … … the angular displacement in degrees for wheel #3

Thankfully, Marginal’s script makes things easier for us by figuring out the branch names itself, all we have to do is type in the leaf name - the part after the last forward slash.

So, starting at the root of the armature, we’ll name each bone by typing the relevant dataref leaf name into the box (figure 2.1). If we use the same dataref for more than one bone in the same armature, Blender automatically adds a numerical suffix (.001, .002 etc) to each subsequent bone. That’s why it’s good to start at the root of the armature when naming, so that the bone names are in sequence as we work along the chain of bones. It makes no difference to the animation, it just makes it less confusing for us!

It’s a family affair

Now that the bones have names, we get to the part I initially found a bit baffling - mainly on account of some of the terminology used - the process of linking, or parenting the bones together. The convention that made least sense to me was the verbal use of the word ‘parent’, as in: ‘now parent bone a to bone b’ - so which bone ends up being the parent? Well, I’m going to be reckless and state categorically that if you parent bone a to bone b, bone b becomes the parent, and bone a becomes the child. If I’ve got that wrong I’m in big trouble...

So, once again starting at the root of the armature, we’ll start to parent the bones to each other. In the same way that we did the naming, I try to keep a vague system together to help me by parenting bones together in numerical order if they are both animating the same object.

For example, in f igure 2.2, both the selected bones are going to be animating the back axle, so we’ll start with the one with the lowest number – tire_vrt_def_veh[2] –- and make it the root. Then we’ll parent tire_vrt_def_veh[3] to it by choosing tire_vrt_def_veh[2] from the drop-down menu as shown (high-lighted in yellow). What this means is that an object parented to tire_vrt_def_veh[3] will be animated by the sum of both bones.

In this case we’re not actually going to connect our back axle to either of these bones, because we still have more animating to do to it first! Instead we’re going to connect another pair of bones – the pair that rotate the axle around the z-axis. Again, we’ll parent the bones in numerical order to keep things tidy f igure 2.2 Parenting the first two bones of the armature.

figure 2.3 Parenting the next pair of bones to the previous one.

Figure 2.3 shows how things look with four bones connected. They are in sequence in the panel on the right with the root at the top (they appear in sequence only because I have selected them in sequence for clarity - it isn’t important at all). In the same way that the second bone of the armature – tire_vrt_def_veh[3] – is effec-tively the sum of the first pair, which look after the vertical motion of our axle, the fourth bone – tire_vrt_def_veh[3].001 – is the sum of the second pair of bones, which are responsible for the z-axis rota-tion. And because the second pair are connected to the first pair, this is the bone we’re going to bolt our back axle to. So we can think of tire_vrt_def_veh[3].001 as our ‘back axle bone’. We can forget about the first three bones for the time being, because the remain-ing bones are going to animate things which in real life are connected to the back axle, – therefore those bones will be parented to the ‘back axle bone’.

I hope I’m making some kind of sense to you - it’s easier to do than to explain! Hang in there – it’s going to get to be more fun soon....

Okay, before we get bored of the whole thing, we’ll swiftly hook up the last four bones: one for each back wheel, and a pair for the prop-shaft. The wheel bones are easy – we just parent them to the back axle bone – and the remaining two are just another pair which again sum the compression of both rear springs. That means that we parent tire_vrt_def_veh[2].002 to our very popular back axle bone (because, like the wheels, the prop shaft is connected to the back axle in real life), and then finally we parent tire_vrt_def_veh[3].002 to tire_vrt_def_veh[2].002 to complete the armature (figure 2.4). Whew.

A couple of points before we move on: you’ll notice that the bone for the left wheel – tire_prop_rot[2] – isn’t connected to the bone for the ‘left-side’ of the back axle (tire_vrt_def_veh[2].001. It is connected to the ‘back axle bone’ (tire_vrt_def_veh[3].001) just the same as the right wheel is.

The other thing is that we’re not clicking the ‘Con’ (connect) buttons in the Armature Bones panel.We would only do that if we wanted the head of a bone to physically snap to the tip of it’s parent bone, which we don’t in this example.

figure 2.4. Connecting the wheel and prop-shaft bones

Enough yellow bones already.

Yes, all our bone-naming and connecting has been done in Edit mode, and after a while even the most diligent of animators starts to grow weary of yellow, and yearns for a glimpse of some nice blue bones to relieve the monotony. So let’s don our most pretentious outfit, adjust the Aviators, and enter Pose mode.

Note: I know that I said at the beginning of this tutorial that I wasn’t going to go into too much detail and yet seem to be doing the exact opposite, but I’m still going to assume that you’ll have at least studied Marginal’s excellent and enviably concise summary of the rudiments of Blender animation which is included with his export script, and will proceed accordingly, with the aim of sharing some tips and hopefully ways to avoid some of the numerous yawning crevasses which await the innocent Blendernaut. However, in no way do I consider myself a Blender expert, so please don’t take anything I say as being ‘right’ – Blender is an extremely flexible application which appears to provide numerous alternative ways of achieving any given result, and although I seem to have got the hang of doing certain things reasonably well with it, I have done so almost entirely through trial and error, and may quite feasibly be in the process of doing the electronic equivalent of advising you to sharpen your pen and lubricate your ruler. The bottom line is that the methods I’m describing do work, but could probably be improved upon by reading the instructions.

Okay. Hopefully having taken your mind of those bones for a moment, let’s resume our quest by entering pose mode and parenting the various mesh objects to the bones. Before doing anything else it’s good policy to go to the Armature tab of the editing window (F9) and set the armature to ‘Rest Position’. That ensures that all the bones in the armature are in the position they would be in with no animation data apple to them. It’s particularly important to make certain that a bone is in the rest position before parenting a mesh to it because otherwise we run the risk of not noticing that the bone may have been already transformed by some animation data and parenting the mesh to it while it’s in the wrong position. This can obviously get very messy. At the moment it’s an unnecessary precaution because we haven’t entered any animation data yet, but nonetheless it’s a good habit to get into. It’s a real pain to realize such a mistake too late and have to go back and re-parent a bunch of stuff.

Parenting the mesh to the bones

So, with our armature in the rest position we can proceed to parent our four mesh objects to the bones, by first selecting the mesh, then the appropriate bone (it should turn light blue), and finally typing CONTROL - P and selecting ‘Make parent to ’Bone’’ from the pop-up menu. It’s probably self-evident which object gets parented to which bone, but just to be on the safe side, here’s the check-list:

Wheel2 is parented to tire_prop_rot[2]Wheel3 is parented to tire_prop_rot[3]Axle Rear is parented to tire_vrt_def_veh[3].001Propshaft_rear is parented to tire_vrt_def_veh[3].002

And that’s it for this armature – we can do some animation now!

figure 2.5 Parenting wheel 3 to tire_prop_rot[3]

Posing order

As a general policy, it’s probably a better idea to build and rig all our armatures before doing any animation but for the sake of variety we’ll look at the animation of this armature now. You may recall that when we were naming and parenting the bones I recommended starting at the root at working outwards to the tips. Well, now that it comes to posing our model, the opposite applies: it’s easier if we start at the extremities and work inwards to the root. As always, there are a few exceptions to this, in fact there’s one in this armature as we’ll see in a moment, but most of the time it’s a good plan. The reason is simple: it’s much easier to accurately pose a bone if it’s axes haven’t previously been rotated as the result of the animation of it’s parent (or grandparent etc..) Think about it for a moment and you’ll see what I mean. The most common exception is where the last bone in a chain needs to point at something – in that case, there’s no sense in posing that bone until we know what effect the previous bones are going to have on it’s position, and the easiest way of finding that out is to pose them first. In our armature, the pair of bones which keep the prop-shaft pointing in the approximate direction of the transfer box fall into this category – so we’ll leave them to last.

A quick review of the posing procedure

To make sure we’re all on the same page let’s quickly review the conventions which Marginal’s script uses. All we have to do is define two poses or ‘frames’ for our armature and X-Plane will interpolate all the other possible positions in between. It will also extrapolate all the positions outside those two frames in the event that it receives data which is greater or smaller than the values we used when posing the armature. What this means is that the two frames that we define need not be the extremes of travel. By convention, unless we tell it otherwise, the script will assume that for any given bone, frame 1 is how we want it to look when the value of it’s dataref is 0, and frame 2 is how it should look when the value of it’s dataref is 1. In many cases, 0 and 1 are convenient values for posing a bone – for example, most panel switches have corresponding datarefs which return a value of 0 when ‘off ’, and 1 when ‘on’ – but sometimes they are not so convenient. To take the example of our armature again, the values for the strut compression are given in metres, and clearly a whole metre of vertical movement is not realistic. In such cases, we can add a ‘property’ to the armature which tells it what our preferred values for frame 1 and 2 are.

Defining frame 1

Even if the value of a bone’s dataref is zero at frame 1, we must still define the position that the bone should be in. It doesn’t matter whether we do this bone-by-bone or all of them at the same time, the effect is the same. Let’s do the latter – it’s nice and quick and we can feel confident that all of our bones have had frame 1 defined. We do this by entering a ‘keyframe’ as follows: we select our armature and enter pose mode if we’re not already there. Next we uncheck the ‘rest position’ button so that the armature is ‘live’ and select all the bones by typing ‘A’, We make sure that blender is at frame 1 of the timeline by looking at the frame display in the header of the buttons window, and type ‘I’ to bring up the ‘Insert Key’ menu. We can now choose what kind of data we want to define for frame 1 – for our purposes we always want to define Location and Rotation, so we select LocRot to set the key frame.

Now that we’ve defined frame 1, we can start waggling things!

I usually check to make absolutely certain that I really have defined frame 1 by hitting RIGHT ARROW to take me to frame 2, grabbing all the bones and moving them to a random posi-tion (crazy, huh? That’s just the kinda guy I am). Then I’ll hit LEFT ARROW to return to frame 1 and if everything jumps back to it’s proper location, I know everything’s okay. If it doesn’t, it means that I’ve screwed up somehow and need to get busy with the undo button and retrace my steps.

Frame 2

Just as for frame 1, it doesn’t matter whether we set key-frames for frame 2 on a bone-by-bone basis, or all at once. This time, however, I tend to be more cautious and work bone-by-bone, or at most with small groups of bones because it’s easy to absentmindedly hit an arrow key and immediately clear your ‘unset’ poses, and it’s less of a blow if it’s only a couple of bones and not the entire armature.

So, starting at the tip of our armature and working backwards as I mentioned earlier, the first things to animate are the wheels. These are nice and straightforward because tire_prop_rot[n] returns a value in degrees, and one degree is a convenient rotation to pose, so there’s no need to define custom values for either of the key-frames. Also, both wheels rotate in the same direction around the same axis, so we can save time by transforming them at the same time!

First we go to frame 2 and select the two ‘wheel bones’, tire_prop_rot[2] and tire_prop_rot[3]. Then we perform the rotation of one degree around the x-axis. The Trans-form Properties floating window can be useful as an alternative way of performing the rota-tion and as a way of checking that we’ve done exactly what we wanted to do. Rotation done, we type ‘I’ to bring up the ‘Insert Key’ window again, and again we select LocRot to confirm the key-frame. Now if we toggle between frame 1 and frame 2, the wheels should jiggle one degree back and forth between their two poses. Hurrah! It lives!

The suspension

Okay, so that was the easy bit – now things get a bit more complicated! The next bones we need to tackle are the pair which rotate the axle around the z-axis (figure 2.8)

figure 2.7. I‘ve high-lighted a couple of useful features:

Transformations can be entered numerically in the Transform Properties window, which is sometimes more convenient than using the mouse.

The ghost function can be handy sometimes – it draws a second, ‘ghost’ image of the bone as it appears when in it’s other position. In fact it would draw many ‘ghosts’ of the bone if we were to enter a large number of frames of animation, but for X-Plane work we only ever use frames 1 and 2 at present so we’ll only see one. The value in the Ghost box controls how intense the ghost images are, and the value of Step determines the number of frames between them – which in our case is 1.

(figure 2.8)

X-plane supplies us with data for the vertical travel of each wheel hub, but we need to know the angle to rotate the axle in order to achieve the same amount of vertical travel. Kick-starting the brain into remembering some rudimentary trigonometry gives us :

R = arcsin(H/W)

However, the .obj format doesn’t handle trig functions , so what do we do? Hopefully the answer should be obvious: we cheat and hope nobody notices.

Rº

L

HH = L sinR

In actual fact, over the relatively small range of travel that the axle is going to rotate, the relationship between angle R and distance H isn’t too far from being a linear one. It’s certainly good enough for a cosmetic function such as this one, so we’ll proceed as if it is linear. I find that I get a tremendous sense of calm and inner peace the moment that I decide to abandon the rules and play dirty...

Posing the axle

Now we’re familiar with the basic posing procedure, I’m going to pick up the pace a bit, or else it will be next year before we get to the windscreen-wipers. Please feel free to ask questions at the end.

First we have to decide upon a value for our second keyframe because one metre of spring compression is not practical. Let’s use 50mm or 0.05m – that’s about 2 inches in old money. Next we have to inform Blender of our decision which we do by adding properties to the armature on the Logic panel as shown in figure 2.9. The correct syntax is shown in figure 2.10.In our case, the value for frame 1 is still the default of zero, so there’s no need to enter a value for v1. We do however need to enter a separate property for each different instance of the dataref, in other words: one for each wheel.

With our properties defined we can return to the armature and define the next set of key-frames.

We’ll start with tire_vrt_def_veh[2].001, which is responsible for rotating the back axle around the z-axis as a result of wheel 2’s springs compressing as it goes over a bump. In frame 2, we’re going to transform this bone so that wheel 2 is 0.05m higher than the other wheels. That’s what’s happening in figure 2.11. The green arrow indicates the vertical motion the wheel needs to make, and the blue arrow represents the rotation that we’re going to use to make that happen. The two parallel black lines are 0.05m apart - they’re part of a temporary cuboid I’ve made to serve as a ruler – I’ve set it to draw in wire mode so it doesn’t get in the way too much (F7/draw tab). Now we select our bone and rotate it clockwise until the left wheel is 0.05m higher than the right wheel and then confirm the transformation with a LocRot command.

Don’t worry about the fact that doing this has made the right wheel drop down. That is what tire_vrt_def_veh[2] and tire_vrt_def_veh[3] are there for. We’ll just make a note of how far the whole axle will have to be raised by tire_vrt_def_veh[2] to bring the right wheel back up to ground level: it is one half of the spring compression, or 0.025m

figure 2.9 Entering armature properties in the Logic panel (F4)

value for frame 1

value for frame 2

figure 2.10 Dataref property naming format

figure 2.11

Our next task is to perform the mirror image of the previous transformation, this time on tire_vrt_def_veh[3].001 to simulate what happens when the right wheel – wheel 3 – goes over a bump (figure 2.12). What is interesting is that as a result of this second rotation, the axle has now become level again – which of course it would be if both back wheels were to simultane-ously go over identical bumps. So far so good.

Now we’re going to move on to the next pair of bones in the armature, tire_vrt_def_veh[2] and tire_vrt_def_veh[3]. We’ll switch to a side view for this.

In figure 2.13, the green arrows show how far the axle is going to have to be raised, and the red arrow shows how we’re going to do it. To be more precise, it shows how we’re going to do half of it, because the axle is being pushed up by compression in both rear springs, which means that each of them is doing half of the work (one little green arrow), as we saw on the previous page.

By experiment, it turns out that to raise the axle the full 0.05m we have to rotate this pair of bones a total of 5º, therefore we’ll rotate tire_vrt_def_veh[2] by 2.5º – remembering to confirm it with a LocRot command – and then rotate tire_vrt_def_veh[3] by the remaining 2.5º to bring the total up to 5º (figure 2.14).

figure 2.12

figure 2.13 figure 2.14

One last sprint to the tape

You may take the generous amount of white space on this page to be a good omen - we’re on the home straight! All that’s left to do is to animate the remaining pair of bones, which prevent the front end of the dummy rear prop-shaft from dangling down from the differential at extreme spring com-pression values. There’s no need for precision here, so we’ll just do this: in frame 1, we’ll place the 3D cursor at the forward end of the prop shaft and then move to frame 2. By experiment we find that we can get the end of the prop shaft back to where it was in frame 1 by rotating it by a total of 3º. Which means that the final two bones need to be rotated 1.5º each to stop it waving about too much (figures 2.15 and 2.16).

Hats may now be legitimately thrown aloft, for our axle is now fully animated! Hurrah!

I was planning to have a quick look at the steering in this part of the tutorial, but I think we all deserve a rest after this marathon session, so we’ll leave that until the next nail-biting installment.

I wouldbe grateful for any feedback you may have on the subject of this tutorial - it will greatly improve the chances of forthcoming installments being more intelligible.

figure 2.15

figure 2.16 All text and images in this document ©2007 Alex Gifford. E-mail to: propsman@earthlink.net