Balshor

The height slider is the number of inches different from six feet. In Zloth's example, the character is slightly taller than 6'10.5" tall. If it said:

0 11 COSTUME 1 7289d4 -4

then the character would be 5'8" tall.

Dear everybody,

At the end of last year, I found myself in the unenviable position of having recently completed my graduate program with no real job prospects in my field. So, I decided to switch career paths and try my hand at real software engineering. Right at the top of my resume under "programming experience," I put the following:
<ul type="square">[*]Designed and developed a core Java / Swing animation scripting tool to allow an online film community to easily manipulate a highly numerical proprietary file format without using complex mathematics. Currently continuing to maintain and update the application based on user feedback.[/list]Lo and behold, I got a few responses, and at their requests for code samples, I sent them the story of how I decided to write a demo editor and how all of you have gone on and created wonderful things with it. This was apparently rather memorable, because at my later interviews, everybody kept mentioning how cool the machinima was, even though I've never actually made a movie myself.

To quickly wrap up this story, I ended up getting a few job offers and picked one at a promising start-up in the SF bay area. As a thank you for inspiring the initial forays into hobby programming that have led to my new career, I originally wanted to sit down and do a major update to the editor for you all. Unfortunately and somewhat ironically (if predictably), my new job has severely impacted my free-programming-time. So, instead, I've decided to release the source code to the wild in the event that one of you has an urge to extend the program. The code for the editor and for my (incorrect) ragdoll tool is up on Github at the following URL:

http://github.com/balshor

I *think* I got the whole program up there -- after almost five years of development, two different IDEs, and a few different distribution and packaging systems, there are some definite snarls in my file organization. Feel free to drop me a line either here on the forums or on GitHub if I missed some crucial file or if you have any questions about the code.

Thanks again for all the inspiration, and thanks for using the program enough to keep me hacking away at it for all these years.

-- Balshor

It looks like you added a costume definition at the end of the file. Two things:

1) I think you're missing a NEW command in there.
2) I assume that you're using my editor from the time information. Be sure to resort your commands into chronological order before writing the file -- the game isn't going to handle a command with a time code of -93128.

My editor can be downloaded here. Version 0.9.1 is the most recent version.

You'll probably be most interested in the interpolation wizard and the "Generate PYR relative to POS" wizard. The interpolation wizard will create POS commands in lines, parabolas, and circles. The other wizard can automatically point the camera either in the direction of motion or at another entity in the demo. You can also put in offsets that will point the camera (for example) three feet above the entity's position, so you can aim at their waist.

Feel free to bug me if you have any questions about using the program.

Here's an update on where I am in figuring out these angles. Download links are at the end of the post.



I'm working from Leandro's assumption that the three parameters represent three consecutive rotations around the horizontal (X), vertical (Y), and depth (Z) axes. The first thing to figure out is the order these rotations are applied. So, I created an animation that placed the upper right arm at (640,640,640), which should indicate a 45 degree rotation around each axis. Next, I increased each of the three parameters to 768 (90 degrees) and back. The sequence went like this:

(640,640,640)-&gt;(768,640,640)-&gt;(640,640,640)-&gt;(640,768,640)-&gt;(640,640,640)-&gt;(640,640,768)-&gt;(640,640,640)

In the animation that CoH displays, you can see that the first motion looks like a rotation around the X-axis, while the second two are rotating around some skewed axis.

Next, I modified the animation so the first parameter was always 512 (no rotation). Looking at the animation in CoH, the second motion (where we vary the third parameter) appears to rotate around the Z-axis, while the first motion rotates around a skewed axis.

So, this suggests that we first use the second parameter to rotate around the Y-axis, then the third parameter to rotate around the Z-axis, then the first parameter to rotate around the X-axis. (These rotations are around the fixed axes.) I've mocked up a version of my program that does exactly that.

Again, however, the problem is the amount of rotation. If you compare Ragdoll's computed animation with the CoH animation when varying only the second and third parameter. In the first motion (varying the second parameter), Ragdoll moves the hand diagonally towards the shoulder. In CoH, the hand moves more across the waist. The other positions also appear to be slightly too high in Ragdoll.

