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). 

step by step...

basically i start out and do my leg movements.
this is very rough, little more than the foot going up, then down and pushing backwards.

then, (with IK), i get a little bobbing motion going with the entire body.
at this point, the bobbing up and down is pretty silly and exaggerated.

now i'll try to position the spine in a static pose (for now) in how i generally want the upper body positioned. so if it's a full tilt running, then i bend the spine way forward, otherwise, i mostly just get it into a decent walking position. (maybe hunched over if it's an evil ogre)

at this point, i start to smooth out the feet so that they look as good as i can make it. with IK, hips won't affect it, and i can always tweak later if i have to anyway.

next up will be to get to side to side motion of the COG/center of gravity done and to make the up and down motion more realistic as well.
the side to side motion is important. without it, the animation can look wooden but not immediately obvious why.

now that the COG movement is done, i do the hip tilting and then the spine sway/compensation stuff.

afterwards, assuming everything looks ok, i'll do the upper body rotation (lots for running, very little/none for walking)

finally, i do the arms.

i do the arms last because otherwise, i'll have to keep going back and tweaking them every time i change something in the torso, or anything that affects the torso. (i rarely do IK on hands, although biped has the option to toggle it on and off). 

if you have ne_ruins, open up pak0.pak and open the zombie2.mdl in qme.

i left the oldrun animation sequence in there for some reason. compare oldrun and run for hips/COG swaying. 

I don't have a method of my own, but I do remember learning quite a bit from a tutorial by Paul Steed. Although Paul is probably most fondly remembered for being the driving force behind the Start-To-Crate rating system, archive.org hosts the tutorial:
http://web.archive.org/web/20030621121346/http://www.loonygames.com/content/1.22/totb/index2.shtml
It's a shame the videos are missing but all the images are preservered 

that's pretty cool. shame about the missing animations as i imagine they would really illustrate his points.

i didn't mention it, but his tutorial does on page2: make sure the feet (when on the ground) are on the center line of motion, not just moving forward and back. the overall motion of the foot is more of a very wide arc instead of a line. 

Having a skeletal rig is a good tool for animating models. Takes some time to construckt though.

Made some dynamic turbulence in the waterfall.

http://members.home.nl/gimli/farl.gif 

 

Brilliant!

What's it like with a texture: water, lava, b-l-o-o-d...