Format conversion

[nemyax]

What do I do to make A:M read and write a custom model or animation format? For example, suppose I want to use A:M to make animations for a game engine. In Blender, I write a Python script. How do I go about this in A:M?

 

I skimmed through the tech reference document but wasn't able to find anything about file I/O plugin support.

[Rodney]

Someone that is more familiar with gaming should chime in here but in the interim...

 

There are plugins for a variety of formats used in gaming and other formats can be achieved through dedicated converters from one of the primary formats.

Standard wizards/plugins for conversion include:

 

.LWO

.3DS

.OBJ

.X

 

Note that in an Action or Choreography an entire sequence of models can be exported.

The formats most often used for gaming (that I am aware of) are .X and .OBJ.

Of course the ideal format to export to will depend on the gaming engine you target.

 

Check out the Game Development forum area for more specific information.

 

Here's a screen cap of the primary export formats:

[nemyax]

I see. Is there a way to make a custom import/export plugin? Importantly, one that works with animation data, not just geometry.

[Rodney]

What do I do to make A:M read and write a custom model or animation format?

 

I might have misunderstood your question.

If you want to export to a custom format you might want to investigate the Software Development Kit (SDK).

With it you can write custom plugins to import/export to any format.

[Rodney]

It looks like you responded prior to my last post.

 

You said:

one that works with animation data, not just geometry.

 

Depending on where you are in A:M you do have some options to export motion/animation data.

I haven't used many of these so I can't comment much on how well they work in other applications.

 

Chors/Chor Actions can be exported to:

Pi Motion (Camera data?)

Python Script (This is mainly for setup I believe... not animation)

MDD (movement of geometry)

[nemyax]

Thanks! Where can I find the SDK documentation?

[wedgeeguy]

Hi Nemyax ... Animation Master's(A:M) files (model, action, choreography) are readable text files. Meaning you can load them into a text editor and be able to see how it deals with each. It would just be a matter of parsing this text file to create your own format. Depending on your game engine choice though, you would need to to be able to convert things into a format that the game engine recognizes. Personally, I export my game data to an .X file and then can convert that .X format into whatever I need using another piece of software. Mainly I work in Ogre so I need to convert from A:M files to .X to .XML to .MESH. I'm not sure if the plug-in to convert A:M's files to .X is already included with the recent version of A:M or if you have to manually install this plug-in yourself. If you have any more questions then please feel free to ask ... Bruce

[robcat2075]

Hi Nemyax ... Animation Master's(A:M) files (model, action, choreography) are readable text files. Meaning you can load them into a text editor and be able to see how it deals with each. It would just be a matter of parsing this text file to create your own format.

 

That's a great point.

 

 

I'll note that my "It Can't be Done" series introduces and explains text-editing of A:M files.

[nemyax]

Ah, the fact the formats are ASCII-based is great to know. Is there a spec for the formats anywhere?

 

And I'd still love some docs for the SDK too, please.

[Fuchur]

Ah, the fact the formats are ASCII-based is great to know. Is there a spec for the formats anywhere?

 

And I'd still love some docs for the SDK too, please.

 

As far as I know, there is no complete documentation about the formats, but there are example-plugins available, which should give you a good starting point in the SDK (I think geometry only there) and here you can get the source code for the directX-exporter (including bone-animation data): DirectX-Export-Plugin with SourceCode

Same is available for Torque: Torque-Export-Plugin with SourceCode

 

Steffen has written an MDD-Plugin too, which could be quite interesting, but I am not sure if the code for that is freely available. I'll ask him about that...

That should at least give you a good starting point. Are you trying to write an FBX- or Collada-Exporter?

 

See you

*Fuchur*

[nemyax]

Are you trying to write an FBX- or Collada-Exporter?

 

At this time, I'm considering doing an MD5 (Doom 3) plug-in. I've made one for Blender and use it regularly. But I'm also curious about A:M's animation capabilities—I'd like to find out if A:M "feels right" for me in the animation department the way Wings3D does (for me) in the modelling department.

 

Thanks for all the links!

[Rodney]