So, I'm guessing that one of two things are occuring: The first possibility is that the three-rotations-around-fixed-axes model is incorrect. The second possibility is that the limbs are spring-loaded, which messes with the amount of rotations that's applied to them. (This is a real possibility, not just something I'm making up. The PhysX API has provisions for spring-loading joints so the PhysX engine can correctly compute how forces act on limbs.) I'm hoping that the problem is the first possibility and not the second; the next step in my master plan (Mwuhahaha!) will be to try to find some animations that will conclusively disprove the 3-rot model and hopefully suggest a more correct one.

(Of course, there's also the possibility that I'm interpreting what I'm seeing incorrectly. Feel free to take a look at the animations and tell me if I'm seeing something different than what's actually there.)




Ragdoll v0.0.8: still not entirely correct. You need Java3D or the .dll files from the v0.0.6 version. See the first post for links to those.

The animations I used as both .xml and .cohdemo files: rename the .xml files to animate.xml to load them into Ragdoll. This version uses the 3-rot model I describe above, where we rotate first around the Y axis, then the Z axis, then the X axis. These are rotations around fixed axes.

Here's a slightly more correct version:

http://www.mediafire.com/?1bnteo3jqm2

I believe that this version can do right angles a bit better, but it's still off computing the in-between values. I'm going to take a look at getting angles for individual joints correct. This will probably take at least a week -- I have some other projects that will be consuming my attention for the next several days.

Edit: Note that you need the .dll files from the previous version, or you can install Java 3D yourself via the links in the first post.

[ QUOTE ]
I scrapped the entire model I was using in favor of OpenGL's glRotatef API. I figured that's what COH uses. My rotations became more accurate indeed when using it... but it just isn't rotating second-level joints (elbows, knees) the way it should.


[/ QUOTE ]

Does OpenGL use a scene-graph abstraction? That's what I'm using, so you can just set the lower arm as a child of the upper arm, and it automatically inherits the parent's orientation.

Leandro --

After a bit more thought, the arm movement you describe isn't really physically possible. Move your arm into the position described in the first step by bending your shoulder and elbow 90 degrees each. Now, rotate your ELBOW 90 degrees so your hand points to the ceiling. It can't be done. If you put a dot on your bicep and move your arm so your hand points to the ceiling, you can see that what you're really doing is rotating your shoulder 90 degrees along the axis of your upper arm.

That doesn't fully explain the discrepancies between what Ragdoll computes and what CoH computers, of course, but it does explain why the (768,768,512) position for the elbow joint appears to be on the edge of what the client considers to be "physically possible". See this demo. After rotating to the (768,768,512) position, I move the elbow to (1024,768,512) and back, then (768,1024,512) and back. I have no explaination for why these two movements are both along the same axis, except that we're running into some sort of limit that prevents the joint from rotating in a more intuitive way. (It may be a bit tricky to see from the side, but the two last arm movements both occur in a vertical plane.)

Hmm...after studying this example, I think that my rotation axes are correct, but there's something weird going on with the angles. Here's my current (incorrect) model:

Positions are defined using Axis-Angle notation. In a nutshell, the three components give you a vector to rotate around, and the length of the vector somehow represents the amount to rotate. After playing around with the possibilities, I still haven't figured out exactly how the quantities of rotation work.

In what follows, all directions are according to the viewer's perspective.

Call the left-right axis "X", the up-down axis "Y", and the in-out axis "Z". Map the range {0 -&gt; 1024} to {-180 -&gt; 180}. So, (768,512,512) maps to (90,0,0) which means a rotation of 90 degrees around the X-axis, which is what we expect.

If you look at the difference between ragdoll1out.jpg and ragdoll2out.jpg, you'll see that the lower arm does not make a simple rotation around the Z-axis because the back of the hand goes from facing up to facing the viewer. A Z-axis rotation would leave the back of the hand facing to the left.

Using my Axis-Angle description, ragdoll1out.jpg = (0,90,0) is a rotation of 90 degrees around the Y-axis. ragdoll2.jpg = (90,90,0) is a rotation of 180 degrees around a diagonal line in the XY-plane. (Keep in mind that from the perspective of the lower arm, the XY-plane is the YZ-plane in world coordinates, because the upper arm has also rotated 90 degrees around the Y axis.) This causes the back of the hand to end up in the correct orientation. So, it would seem that rotations might be calculated by simply adding the (absolute values, probably) of each component.

The problem with this is if we animate the transitions. From this perspective, we can see that Ragdoll is incorrectly calculating the intermediate positions: Ragdoll makes the hand moves closer to the face in the second motion, where CoH has the hand moving in a vertical plane.

So, there's either something else going on with calculating rotation amounts, or my Axis-Angle interpretation is completely wrong. Rotation amounts aren't L2-norm (which is what the version you have calculates) or the L1-norm (which is what I described above). I'll play around with it some more and see if I can come up with anything.

Well, I still haven't figured out what the third parameter (ie, the second timing number) does. However, I (may have) figured out the position information, and I have a (supposedly) working proof-of-concept animator available in case anybody wants to give it a spin:

http://www.mediafire.com/?gzgngmyyj3j

Just unzip the files somewhere and double-click on the jar. You'll need to have a recent version of Java installed: if you don't, you can get it at www.java.com.

Note that the DLL files are for the Windows x86 version of Java3D, although they should probably also work for Windows x64. If you want to try the program out on a different platform, you'll need to download and install the appropriate files from the Java3D project here. As I only have Windows machines available, I can't help you with any of that, but it shouldn't be too hard if you're reasonably tech-savvy.

As I mentioned, this program is intended to see if I have the correct algorithm down. Here are some of its features and limitations:
<ul type="square">[*]This is a simple keyframe animator. You can set the position of any of the 11 bones on each keyframe. The program will automatically interpolate between these set values.[*]To change a bone position, you can either edit the numbers in the key frame grid or drag the bone itself in a fixed view. If you check the "Drag Lock" box, the currently selected bone will be the one that moves when you drag.[*]You can change the adjustable views via dragging. Left-drag should rotate, right-drag should move, and center-drag should zoom. The mouse wheel will also zoom, but there's a bug where it will zoom every adjustable window you have open.[*]The P/Y/R parameters are incorrectly labeled. They really should be X/Z/Y parameters.[*]The "S" parameter is a smoothing factor for interpolating between the previous keyframe and the current keyframe. It does nothing on the first keyframe. Set it to a number between 0.0 (for normal linear interpolation) and 0.5 (for maximum smoothness).[*]Play and stop are very primitive right now. Play always plays from the beginning. Stop will go back to time zero. This means that the edit window and the display may be out of sync after you push stop. Just select a different keyframe to resync them.[*]Exported animations end up as export.cohdemo. In recognition of all the work Leandro put into his Poser program, I went ahead and stuck him as the model in mine. (Leandro: if this bugs you, speak up and I'll change the default model.)[*]Exported animations probably won't work in any other demos that have ragdoll commands, as I've set the initial timing information arbitrarily.[*]Animations are saved and loaded to animate.xml. I was only testing one animation script at a time, so I just hard-coded the file names.[*]The in-game model has some limits on how much you can rotate each joint. Mr. Rainbow Man does not. As long as the animations are reasonably physically possible, the animations in-game should match the animations in-editor, but anything beyond these limits won't match.[*]This is a proof-of-concept release only. Guaranteed to be buggy. During development, this program did not become self-aware and murder its creator; however, I make no promises for you.[/list]
At this point, I'm mostly looking for feedback about whether this program correctly generates animations and about what sort of features and interface you would be looking for in a full-fledged animation editor. So, tell me what you think!

Edit: Okay, it's not quite cracked. Updated thread title to reflect that.

As far as I know, it's not possible to adjust hands and feet with ragdoll code. However, I've only been looking at the 11 bone model discussed in this thread; it's possible (although in my mind unlikely) that other models are accessible with the EntRagdoll command. Why don't you try adjusting the number of bones, tack on a few more triples of angles, and see what happens?

Yeah, I don't know OpenGL, so although the JOGL program makes OpenGL available in Java, I'm relying on the higher-level Java3D project (depsite the fact that development on the Java3D project is currently on hold).

On a side note, I can generate and play animations with my program...but the animations that CoH plays aren't the animations that I think I'm generating. The three numbers don't appear to be independent -- if I set a limb's "pitch" to 90 degrees and try to rotate the limb by increasing the "yaw" from 0 to 360 degrees, the limb also rotates in the "roll" direction.

I'm assuming that the ragdoll data is basically dumped straight out of whatever PhysX routine CoH runs, so I've been reading up on the PhysX API to try to come up with good guesses as to how it works. Currently, my best guess is that the three components represent the spin/twist coordinates or some sort of quaternion components. Unfortunately, I suspect that it's the latter, as calculating interpolations is much easier with quaternion coordinates than with spin/twist.

Has anybody here investigated playing demos on the Mac client? Does it use the same command-line arguments as the PC client? I don't have a Mac myself, but I'd be interested in making the demo launcher built into my editor work for Macs as well.

(As it's written in Java, the rest of the editor should do just fine on a Mac, although you obviously would need the .jar version instead of the .exe version. You'd also want to configure the JVM to use more memory if you want to work with large demo files.)

Well, this probably explains why all of my test demos (based around Ms. Liberty's platform for an easy initial starting point) broke halfway through writing the latest version of my editor.

Judging from a quick demo of my ff defender tossing around some warriors, EntRagdoll commands are recorded approximately every 250 ms, or 4 commands per second. This contrasts with movement, which is recorded about every 33 ms, or 30 commands per second.

Of the two unknown numbers, the first parallels the timing in the demo. If you look at the amount of time between two EntRagdoll (not necessarily consecutive) commands and the difference between the two values of that first unknown number, the difference is always three times the amount of time (up to a small amount of rounding error). Perhaps the physics system needs timing information at 3000 ticks per second, while the rest of the game records at 1000 ticks per second? This could explain why the demo saves duplicate timing information.

Examples: (timing is absolute from the beginning of the demo)

2660 2460 EntRagdoll 11 605724759 605723741
2910 2460 EntRagdoll 11 605725509 605724403

Difference in time = 250
Difference in first unknown = 750
Div by 3 = 250

10425 2461 EntRagdoll 11 605748055 605746940
21409 2438 EntRagdoll 11 605781006 605779865

Difference in time = 10984
Difference in first unknown = 32951
Div by 3 = 10983.67

This pattern has held for a few tests from one demo, but it appears too precise for me to think that it's a fluke of my small sample size.

Now, on to the second number....

Currently, it looks like this. This is a purely functional UI that will undoubtedly evolve as the program progresses, but the main pieces are there:
<ul type="square">[*]The three small views are fixed, flat perspective view of the figure along the three axes. Individual bones can be adjusted with the mouse, although the precise connections between mouse movements and rotations needs some work.[*]The large view on the right is an adjustable view that you can adjust to see whatever angle you want on the figure.[*]Additional fixed and adjustable views can be opened using the "Open View" button.[*]The left grid is the current key frame, showing the PYR values for each of the eleven bones. The "S" column is a smoothing factor that controls the interpolation from the previous key frame to the current one.[*]The right grid displays the key frames. An "X" in a box indicates that a bone has a position set. Hyphens indicate interpolation.[*]The export button! It does nothing! (Yet)[/list]I've actually played around with Leandro's program a fair amount and drawn some obvious inspiration for the UI from him. (He's also told me that he's more than happy to let me wrestle with this ragdoll programming.) I'm currently at the point where I'd like to get the export actually working before I start messing with anything beyond a purely functional UI. Once export is working, I'll do things like track down a nicer looking figure instead of Boxy Rainbow Man.

Okay, I'm in the midst of writing a custom animation generator, and I have the bare essentials done except for outputting my internal representation of the animation to ragdoll code. (Yeah, it's "only" that left, but the input, keyframes, and a multiple-angle display are all done.) So, I'm resurrecting this thread in case anybody out there has more knowledge or experience to share. Here's a summary of where I am right now, before I begin to really mess around with EntRagdolls:
<ul type="square">[*] There are eleven bones.[*] Each bone has PYR values represented as an 8-digit hex number.[*] Going from 0 to 1024 represents a full circle.[*] The bones are ordered as follows: Lower Right Leg, Upper Right Leg, Lower Left Leg, Upper Left Leg, Lower Left Arm, Upper Left Arm, Lower Right Arm, Upper Right Arm, Head, Torso, Waist.[*] We really don't know what the second and third arguments mean.[/list]I'll probably be spending a lot of time with my FF/nrg defender this weekend, knocking low level mobs around and recording demos. Does anybody have any additional insight to share? Has anybody gotten a custom ragdoll figure to smoothly animate in-game, even if it's not quite the animation you wanted?

My quick weekend update on the editor turned into a fairly major rewrite of the program. Most of this is behind-the-scenes, but here are some of the more visible changes I've made to the editor:
<ul type="square">[*] Changed the look-and-feel to from cross-platform to system.[*] Made the save function default to the demo's current location.[*] Added Windows Vista recognition to the launcher. Should get rid of the "Windows version not recognized, using cmd.exe, blah blah blah" error message on Vista.[*] Allow edits directly on the center table.[*] Filled in some more of the help files[*] Display bad lines when they cannot be read from a demo file.[*] Made the resort process take command names into account.[*] Remember the launcher settings from session-to-session.[*] Added a rotation wizard.[*] Rewrote the smart cut wizard for better performance.[*] Switched to launch4j to wrap the jar for Windows.[/list]I still don't have a personal web space set up, so you can grab v0.9.1 off of mediafire at one of the following URL:

exe version for Windows
jar version for other systems or expert users

Most of you can just grab the exe version -- stick it anywhere, and it should work (provided you have a recent JRE installed...see below.) If you prefer configuring your JRE yourself or if you're running on a non-Windows platform, you should download and use the jar version. The exe version does have some memory limits, so if you plan to work with very large (ie, hundreds of megabytes) demo files, you may need to use the jar version and configure the JVM for more memory.

Either way, you'll need a recent version (6+) of the Java Runtime Environment available. If you don't have a copy, you can download one at www.java.com. The exe version *should* also point you to the correct download location if necessary.

If you're upgrading from a previous version, you can use the same config.xml file and keep all of your previous settings and saved filter lists.

As always, if you find any bugs or have any suggestions, please tell me by replying to this post, by PM, or by email. Thanks for using the program!

I'm working on that one...just not this weekend.

Hey, everybody.

I've set aside some time this weekend to do some work on the editor -- I think I have a big enough list of major feature additions for now, but if you have any smaller requests or bugfixes (other than what's mentioned above) that you want included in the next version, now would be a good time to tell me about them.

