Blog for Chris Calef at GarageGames.com

Fun with BVH Files, in Torque.

Chris Calef — 2008-05-14T07:05:33+00:00

WARNING: this blog is rather long and technical, and very heavy on animated gifs! Feel free to cruise through it and just look at the pictures. Or if you just want the code, skip to (HERE). I am including gratuitous explanations in the pages below, in the hopes that it might assist some artists or programmers to have a better understanding of how shapes, skeletons, and sequences work in Torque. Take from it what you will.

This resource is not guaranteed to work, and the user should download it at his own risk. Chris Calef is in no way responsible for anything that might happen as a result of downloading this resource.

----------------------------------------------------------------------------------------

So, anyway, a few weeks ago, an acquaintance dropped a three-letter acronym on me that momentarily changed my life and transformed me into a single-minded, obsessed, fanatically driven introvert. (Okay, so it wasn't that big of a change. My friends didn't really notice.) He said:

"Hey, do you know anything about bvh format?"

I'd had experience with motion capture before and knew there was a lot of data out there -- but I've been busy doing other things for the past couple of years. I have been interested in the engine side of character animation for a long time, though, and wanted to hone my skills a bit in that department anyway.

But as an indie developer, I also just want an easy, cheap or preferably free way to make use of the huge variety of bvh files that are out there on the internet, without buying or even having to learn to use any major art applications.

Call me lazy, I guess, but I'm a coder. I hate using GUIs.

I do also have the impression, though, that even with all the latest tools and techniques, it isn't always easy for artists to convert an animation that was made on one skeleton into a sequence that works with their particular model. The results of failure sometimes aren't pretty.

Well, I'm happy to report, mission accomplished! Some time later, I emerged from my lair with a couple of big shiny new ShapeBase functions that do everything I asked for. Now all I have to do is download a bvh, load up a player, type "$myPlayer.importBVH(coolNewAnimation);" at the console, and voila!

Well, okay, I'm exaggerating just a little. There are a couple of other steps you have to take. But once you get it set up, it's just about that easy.

Just so we're all on the same page, here's what a typical BVH file looks like:

It's a really simple, plain text format that is quite easy to parse. The skeleton is defined at the front of the file, and then the rest of the file is filled with all the frames data. Each line of frames data represents one frame, and all the rotations and translations for all the bodyparts (there can't be any left out) are stuffed into that one line, separated by spaces. Like this:

As you can see, it makes for pretty long lines.

One complication that became immediately evident was the fact that not all the files agreed on whether nodes should have six channels or three. The most efficient and logical method would be to include translation information for the base node, and then only rotations for everything else, since each node has already defined its offset with regard to its parent, and that's all you really need to know.

However, many sources of motion capture data seem to be less than perfectly efficient and logical, and include all six channels for every bodypart. I even found one bvh file that had NINE, adding scale to the end. (It was always "1 1 1", but it was good to know it was there, just in case.)

Also, many files had a lot of float garbage in them (numbers that should have been zero coming out like "-8.88178e-016"). This may not be terminal, depending on how you're scanning the data, but it's just ugly and I wanted it gone before I even started thinking about making these things work with my character.

So, I added another little ShapeBase function: "$myPlayer.cleanupBVH(coolNewAnimation);". What it does is loads up the entire bvh file (in this case "coolNewAnimation.bvh"), changes float garbage to zero, changes channels to three, deletes all the node translation data except for the top node, and then writes it all back out to "coolNewAnimation.new.bvh". It also cuts everything back to a reasonable number of decimal places, like "4.356" instead of "4.3564786755". These files are plain ascii text, and are pretty darn big anyway; I found that just by chopping off that unnecessary resolution, I could drop the file size by a lot.

So, cleaned up, shrunken down and reasonably efficient motion files in hand, the next step to make this work was to get it into a Torque character. For this, I started with a handy character from BrokeAss Games, who was rigged with globally aligned local bodypart orientations and hence was a convenient testing ground. (If you have no idea what that last sentence meant... stick with me, all will soon be made clear.)

This is where the rubber really hits the road, because the main problem people have with using other people's animations (and this is true whether we're talking about dsq files or bvh files or anything else) is the fact that all models do not share the same skeleton. Even though all normal humans may have two arms, two legs and a head, there is no protocol in place to define whether the right upper leg is called RThigh or RUpLeg or right_femur or what. It's entirely up to the artist, and this is the first of our problems. Often this problem alone keeps people from being able to share animations.

