sock: try out blender first to make sure you don't mind it.

if you are familiar with mainstream editing packages, it could be painful. 

I keep saying Finally too much, but I think I have my first rough (extremely crap) ogre model animated. Probably the most painful thing I have done in my games life and I after playing red777 yesterday I can't believe the monsters in quoth and how much effort it must of taken to animate them.

http://www.simonoc.com/images/design/sp/ogre2.gif

My ogre is suppose to be a similar (style wise) to the Hell Knight. These ogres make the armour for the Hell Knights and they like it so much they have adapted parts to their own needs.

Process:
1. Create model in LW and skin in PS
2. Skin/UV in LW
3. Break model down into mesh/uv triangles
4. Export 3DS format
5. Import to Gmax
6. Weld all mesh/uv triangles
7. Setup bones and weights (borrowed heavily from preach model)
8. Export to MD3 (with object name filter)
9. Compiled it with utility from Preach.
10. Fixed skin with Qme

@Preach, thank you for all the help, I am sure I asked too many stupid questions. No worries on email, I assumed you were busy.

@ijed, that utility you linked is amazing! I just did a quick test from LW scene manager, exported with FBX format and straight to MDL format! one step for animations, mesh and UVs!

My next trip into Q1 modelling is to try a pure LW pipeline with Noesis. I am sure something is bound to go wrong but at least I will get the chance to learn another modelling package animation system. 

@necros, at this point I only know bits of different packages and every application is new to me. I have never done animation stuff before, always done static mesh. The whole process is just one big painful learning curve, but it will get better. I sort of understand animation/bone systems (Max version) now I am going to torture myself by learning LW animation system next! 

That looks fucking awesome! 

About Quake animation is that it's practically pose to pose, you don't have to worry as much about timing.

I'm pretty useless at animation, but a lot of cell animation tutorials have helped - like this one http://www.idleworm.com/how/anm/02w/walk1.shtml

Nothing special, although I wouldn't want to do it outside my comfort zone of 3dsMax :) 

thanks for posting that ijed. i was going to mentioned traditional animation because it's very relevant (probably even more with quake due to 10fps).

it can even help to do the movements yourself in a mirror to get an idea of where you want your keyframes to be (close your blinds so you neighbours don't think you're insane).

it's about expressiveness. speaking about quoth, the drole was the first monster i animated, and i find his movements are not expressive enough. it's hard to tell what he is doing between running and swinging for melee attacks.

also, regarding death animations, make sure that when they die, they keel over immediatly. again, the drole's death animation is cool, but slow and when watching demos, i almost always see players continue to shoot at droles that are playing their death animations.
it's important to communicate that the monster is dead as quickly as possible.

be expressive, but don't go overboard. if you can communicate what you want in 4 frames, don't take 12 to do it. 

The thing I like about Quake animation is that it does not need to be perfect AAA quality and can have some goofy poses and body movements. The monsters also don't have to follow exact anatomy guidelines and have some funny shapes like crazy fat arms.

The hardest thing about modelling Q1 monsters for me is knowing how to setup the skeleton. Example layouts of bone structures was something I struggled with for a long while and had to do a bit of research with gmax tutorial examples.

I also can't believe after all this time how little information or tutorials exists on the whole pipeline for creating a monster in quake. I know writing articles is time consuming and painful but there is so much cool information people here know and it is not easy to access. 

Is kind of cartoony at its core. The art is excellent for its time, and many studios now don't have that kind of focus when doing assets.

For example I showed the fiend to someone in the office and they were very impressed at how precise every single vertex was - no waste in the movements, even though looking at it in a 3d package makes it look like a deforming box kite, or even more apt, a papercraft: http://www.youtube.com/watch?v=mi3fy3IVA-M

And good advice about the death - I'd add that make sure the monster has a unique death scream sound, that is fired in its first frame of death animation and not easily confused with its other sounds.