(QR)

StarDancer: Actually, I've always wanted to learn Java3D and implement an interactive demo previewer or something like that. The amount of effort I expect that would take, however, has always required more free time than I have to allocate. I do have a different project in mind that may help me bootstrap up my knowledge, though.

I'm not positive what the secondary sort criteria is, but I'll definitely try to fix that resort bug. The edit-in-place should be pretty straightforward, assuming I didn't do anything stupid in my MVC design.

PsychoPez: Piece of cake. That's something like two lines of code.

Star_Dancer: If I programmed the thing intelligently, remembering the launch settings should be easy. If I was stupid about it, it may be a pain, but probably should be reprogrammed in a smart way, anyway.

Let me know if there's anything else for the list.

Yes, the current version is still 0.8.14.

I'll stick the "save" function name on the list of things to update. Actually, I'm guessing that list will probably end up being this thread, since my current inventory of possessions contains a mattress on the floor, a suitcase full of clothes, and a laptop that I'm using to write this post.

So, if anybody has any other suggestions or annoyances or whatever, please post them here and I'll see what I can do when I finish my relocation. I know I promised some coordinate transformation tools to somebody a while back....

I'm in the process of moving to the other side of the country, so the previous download location of my demo editor will soon be invalid. For the time being, you can download the current version from MediaFire:

http://www.mediafire.com/?mqm2jkjowg5

Once I get settled in my new location, I'll hopefully have time to program something interesting for the demo editing community.

Hey, Vorac, thanks for telling me.

Unfortunately, my main computer died about a month ago, and although I still have all of the code for the program, I no longer have a computer to do development on (or play CoH on, for that matter). I'm hoping to build a new system this Christmas, and I'll try to push out an updated demo editor shortly after that.

On a side note, CoH *does* run on an Intel Atom platform with integrated graphics. However, the one team I tried out was kind of like trying to play Crysis on my old rig.