It gets much worse than lack of naming conventions, however. Even if we had two skeletons with exactly the same bodyparts, with the same names, defined in exactly the same order, the real stickler is going to come when we look at how the geometry itself is aligned with the world. When an artist is making a character, they might decide that the right upper leg could be represented by a cylinder, which they will then modify and attach to the rest of the body. This cylinder will be created by their modeling application on some initial axis (like, horizontally on the X axis), and they will then rotate it around to the position they want that leg to be in, and attach it to the body.

This is all well and good, but this means that when we want to rotate this bodypart, we have to be aware that it has local axes that differ from the world. For the right upper leg, the direction that the world calls "down", or negative Z in Torque, might actually be positive X.

This problem right here is why you can't just past rotations from one model into another without them looking really stupid. Working around it can be kind of a brain twister. I had to solve this problem once before for the ragdoll pack, though, so I wasn't intimidated this time.

The solution I came up with was to address all of the above problems in one little plain text config file. Often one config file for a model will work with a whole set of related bvh files, but I set it up so you can make one config file per model per animation, to cover all possibilities. You simply name your cfg file after a particular motion (if you have a "frontkick.bvh" to import, then name the config file "frontkick.cfg") and keep it in the same directory as your bvh files for this model. If the system doesn't find a cfg file named after this motion, it then looks for one named "default.cfg" in the same directory.

Default.cfg for Kork came out looking like this:

The first column of numbers is the index of the bones in the bvh skeleton, mapped to the second column which are the corresponding nodes in the dts model. All the rest of the numbers are Euler vectors that represent rotations.

Along the way here I also added a few handy console methods, just to get a better look at my models and sequences. One of them, "$myPlayer.showNodes();" prints out the list of all the nodes in this shape, with their IDs. It makes the mapping part a little easier.

In this case, I had the following skeletons to match up:

KORK

BVH

The reason I started with the BrokeAss model instead of Kork is because when you look at him in ShowTool, you find that in his default position, standing straight up with his arms held straight out, all of his bodyparts have local axes that exactly match the global axes. With Kork, as with most other character models, this is most definitely not the case.

This is only our first problem, however. When it comes to node rotations, there are really two separate issues to deal with. Besides our local node transforms, we also have to take into account the fact that our models may not be starting in the same position, either! My BVH character is defined with his arms down at his sides, but even my friend the BrokeAss Guy starts his life with his arms straight out. This means that even though a Y axis rotation might mean the same thing to both characters, a ninety degree rotation for the BVH guy lifts his arm from down to straight out, while the same rotation on the game character raises his arm from straight out to straight up over his head!

When we get to Kork, he's even worse -- he defaults to "standing holding a weapon" where none of his limbs are aligned with any axis at all.

So, let's take a look at that cfg file for Kork again:

0;0;(-0.0674,-86.4207,-0.0969);(0.0,90.0,0.0);(0.0,-90.0,0.0);(0.0,0.0,0.0);
1;18;(11.7373,-168.9883,-27.6818);(0.0,180.0,0.0);(0.0,90.0,0.0);(0.0,0.0,0.0);
2;19;(0.0,0.0,-44.9645);(0.0,0.0,0.0);(0.0,90.0,0.0);(0.0,0.0,0.0);

After the node mapping, there are four sets of Euler vectors (rotations about X,Y,Z). The first two are for putting the body physically into the position of the bvh character (arms down), and the second two are for dealing with the local rotations of the nodes once we get into this position.

That file's pretty ugly, though, so let's go back to the easier one. Recall that our BrokeAss human has his arms out, and all I need to do is to move his arms down in order to match my bvh position:

10;30;(0.0,90.0,0.0);(0.0,0.0,0.0);(0.0,-90.0,0.0);(0.0,0.0,0.0);
11;31;(0.0,0.0,0.0);(0.0,0.0,0.0);(0.0,-90.0,0.0);(0.0,0.0,0.0);
12;32;(0.0,0.0,0.0);(0.0,0.0,0.0);(0.0,-90.0,0.0);(0.0,0.0,0.0);

How about that? What we're looking at right there is the left shoulder, elbow, and wrist. Since the local axes are all global, and our character has Z up and Y forward, then all I have to do is rotate his shoulder 90 degrees on the Y and it will make his arm point down to the ground instead of out to his left.

This is all good, but what happens to our local axes when we do that? Suddenly our left shoulder, forearm and hand, which used to be pointing toward toward negative X, are now pointing toward negative Z! Oh no! What do we do?

That's where the last two numbers come in. No matter where we end up, it is always going to be possible to rotate our frame of reference back to the global, in two if not in one set of X,Y,Z rotations. (It's possible in one, but for humans it's sometimes much easier to use two, so I included that option. It turned out to be a very good idea, as we'll see shortly when we get back to Kork.) For our BrokeAss human's arms, then, we simply take the reverse of the ninety degree Y rotation we did at the shoulder, and lo and behold, everything works!