Going nonsolid in the same frame is desirable as well.

As to dev documentation, its almost a lost art because of the age of a lot of the processes. I will get round to writing something sooner or later - every now and again I have to bang out a few pages on something just to keep the goals and backstory in mind, might as well be some how-to's for the next one.

At least tools like Noesis open things up a bit and give various routes to getting things right, as opposed to a single one that only works after hours of trial and error. 

A link to the rest of the guy's paper models:

http://cow.mooh.org/paper/

All taken from the original meshes of the monsters.

I think this is called nerdcore :) 

Seems like the links are 404 

or anyone else (stupid enough) modelling q1 monsters in gmax!

Problem 1 - Stationary objects having strange movement between frames
Solution - Double frames

Frame / Description
-2 T Pose
-1 Duplicate of Frame -2 (This extra frame makes sure no 'loose' object movement
0 Standing Pose
1 Duplicate of Frame 0

All frames are affected by previous frames and the double static frame prevents previous movement from affecting new frames. This may well be fixed in modern day versions of max, but gmax is v4 (very old)

Problem 2 - Objects do random 360 rotations between frames
example - http://www.simonoc.com/images/design/sp/ogre1_stupid1.gif
Solution - Use local rotation ONLY

This one had me going round in circles for ages, the default in gmax is view rotation which screws *most* animations. I thought I had some bones rotated/setup wrong and re-created them several times in different ways and it made no difference. It was just the default rotation mode is fuckin useless. (wasted days of time on this stupid default)
Once I used local rotation mode, the animations worked perfectly. 

There's a common problem in regular max when flipping bones, usually to make the right/left side arms/legs.

The flipped versions get a negative scale which breaks most exporters. This can be fixed by using animation/bone tools/mirror mode from the panel.

No idea if Gmax has this panel :) 

I still get the rotation bug almost every time I rotate a bone with gmax. I have rebuilt all the bones every way I can think of, not used mirror and still get constant rotation lock problem. There must be a way to prevent this, otherwise I will never finish animating anything.

After two weeks I finally have an idle animation, I feel like I want to jump up and down with glee, but I know it is just an idle animation, probably the easiest thing to make! (it should be)

http://www.simonoc.com/images/design/sp/ogre3.gif
http://www.simonoc.com/images/design/sp/ogre3b.gif (Alternative) 

Armored Ogre ! Very nice ! 

There are ways to avoid using the double frame trick, by setting the tangent type to linear or step. This link is a brief outline, better resources are probably out there:
http://billysalisbury.com/Learn_Max/chapters/lecture6d.htm

The way I try and avoid the random 360 degree rotations is where possible to never rotate the bones! Instead if you move the bone below the target bone in the heirarchy then the IK seems to always perform the shortest rotation.

The track viewer is also sometimes useful to diagnose weird problems, although it's quite overwhelming at first. 

@Preach, thanks for the link, that is very cool explanation of the transitions. I will save that off to my MD. I looked at your ogre and I could not see any IK bone setup? How did you move all the bones while avoiding rotation? It is hard to tell at this point if it is my setup of the bones that is the problem or gmax! :P 