A converter for Doom would be quite something.

It hasn't been since back in 2000 or so since A:M and Doom were in the spotlight together.

 

Here's a snippet from back in 2000 from artist/animator Joe Cosman who modeled/animated for Doom/Duke Nukem and similar games etc. back in the day:

 

indeed, John Carmack is always on the 'bleeding' edge of technology. with the advent of new 3d routines, graphics cards, programming APIs and modeling packages, the future seems bright for any developer or hobbyist designing games.

 

several coworkers and I have come to a conclusion that there are certain parts to video games that go overlooked, but are very important and contribute greatly to the 'suspension of disbelief' we see lacking in most games.

 

anything to do with generating the visual aspect of a 3d shooter has been covered. we have everything we need to get slimy, droopy gooey, foggy effects and textures. to honestly say, we have all been 'prettied' out. what seems to be missing(and someone correct me if I am wrong) is accurate and entertaining animation.

 

for the most part of the new gaming development era, and especially in the 3d shooter genre, we have been using pre-animated sequences linked together to show character interaction. this would be known as scripting. player runs left(play runcycle), then strafes(switch to strafe cycle) then dies(play death sequence).

 

each of these are separate animations, and for the most part, programmers have been finding better ways to transition one to the other without annoying 'popping' artifacts.

 

something as simple as a walk cycle can be hard to make look realistic in a game.

getting the feet to stay stuck to the floor is a real nightmare, as you have to program the speed of the character moving in the game to match the walking animation you just made.

 

with the advent of newer technologies from 3d software companies, such problems can be alleviated by allowing a character to be animated procedurally. the computer puts down a 'target' and moves that around in 3d space, you bind your characters bones and mesh to these targets.

 

for example, you have just made a cyberdemon model, it has bones inside it that cause the 3d surface to animate. an animation file tells these bones to rotate, translate and scale, making your cyberdemon move.

 

instead of making a ton of animation sequences, you instead opt for a procedural method, which is less bandwith intensive when it stores animation(6 targets for the extremities as opposed to 15 bones for the entire model).

 

here is an example of how I can do this on a 3d character in Animation:Master by Hash inc(www.hash.com)

 

after my bone system is set up(meaning the mesh is attached to the bones)I can apply what is called a constraint, which tells a bone how to behave. I add an 'aim at' constraint to point my thigh bone at my foot target. I can add a 'hinge' constraint that tells the Calve bone to bend the thigh when the foot target moves up.

 

those of you building Quake3 characters are familiar with this already, because you can add 'tags'(targets) to models that tell the computer to 'put the weapon model here'.

 

once I do this, I can animate just the feet and hips instead of animating the hips, thigh, calf, ankle, foot and toe bones for my walk cycle. I have just cut my animation duties by a factor of 3(and offloaded the rest to the programmers on the third floor. ahh, the tradeoffs we must make...)

 

so a simple walk cycle for my Cyberdemon would consist of animating three bones: a left foot, a right foot, and a hip. the rest is all taken care of by the computer program. I could even tell the computer to move these targets itself, which would allow the programmers to apply dynamics and behavioural attributes to this character(as well as animate it, too.) so if I hit the cyberdemon from the side with a rocket, he would sway and have to regain his balance.

 

I can also program a walk cycle that lifted the left foot target and placed it down on a surface, then lifted the right foot target and set them down on a surface, going in a specified direction.

 

by using the latter method, when my foot targets encounter a set of stairs while walking, each foot will remain _planted_ on the stairs, instead of skidding, sliding and clipping through the stairs.(one disadvantage to premade animations. you have to make a 'walk up stair' animation if you dont want that to happen, which increases your animation duties.)

 

if your cyberdemon walks down a slope, the feet stay _planted_ on the slope instead of hovering in mid air while the body slides down the hill(hooray for the pre-animated sequences, right? :-)).

 

this type of procedural animation has a host of advantages to it. the characters stay rooted on the ground when they walk, so no more sliding feet. the filesize of animations are smaller(because the task of moving and rotating other bones is handed to the computer and you only have to keyframe 6 bones). You can attach objects to the bone targets, and attach bone targets to an object(similar to Quake3 tags). imagine pulling a shotgun away from a corpse's hand and watching the arms move with the gun, as if the corpse was actually gripping it.)

