We decided to make a fictitious dinosaur from the ground up. We wanted it to look like a T-Rex but better - bigger forearms, a slightly smaller head. We also intend to make it extremely muscular and hungry looking… sort of like a bony old bull… after all the whole point is to show off our ACT software driving the skin with muscles and bones underneath! It is very important to make sure that you are well organized and that your base model is very clean with no strange transforms or stray modifiers to mess you up later. You also need to set naming conventions, viewport display, file naming, directory, material and a whole lot of other stuff if you want to keep a big project like this one under control and efficient.

Bones System - or not?
In Max 4 any object can be a bone and participate in IK… so there is no reason to use Bone helpers except perhaps for display speed. We decided that it was an added layer of complication to have a Bone Helper skeleton when we need a "real" skeleton in any case. Displaying a simple set of real geometric bones is so fast now that there is really no reason to have a separate bones helper system. This is typical - we recommend always having a real skeleton only as your underlying foundation - just like in the real world.

Reference Material
After raiding my son's (Aidan, 8 years old) room to get his dinosaur books we decided on a blend of T-Rex and Allasaurus. To make things easy we also decided to start with a low rez human bones structure we were familiar with and modify the bones to suit… just having to build the head, teeth and pelvis from scratch. The resulting bone structure looks very credible and is as biomechanically sound as we need. Some of the things we did to the bones to make them suitable for a dinosaur were to make them thicker in general, make the joints much bulkier and add large spines to the vertebra.

Is the Shape Right?
It's important to view the model from all angles and imagine it in motion… I am reasonably happy with the model we have come up with. We created a simple run cycle just to get a feel for the model in action. After looking at it we enlarged the teeth and added more vertebra to the tail. The knees were also pointing in a bit and the ribs were too wide between the knees - this gave problems during running. You can't expect to get everything right before fully animating the model - but you should try to get it as close as possible.

Editable Poly objects are slightly faster and more reliable in Max…
The bones are either Editable Poly or Patch objects. They were all Patch objects to begin with. Where there was no significant change in shape on subdivision we converted Patch objects to Editable Poly objects for preference. We only kept a few bones as Patch objects where they lost significant features when subdivided as Editable Poly objects.

For the Editable Poly objects - All the viewport subdivision levels are set to 0 and the render subdivisions enabled and set to 2. After selecting all the geometry in the scene this is done with a simple MaxScript… for obj in selection do (if classof obj == Editable_Poly then (obj.iterations = 0; obj.userenderiterations = true; obj.renderiterations = 2))

Clean up Transforms:
After modeling all the bones we then made sure that the transforms of all the objects were reset and that everything was collapsed. You do this with the Reset XForm and Collapse Utilities (to Modifier Stack result) applying them to all objects at once in that order. This gives you a nice clean set of objects for the next step… the last thing you want is weird scale factors and other oddities in your skeletal bones (or any object for that matter).

Setting Pivot Points
The next step was to set all the pivot points. This is relatively straight forward except perhaps for the vertebra and Radial bones (lower arm bone that rotates). The vertebra do not have a single pivot point. A good approximation is to use two pivot points - one for twisting around the spinal chord and another for the other axis. However for our model we opted for a compromise and a single pivot point for each vertebra. We can get away with this because there are so many vertebra that there is very little rotation in any one - so a small error in pivot point will not matter. Wherever possible we will follow the convention set by Biped in determining axis orientations - this will make animation as standard as possible when driving it from a Biped and also maintain familiar axis for users experienced with Biped. X will always look at the next joint. IF a joint has a single degree of freedom that will be the Z axis.

Naming Conventions
We also established naming conventions at this stage. Everything is prefixed with mSaurus (standing for Muscle Saurus) and all bones have correct anatomical names prefixed with _L_ for left, _R_ for right or _C_ for center (ie. Vertebra). So the right radius bone is called mSaurus_R_radius. Control objects will be prefixed with mSaurus__ (whether helpers or geometric controls) and will be green. Parent helpers will have the suffix _p. Control objects that are not intended for user interaction will be red in color.

Special Helpers, Lights and Camera
The root helper will be called mSaurus__root and is a large point helper displayed as a box. There is also a Center of Mass helper called mSaurus__COM. A standard light rig of 4 instanced fill lights and one key light is created with the fill lights set to a sky blue and the Key to a warm sun color - all cast shadows. All these are named correctly and linked to a helper called Light__Parent that is positioned at the mSaurus__COM. There is a single target camera with a standard 35mm lens that is parented to a camera__parent point helper also positioned at the mSaurus__COM. The camera is positioned so that the subject is mostly within the action safe area for 3:4 aspect render. The Light__Parent is colored yellow and the camera__Parent is colored light blue.

Other conventions
Frame 0 will be the master reference frame and will NEVER be animated or modified after sign off at each stage. This is essential for all sorts of systems - character rigging controllers, skinning, vMuscles, skin deformation… Only allowed transforms will be enabled - locks will be put on all other transforms. This is done in the Hierarchy panel under Link Info. The default character pose will be consistent with the standard track view views - front, back top and bottom (note that left and right appear to be wrong - but that's simply because when the camera is pointed right you see the left side).

Default Animation
The animation duration is set to 0 - 359 frames and the frame rate to NTSC. The camera__Parent rotation controller is Euler XYZ and the Z rotation is keyed to 359 deg rotation - looking at the mSaurus__COM. This gives a perfect looping rotation over 6 seconds at 1 deg per frame.

Using Scripts For Modeling
We use MaxScript interactively all the time to do bulk renaming and setting of parameters like subdivision iterations or helper size and color. This is much faster than hand editing and avoids typos. I can't stress strongly enough the benefits of learning just a little MaxSCript - it's so easy and powerful.

Materials
Every piece of geometry is assigned a realistic material with a meaningful name. It is never too soon to get your materials in order! You also want to make sure that the material editor is left clean - with one copy of materials in view only and any unused materials removed. You should start a dedicated Material Library at this stage also.

Tutorial 1 | Tutorial 2 | Tutorial 3 | Tutorial 4 | Tutorial 5 | Tutorial 6 |