For those who are interested, the actual transform process looked like this:

m.identity();              //Start with an identity matrix.
m.mul(matBvhPose); //move this bodypart from its default pose to match the bvh pose.
m.mul(matAxesFix);  //then temporarily move it back to get the local axes matching global.
m.mul(matY);            //then do the bvh rotations
m.mul(matX);           // ...
m.mul(matZ);          // ...
m.mul(matAxesUnfix); //and then rotate by the _inverse_ of that temporary transform,
                              //to take it back out. Voila!

This wasn't too hard with the BrokeAss guy, since all I had to do was rotate his arms, but what about Kork? What are we supposed to do with a guy who not only has a huge mess of local transforms, but then he's standing there holding a crossbow instead of politely keeping his arms out?

Well, this could be nasty, but it turned out it wasn't all that horribly difficult, either. All you need to know is that Torque has a lot of useful quaternion and matrix functions, and my current favorite is called MatrixF::toEuler(). What it means is if you have a matrix representing your current position, and you take its inverse (which brings you back to the global frame of reference), and then you call toEuler() on that inverse, what you end up with is three magic numbers that you can plug right into my config file. Weird starting position, gone!

In code, it gets slightly complicated by the fact that we have to go from Quat16 to QuatF to MatrixF in order to make it work, but that's not so hard:

q16 = kShape->defaultRotations[2];
q16.getQuatF(&myQuat);
myQuat.inverse();
myQuat.setMatrix(&myMatrix);
myEuler = myMatrix.toEuler();

Unfortunately, if you have no starting position at all, what you get is this:

And that's why I'm glad I gave myself two Eulers per operation instead of only one. Now that I'm back to null, it's pretty easy to rotate Kork's bodyparts around with 90s and 180s until he's standing up with his arms down:

0;0;(-0.0674,-86.4207,-0.0969);(0.0,90.0,0.0);(0.0,-90.0,0.0);(0.0,0.0,0.0);
1;18;(11.7373,-168.9883,-27.6818);(0.0,180.0,0.0);(0.0,90.0,0.0);(0.0,0.0,0.0);
2;19;(0.0,0.0,-44.9645);(0.0,0.0,0.0);(0.0,90.0,0.0);(0.0,0.0,0.0);