There's no IK or angle constraints because I'm lazy about that kind of thing. However, the bones are connected parent-to-child in the default way, which creates a constraint. When you move a child bone, the parent bone rotates to match it it, but the generated motion is more friendly to rotation interpolation (I assume that it's calculating the relative motion in the keys automatically).

The main difference between this and IK is that it only extends to the immmediate parent, and so the child is locked to the radius of the parent bone. If it was IK then you could move the hand away from the torso and both the forearm and upper-arm bones would straighten to allow the motion. Without IK only the forearm would move, so to get the hand further away you'd have to move the forearm first, then the hand.

As a last tip, sometimes you do need to rotate things directly. In those cases I've found that what usually provokes the wild backwards rotations is inserting a rotation between two existing rotations. Wish I knew how to fix it, but better to know what to avoid than nothing at all... 

@Preach, I can't believe you animated your ogre model without any IK solvers or constraints! The rotation issues on bones are extreme without any rotation helpers and not using rotation is not really an option.

I think I found a workable solution for Gmax (3dMax people get biped auto-magic bone setup, so this post is pointless to them).

I setup legs, arms, neck, back and chainsaw with IK solvers, added constraints to top arms/legs and tweaked various inherit rotation blockers to shoulders, pelvis and hand/weapons. In order to maintain rotation on hands and feet I added a dummy_helper into the chain and linked the IK solver to the helper instead of the end bone. The helper is linked to the end bone and the IK solver still thinks it is a valid connection. To make sure the solver bends the bones in the correct direction I added a slight bone twist to the middle joint.

As far as I can tell most rotation issues come from bone inheritance, with child bones doing full 360 rotation to re-sync with parent bones.

Probably the sadest thing about this whole gmax route is that I found out yesterday that I can download the latest version of 3dmax (ex pro/student license deal) and use the auto-magic biped bone system instead. I am assuming I can use Noesis to export to q1 model format?

The silver lining to this whole Q1 model process, I sort of know my way around 3dmax now! :) 

You're usually better off rigging yourself than using Biped, and it's fun to learn! ;)
You should look into the swivel angle stuff if you have any problems with your knees rotating weirdly.

Also, not quite sure if it's what you described, but if you want your feet bone to stay in the proper bone hierarchy, and not have it rotate when you lift the IK controller, you can create a second IK from the ankle to the end of the foot, and parent it to your foot controller (the dummy), so when you lift the dummy your foot will stay aligned to the floor.
This should give you the same result as what you described (if I understood it right), but it's cleaner cause you're not mixing your bone hierarchy and your controller hierarchy (which is good, cause ideally you're only placing animation keys on the controllers, so you can always change your skeleton, and as long as the controllers are the same your animations will always be good). 

bal, i think i know what you're saying about biped vs your own rig.

i learnt originally from building my own rigs too, but i remember the first time i used biped and how much it takes care of on it's own.

i guess the real barrier to using biped is just the massive amount of stuff you get, some of it not at all useful for quake animation.

otoh, using an up to date max means there will be lots of relevant tutorials. 

@Bal, I did that for the back and neck, two IK solvers in a row. I did not realize it could be done and create my wacky foot setup first. Then when I realized you got to use controllers on bones otherwise you get crazy rotation time, I experimented more and saw you could chain the solvers together. It is very cool what you can do, I just wish there was a way to play with the joint between the two bones, like it had a handle you could drag around as well.

I imagine the biped magic button in 3dmax 10+ has its own problems with setup, but at least it is a good starting point. I just wish I found more help earlier on when I was creating the bone setup for gmax. From all the internet searching I did, not many people talk about it. 

When you create a walk or run animation do you create it in layers? like move feet first, then torso and finally arms? Or try to move all of it at once frame by frame? 

are you talking about animation layers, which is making animations in layers like in photoshop (allowing very similar things to what you can do with layers in photoshop) and combining them after?

or just which parts to animate first?

for the former, i don't know :P
for the latter, i like to start with feet/legs first. once i have the rhythm i'm happy with, i start in on the hips and the continue working up.
at the same time, i don't do feet/legs 100% then hips 100% etc... i like to iteratively tweak it because it's hard to judge what's a good movement if you can't see the whole thing at once. 

I mean passes, like which bits to work on first and what to do next. Working on the model from the feet up makes sense, just was not sure if I was doing it right or not.

I am assuming it is feet, hips, torso, shoulders, head and finally swinging arms? (layers of stuff to do during a walk animation) 

yeah, i usually do arms last because they're basically secondary movement (movement as a result of).

hips and spine i do all at once, i found the upper spine depends on the hips (how much they sway vs how much upper body is compensating for the sway).