smaller filesizes mean you can add more animation to the character. instead of having 2 death sequences, you could have 20 or 30. or if you opt for programming it, you can quantize the entire set of animations into behavioural patterns, giving your character style and interaction with the environment.

 

putting the computer on the task of animating also means you can have more realistic falls and death animations. if,in a death animation a character dies near a fence, the computer puts the targets close to the fence on the fence, and places the others on the ground, which would make the character 'slump' over the fence.

 

if each of the targets were assigned a weight on a procedural death animation, falling bodies can hit the ground and bounce with different body parts moving in different directions. they can then settle on the surface(which might include other corpses on top of it.) for example: a corpse falling and hitting the base of the stairs. the torso and hands would rest on the stair steps instead of clipping through, while the legs stayed level on the ground.

 

explosions would have more punch if your victims actually hit and bounced off of walls and other objects realistically, instead of going into a predefined 'death' animation or(as id likes to do it) disintegrating into a rain of gibs.

the latter is satisfying, but not very realistic.

 

of course, collision and dynamics dont have to be applied to Just the characters in a game, they can be applied to the environment as well. blasting a wall apart, because it is made of bricks, can allow you to build a fort using the bricks that made the wall. swing along vines, throw rocks, etc. this can have alot of exciting opportunities in Network game play, as you have the ability to alter your environment as you play.

 

Bob jumps into a CTF game only to find that the base walls have been rearranged into a maze to keep the Blue team from reaching the flag easily

 

bob runs to the blue team's base to find that a hole has been blasted in the wall and his teammates are running out with the blue flag.

 

my reply is getting waay to long right now, so I will wrap it up.

 

movement is what we use to distinguish what is happening around us. the way things can move help determine what it is and what it could do. by making things move more like their "real world" counterparts, we can continue to enforce the 'willing suspension of disbelief' in our video games.

 

Apologies for the length of the above quote. I find it a bit ironic that those in that other forum Joe posted to way back then complained about the length of his post.

Could they possibly not have realized they were asking the Joe Cosman of Avalanche fame and suggesting he limit the information he was sharing with them?

When someone like Joe shares his insight into game development there really is only one thing to do... let him talk.

 

I hope this hasn't strayed too far off topic but considering your goal is to capture animation and put it into games I thought it might be at least a little bit on topic.

[nemyax]

Joe has a funny way of putting it =)

 

He describes a regular honest-to-god rig based on constraints and IK and calls it procedural for some reason. As for feet staying planted on sloping surfaces, the engine's custom real-time IK system takes care of that, modifying existing animation to conform to the terrain. Death animations are diversified by ragdoll physics—another thing that the animation-producing software has nothing to do with. There are a few facilities for real-time tracking as well (for the eyes, for example), also engine-specific.

 

 

MD5 animations are really just baked keyframes. What you can do to make your character more procedural is construct it from several independent pieces and slap some kind of logic on that in the engine. I don't remember any support for blending pre-baked animations (though I might be wrong).

[Rodney]

Of course that was 14 years ago.

Gaming has changed a lot since then.

 

I took a quick glance at your converter.

Anyone that can code like that impresses me. (your python code is well organized... you obviously aren't a newbie)

I'd love to get to that point of programming but my skills (and general capacity for learning such) are nil.

 

We need to get you connected with some of the folks who have programmed plugins for A:M.

That'll certainly get you headed in the right direction.

[nemyax]

Which SDK version is best for use with A:M V17? The FTP directory has V13 and V18 with nothing in-between. Is V13 suitable?

[robcat2075]

Which SDK version is best for use with A:M V17? The FTP directory has V13 and V18 with nothing in-between. Is V13 suitable?

 

I don't know if it matters but there has been a substantial change in the compiler that is used since about v16. And other changes in the program. 13 sounds like a long time ago.

 

Steffen could tell you but you have to wait for Steffen to get back.