When trying to visualize all these rotations, it can help to draw yourself a picture (see below, sorry for the sloppy artwork.) This is Kork with his back to us (so we're all facing the same direction), if he was standing with his arms out. Globally the X axis (red) goes to our right, Z (blue) is up, and Y (green) should go into the page.

And that's really the process, in a nutshell. Once all the frames are loaded and suitably processed, my importBVH function simply adds a sequence to our TSShape, sets it up with whatever flags it needs, and adds all of our new rotations and node[0] translations to the shape's nodeTranslations and nodeRotations lists. (If you have a Torque license and want to see the actual code, go (HERE)).

And with that, I believe I will draw this lengthy and perhaps overly detailed blog to a well-deserved conclusion. In the tradition of free motion capture files on the internet and many years of great advice and free stuff for Torque, I'm just going to throw this little project out there gratis as a "thank you" to everybody who's ever helped me figure something out. Have fun, and make awesome games!!

<shameless plug>
I am available for contract work, however, so feel free to get in touch with me if you need help!
chris (dot) calef (at) gmail (dot) com
<end plug>

Hello, Goodbye, Israel, and LSystems

Chris Calef — 2008-03-12T18:53:32+00:00

Well, hi again, everybody! Turns out it's been eleven months since my last blog. I know, it hasn't even been a year yet, but I'm just gonna go ahead and post something anyway. I'm turning over a new leaf. And I have had quite a bit going on recently. For one thing, I quit working at Garage Games and returned to Joyfully Independent!! Don't worry, though, there's warm fuzzy feelings all around, it's all good. (More below.)

Be warned, This Blog Is Image Heavy.

As you may have guessed, I just came back from Israel a little while ago.

It was a really cool trip, and I had a fantastic time. I highly recommend anyone who can to check it out at least once in your life. I'm not especially religious, at least not in any way that orients on a particular piece of territory, but the history there is deep and wide and comes screaming right on up to the present in a way that few places do. In a way it almost feels like Israel represents the crux of the whole world's problems, like if things could somehow get fixed there, then there might be hope for everybody.

;

Unfortunately, that doesn't seem to be the direction things are going, at least not this month. They've been taking rockets from Gaza in the Israeli town of Sderot for quite a while, and while I was there the Israeli government cut back electricity to the entire Gaza Strip, and I hear things have escalated quite a bit since then. Unfortunately, I didn't leave with any brilliant ideas for making everybody happy.

But damn, the story's been going on for a long time over there! Above is a segment of an Egyptian wall that is three thousand years old. You can see that they were made of mud, as they were kind of plastic when they laid them together. As far as I know, that wall right there could very well have been made by Hebrew slaves mixing straw and mud just like in the Bible stories.

You can't go up to the three thousand year old walls, but the two thousand year old wall above is open for anybody to drop their backpack on and hang out for a while. I stayed there quite a while, just soaking it up.

I got a chance to visit the Masada, on the Dead Sea, where the Hebrew Zealots took their last stand against the Romans, somewhere around the year 30 AD, after fractious infighting in Jerusalem wherein they proclaimed that real Jews had to fight the Romans right now, and everybody else was a wimp and a compromiser. They fought each other, and then the Romans came in and crushed them all.

Can't quite put my finger on it, but something about that story just feels familiar somehow.

The crazy thing about the above picture, actually, is that the building doesn't even date from the Masada's heyday. It's a Byzantine church from six centuries later. It's fourteen hundred years old, and the people who used it were already camping out in six hundred year old ruins. That's what I call history.

Here's what the place looked like when it was new.

Here's a Roman camp, one of the eight that surrounded the whole plateau for three years. Still sitting right there, two thousand years later.

If you're interested, you can check out more of my pictures here. It's kind of weird, the first image there is actually a link to a sub-gallery, but if you keep clicking around you'll figure it out.

My trip was fun as hell, but it actually wasn't all vacation. I was there as an official representative of Garage Games, on a secret mission involving these guys. More on that later.

This sort of brings me to the really big news of this blog, for anybody who's still with me. A few weeks ago, I took a giant leap from safe and employed back to crazy sketchy who-the-hell-knows-what's-gonna-happen-next INDIE!!!

(Hence, the "Goodbye" section of the title.) It's not really a goodbye, of course, but I said goodbye to working in the Garage Games office anyway. It was a great ride, I learned a hell of a lot and had an awful lot of fun and met a whole bunch of really cool people who will be friends for a long time, but the time had to come sooner or later where I jump out and start working on the game titles and projects I've had running through my head for the last ten years. The time is now, now is the time, and the move is made. For anyone interested, I'm officially available for contract jobs, I'm busy but if it's an interesting project that oughta get done, I can probably work it in, feel free to get in touch with me at chris dot calef, at gmail dot com. I love to work with dts models, converting and tweaking and applying physics and AI; and I can occasionally be persuaded to do other things too.

Now, some people who are STILL reading this might be curious about that last bit of the title.

Turns out, I've been grinding away at a side project that makes my life a living hell, but occasionally pops out something interesting. I finally got it up to the level of making a few screenshots, at least.

What it is is a perversion of an old freeware LSystems application called LParser by Laurens Lapre. I've had that program for years, played with it a lot, and thought it was really cool. Meanwhile, I was also working on a system for spitting out simple DTS models based on connected bodypart primitives read in from a script. I designed it way back when in order to have a means for testing physics on a number of different body types. At the time I was using ODE. Eventually, I hooked it up to dtsSDK so I could use it the models in Torque.

The above model was based on a cfg file that looks something like this:

0 Pelvis ; Pattern_X ; null ;0;(0.0,0.0,0.0);(90.0,0.0,0.0);5.0;10.0;-0.0;0.0;-0.0;0.0;(0.0,0.0,0.0);0.0;0.0;3;0.0;3.0;
1 Spine1 ; Pattern_X ; null ;0;(0.0,0.0,10.0);(0.0,0.0,0.0);5.0;12.0;-0.1;0.1;-0.1;0.1;(0.0,0.0,0.0);0.0;0.0;3;15.0;3.0;
2 Spine2 ; Pattern_X ; null ;1;(0.0,0.0,12.0);(0.0,0.0,0.0);5.8;14.0;-0.1;0.1;-0.1;0.1;(0.0,0.0,0.0);0.0;0.0;3;15.0;3.0;
3 Spine3 ; Pattern_X ; null ;2;(0.0,0.0,14.0);(0.0,0.0,0.0);7.5;10.0;-0.1;0.1;-0.1;0.1;(0.0,0.0,0.0);0.0;0.0;3;15.0;3.0;

4 Neck1  ; Pattern_X ; null ;3;(0.0,0.0,10.0);(0.0,0.0,0.0);3.0;6.0;-0.2;0.1;-0.1;0.1;(0.0,0.0,0.0);0.0;0.0;3;8.0;3.0;
5 Neck2  ; Pattern_X ; null ;4;(0.0,0.0,6.0);(0.0,0.0,0.0);3.0;5.0;-0.2;0.1;-0.1;0.1;(0.0,0.0,0.0);0.0;0.0;3;8.0;3.0;
6 Neck3  ; Pattern_X ; null ;5;(0.0,0.0,5.0);(0.0,0.0,0.0);2.5;4.0;-0.2;0.1;-0.1;0.1;(0.0,0.0,0.0);0.0;0.0;3;8.0;3.0;
7 Neck4  ; Pattern_X ; null ;6;(0.0,0.0,4.0);(0.0,0.0,0.0);2.0;4.0;-0.2;0.1;-0.1;0.1;(0.0,0.0,0.0);0.0;0.0;3;8.0;3.0;
8 Neck5  ; Pattern_X ; null ;7;(0.0,0.0,4.0);(0.0,0.0,0.0);1.8;4.0;-0.2;0.1;-0.1;0.1;(0.0,0.0,0.0);0.0;0.0;3;8.0;3.0;

It goes on, but I snipped it for readability. The point is, you write this text file by hand and then feed it into the system, and it spits out geometry. It's programmer art with a capital P, but my intent was to produce something rapidly that could get finishing touches from an artist, but would already have all the bones hooked up and the general shape working. Either that, or just use it as is in a cartoony game with lower art standards than your average FPS. Anyway, that project is still happening when I get time to work on it, but somewhere along the way I decided it would be a hoot to hook it up to LParser.

Turns out it _was_ a hoot, as well as a big pain in the butt. I spent two weeks immediately after leaving Garage Games flailing around in the transforms jungle, dealing with things that looked like this:

But, I finally got at least the first level of branching to more or less work, under a variety of different configurations.

Here's the code for the above model, I hope all the brackets and quotes work out all right:

# --- L-System Parser/Mutator --- Lj Lapre --------------
6
10
30
j[p][o]
j=FF
p=''^^Fp
o=''&&Fo
@

# --- L-System Parser/Mutator --- Lj Lapre --------------
6
10
30
j[''u]>>['u]>>>[u]>>>['u]>>>[''u]
j=F'F
u='''^^Fu
@

# --- L-System Parser/Mutator --- Lj Lapre --------------
2
10
30
j[p][o]''F[p][o]''F[p][o]''F[p][o]''F[p][o]''F[p][o]''F[p][o]
j=F'F
p='''^^^Fp
o='''&&&Fo
@

The complexity is limited by a crash bug right now, which I haven't tracked down yet, and I have big problems when I try to branch out into a second level. Still obviously a work in progress, but I thought some people out there might be interested. I recently became aware of one other LSystems project in Torque, which is also very interesting, but mine is actually geared more toward making creatures, giant bugs, and weird tentacled monsters than trees, which is the "normal" use of LSystems.

Oh yeah, and the other reason I'm doing it is, it plugs directly into my physics system:

But that's a whole other story, and is also beset with killer bugs at this point. Stay tuned for updates, I'll be posting again when things get farther along, but I figured I might as well spill the beans on it anyway. I haven't figured out the final end product for this one yet, but if you're interested, drop me a line and maybe you can bump it up on my priority list.

In the meantime, I'm back to work. Thanks for listening!

Chris

The Grand Canyon is really, really, really big.

Chris Calef — 2007-04-30T18:02:12+00:00

I know everybody knows that already, but just to make sure you know, it's not a myth! The grand canyon is indeed VERY BIG. In fact, it's hard to even describe how insanely ridiculously ENORMOUS it is.

As you may have gathered, I just got back from there. Had the most _amazing_ two weeks of my life, as part of a private flotilla of six oar boats riding some of the biggest rapids in North America. And, due to the admirable skill of our captains, we actually got through the entire trip with no boats flipped and no (involuntary) swimmers! Just lots of oohs and aahs (and screams), and moderate quantities of ingested sand and river water.

Take it from me, if you EVER get an invite to go on a private Grand Canyon trip... SAY YES! I know it's expensive and a big time commitment. Borrow money if you have to. You Will Not Regret It!

Now, the pictures. They don't even come close to capturing it, but here's some of them anyway:

Torque Build Environment (TBE) Changes Course

Chris Calef — 2005-12-07T00:46:28+00:00

Well, hello everyone! Sorry for my recent lack of .planning: don't think I'm not working on anything cool -- I'm just not at a stage where I'm ready to talk!

However, on the subject of TBE (the free Torque Build Environment, for those who don't know), there has been a major shift in direction and Jeff asked me to inform the community about it.

To cut directly to the chase: coinciding with the release of TGE 1.4, Garage Games is now officially recommending new users (and anyone else looking for a free compiler) to download Microsoft's Visual Studio 2005 Express, rather than using the GCC/Eclipse package we released last year.

If you've heard enough and you want to get started immediately,
Go Here For Instructions. (If it asks you to login and it doesn't work, keep trying, using your regular GG login information.)

If you want to know why we've made this decision, read on:

The reasons for this change are numerous. First and foremost, last year Visual Studio wasn't free, this year it is. (Unfortunately it is only free for a year, but it is most likely going to be quite cheap after that, and there will still be free options available; if there are problems next year we'll deal with them then. )

Given that the price to the end user is the same (free), it must be said that the price to Garage Games of maintaining support for an alternate compiler and IDE is significant.

To put it bluntly, for coding in C++, relative to Visual Studio... Eclipse bites. GCC is a pretty good compiler, but it doesn't have a very reliable debugger, and performance varies. A few times I have found dramatic differences in performance, and sometimes hard-to-track bugs, where the difference turned out to be simply that I had compiled my engine with GCC rather than VC++. Yes, these problems can be dealt with, one by one, but they all take extra time, and nobody in the office has a lot of extra time to keep throwing at this issue when there is another free solution sitting right there that works fine.

I hope I'm not breaking the hearts of too many fervent anti-Microsoft freedom fighters out there, (if this is you, what are you doing using Windows anyway??) :-) -- but the fact is, Visual Studio is a really professional product, and it does its job quite well. The debugger works exactly as you would want it to, the intellisense functions do their job, and most importantly, Visual Studio is, with a couple of exceptions, what everybody in the office is using. We can't slow down our own coding by using a second-rate tool, but at the same time we can't adequately support the MinGW/GCC/Eclipse development chain if we're not using it every day.

The release of TGE 1.4 brought this issue directly to the front, as it took several people (in and out of the office) several days of off-and-on work to get through the compiler and linker errors that came up when compiling the new engine under GCC. While this is great fun and all, we would much rather have our work go toward improving Torque.

So, there you have it. If you already have TBE and can't or won't use a Microsoft product no matter what, the issues with compiling TGE 1.4 did get resolved (thanks, everybody who helped!), and you can find instructions here

However, for everyone who wants to go ahead with Visual Studio Express, once again, you can find instructions on TDN here. (Again, if it gives you trouble logging in, try, try again! Ben is working on that. Use your regular GG site username/password.)

Thanks for listening, hope this helps everybody get on the same page! Good luck with it!

Chris

Ragdoll Pack Gets Multiple Character Support

Chris Calef — 2005-09-13T23:28:31+00:00

Well, once again it took about six times as long as projected, what with all the annoying details of real life that tend to obstruct the flow of coding, but... as of today, the ragdoll animation pack is NO LONGER LIMITED TO ORCS!!

It now works with Jill (Tank Girl Pack), Adam Pack, AND Soldier Pack. If you've held off buying it because you want support for one of the above models, wait no more!! Each of the supported models has its own dsq file containing a full set of ragdoll animations that work with that model -- kork_ragdoll.dsq, jill_ragdoll.dsq, etc.

Furthermore (and this is even more exciting from my perspective), I achieved a technological breakthrough in the process!!! (While I strive to maintain an atmosphere of humility, I think I deserve some bonus points for this one!!!) This is the reason this update took so darn long. I'm one of those people who, given a choice between an easy way (short-term payoff) and a hard way (long-term benefits), just has to take the hard way. In this case, the "easy way" would have meant building a separate ragdoll model for each character, and doing all 72 animations again for each one, and saving them out. This would have taken a few days, and could have been done a long time ago, but it wouldn't have done me much good in the long term. It would have been a laborious process that would have had to be repeated every time a new model came along.

Instead, being a true masochist, I decided that it should be possible to dispense with this whole process and instead simply convert the animations from the orc model to the other models. It stood to reason that any roughly bipedal form should be able to perform motions designed for another similar bipedal form, given that they have the same number of arms and legs, after all.

Thus:

As you can see, it worked! (For those who don't recognize it, that soldier is doing the "Kork dance" from the Torque demo. As far as I know, it's the first time anyone without a Kork skeleton has ever done those particular moves!)

The difficulty here, of course, is that each model is built with nodes having totally different local orientations. If you open up the Show Tool Pro, and load Kork, then Jill, then Soldier, and start clicking around on their bodyparts and observing the red, green, and blue axis indicators, you will see what I mean. Even if you fix all the node names, which need to match for the dsq to even load, you will find unexpected and undesirable results if you don't deal with the node orientations.

However, except for Jill's feet, the one similarity they all share is the fact that the bodyparts all tend to be aligned at 90 degree angles to the global axes. Without that fortuitous coincidence, I don't know if I would have ever figured this out. As is, though, it usually only requires some number of 90 or 180 degree rotations around one axis or another to "fix" the movement of each node in a sequence, so that it will work with a different model.

Anyway, the long and short of it is: it was really hard, but I got it, and now I can finally work on something else! Yay!!!

Before I go, I have one question for the community: Is anyone else beset with the problem of animations they wish they could convert from one model to another? And more to the point, would the solution be worth a few bucks to you? I'm thinking of incorporating my new logic into a GUI-based tool for sale if there's demand. It seems pretty handy to me, anyway. Speak up now if you want it, otherwise I'm back to churning out animations!

Peace out,
Chris

Ragdoll Pack Is SHIPPED!!

Chris Calef — 2005-04-08T00:46:54+00:00

Well, yesterday was my birthday, and on the same day I saw my very first, completely independent, game-related product go out the door. Seems like a good time to look back and reflect a bit. It does tend to make one think. I just spent something approaching six months of my life working on a $20 product, that probably won't ever pay me back for more than a decent month in any real job. Ha ha. Life can be funny that way.

But, hey, nobody ever told me to be an indie game programmer. :-)

And, even though I watched not just the numbers, but the numbers of digits in my bank account plummet during that time, I can't feel too terribly bad about it. Six months ago the entire engine/ts directory, as well as all that gobbledy-gook about ghosts and bitstreams, and of course everything about the RTS kit, were pretty much "black boxes" as far as I was concerned. Were it not for Ben Garney, Tim Gift, and the other wise and generous souls in the GG office, I'd still be spinning my wheels on that stuff. (Thanks you guys!)

So, it wasn't really six months on the $20 Ragdoll Animation Pack. It was six months on the pipeline from the Open Dynamics Engine into Torque, including: RTS pack basics, Torque client/server architecture, DTS format fundamentals, and don't forget the constant ODE shock therapy!

Anyway, enough excuses. The important thing is, I DID IT! Today, my life is beautiful, birds are singing, flowers are blooming, and if the proverbial bus takes me out tomorrow, at least I'll die happy!

So what did I do? Ever since Tim Gift dropped the magic words "Open Dynamics Engine" at my feet, at my first IGC in 2003, I've been absolutely possessed by the need to link it up to the Torque Engine, and more than that, to create animation with it.

I should back up a minute, though. I've been trying to make my own game since at least 1997. Along the way I've had a lot of great ideas, but one that just would not ever leave my head is this: Trying to model character motion, without a system of gravity and collision detection to handle the realism part, just sucks. I don't care how many people I see out there doing it, with IK or whatever, if we are creating a run or jump or fall animation by dragging a character's limbs through what we think are realistic trajectories, but we are not modeling the actual gravity and forces of the imaginary situation, then in my humble opinion, we're just wasting time. No offense to all the artists out there who do a miraculously good job of pulling this off believably. When it comes to animation in my game, I don't want art, I want a simulation.

If I had a simulation, not only of "natural world" forces like collisions and gravity, but also including some kind of AI and motor forces in the character, then someday I could theoretically generate ALL of my game animation without an artist having to lift a finger, except maybe to make corrections and improve the feel. I'd also have a pipeline with which to effortlessly create movies and animations, and, ultimately, to get rid of the "saved sequences" animation model entirely, instead having live virtual creatures animating themselves in realtime.

This is the primary will-o-wisp that I've been chasing after with glazed eyes for all these years. Unfortunately, before Tim told me about ODE, I was going to have to write the entire physics engine before I could even start my real project, which is generating the animation. While that goal could still be considered within the bounds of "humanly possible", it definitely comes under a different time frame. (Like, in Brian Ramage's words, "go back to school and get a Ph.D. in physics.")

But even with ODE in the picture, it's still not exactly cake. ODE is far from simple, and neither is Torque. Especially on the ODE side, I've found all kinds of stability issues and unexplained behavior that has required bizarre workarounds, and all I've done is the simplest little bit I could think of. I'm not doing any AI here, I'm just modeling some more-or-less realistic joints and collisions objects to match Kork's skeleton, and then flinging him. Later I'll be putting muscles on him and handing him a genetic algorithm with which to learn how to do what I want him to do. (In case you're wondering, this second part of the project is prototyped already, that's what I was working on when I hit IGC last year.)

My most immediate future plans for the project are to deal with the obvious, glaring, painful issue that people have their own player skeletons, and probably aren't using Kork or Elf Girl or Blue Guy in their games. I can't make dsqs for models I've never seen, and I can't very well go through hundreds of skeletons and custom generate animations for each one, either. Fortunately, right about the time this realization started to really sink in, Jeff Gran happened to pop up right behind me (literally) in the Garage Games office, with a very cool idea. If you missed it, check out his plan, I'll let him tell you about it. But trust me, we're working to solve this problem.

But anyway, this plan is fast getting out of hand. Just wanted to touch base and say "Thank You!" to everybody who helped me wrap my dim-witted brain around all the problems it's had to wrap itself around so far. I'll shut up now and give you time to get your credit card out. Go check out the Ragdoll Animation Pack Product Page, and if you have any interest in seeing another struggling indie pull his rent together for another month and keep working on radically cool lines of development for Torque, you know what to do!

Till next time,

Chris Calef

Ragdoll Pack On The Way

Chris Calef — 2005-02-24T01:45:29+00:00

Okay boys and girls,

I'm back with another .plan! I swore I wasn't posting anything again till it was ready to ship, but then I figured what the hell, Josh has posted about a dozen T2D-related plans since the last time I said anything, guess I might as well let y'all know what's happening!

The short story: the ragdoll animation packs are VERY CLOSE, and they work great with the RTS Pack too! That's what took the last couple of weeks -- had to roll my own little physics system in RTS, not to mention some time setting up explosions etc. just so the movies wouldn't look dumb, and just generally finding my way around the RTS pack.

But it works! I say "packs", now, because there are going to be two of them, one pack for radius damage (explosions) and one for direct damage (direct hits). For the questions about when and how much, the answers are a) as soon as they are done, which will be very soon, and b) cheap, probably $25 each or $40 for the pair, but I'm not committing on prices until they're actually for sale.

For MPG movies of this stuff in action, go here.

Ragdoll Pack Preview

Chris Calef — 2005-01-29T00:52:18+00:00

Well, hey again! It took me a little longer than planned to overcome some of the ODE obstacles (hint to anyone new to ODE: if things just don't make any sense at all, try scaling everything up ten times) but I'm finally looking at a Kork in the torque demo environment who can get blown all over the place, and I have to say, it feels good!!

Not that I'm in favor of blowing people up -- if you feel bad for Kork, you'll be happy to know I dropped the crossbow damage to only one point, so this definitely doesn't qualify as "torture" under the rules of the current administration!

Anyway, check out the rest here:

Thursday Jan 13 17:56

Chris Calef — 2005-01-13T17:56:33+00:00

rag doll animations for torque.

Hey y'all,

The time has come... (drum roll, please...) to bring you all up to date on a secret project I've been constructing in my underground laboratories for the last several months!

You want a rag doll for Torque? Check it out:

(For more eye candy, check out the preview site.)

"Things you just can't pay your motion capture actors enough to do!"

I guess I'm one of those people who doesn't put out many .plans, cuz I don't like to bust anything out till it's a .done! But this current project is rapidly approaching that stage. After months of torturing the patient garage games staff with my invisible dts meshes and weird boxy guys with disconnected body parts, I've finally hooked up a pipeline from an Open Dynamics rag doll figure to the dts player skeleton!

In case you've missed it so far, the Open Dynamics Engine is a fabulous free physics engine written primarily by Russell Smith. ODE provides a simulation environment for rigid body physics, in which you can create rigid shapes and link them together with constrained joints, forming skeletons. ODE is awesome!

It isn't entirely .done yet, though, so I don't want to say much more at the moment. Suffice it to know that there is an animation pack forthcoming in the very near future, and it won't be the last one! Stay tuned...

Wednesday Mar 17 18:22

Chris Calef — 2004-03-17T18:22:49+00:00

cloth object based on render object (melv is the best!)

just a quick work update .plan:

a couple of the goals from my earlier .plan require me to either write dts models or bypass them and do procedural modeling internally, so to practice I used Melv May's fxRenderObject to make a cloth object, using a spring-particle system I wrote a couple years ago.

if anyone's interested, here's a couple shots:

i'll post it as a resource when it's cleaned up (if anyone really wants it soon let me know). Right now it doesn't do any collision detection or shadow or anything, so it's kind of boring. I plan to at least make a "blow" function from the player, or crossbow bolt collision detection, so you can make it move. Right now it just starts with an initial velocity on the particles and then settles down for the rest of its life.

I'm still working on multi-block terrain code (terrain manager or derivative), but I'm doing pretty basic research right now. If anyone can point me to really good tutorials or forum threads about the terrain system I'd appreciate it.

peacenluv,
chris calef