Can’t ride a horse without a back

Last Updated 05.06.2019


  • Build your spine


  • Understand the basics of the segment rigBlock
  • Explore what you can do with it

Suggested Reading

The following from the docs

  • Segment
  • Builder
  • RigBlock States
  • RigBlocks

A horse needs a back to move, for our other characters to sit on and, more practically speaking, to attach legs, heads and a neck to.

The segment block is one of our blocks that can do a number things. We use it for spines, tails, ears and more. It is for bendy sections or rig rather than hinged for which we use a limb rigBlock.

We’ll be looping back to hit segments after a few modules but for now we just want to worry about the spine.

Starting Point

If you haven’t done so, open up your file from our master session. You should have:

  • Your master rigBlock at the skeleton state
  • Any reference you want ready to go

Let’s begin.

Intro to Segment

Before we actually get to making our spine I wanted to go over a little bit about rigBlocks in general as there are a number of concepts we want to hit on in this material.

Segments are for flowing chains of joints like a tail, neck, tail or tentacle.

We have a number of segment block profiles.



Let’s make our rigBlock

  • Open up the mrsBuilder. | cgm Top
  • Add the rigBlock to our scene | Add> segment> spineFwd.

This will create our new rig block.

Should look something like…


Use the rigblock and define handles to position your rig block on your design or model.

  • Form – You’re not worrying about the pivots here, just bounding box your frame
    • Put the rigBlock root on the rump
    • Put the end define handle at the front
      • The end handle has length, width, height attributes if that’s helpful
  • Up – Check your up handle to make sure it’s where you want it.
  • RP – Ensure the rp plane is oriented how you want. Generally speaking the rp plane is through the main axis of rotation for that chain.


There are a lot of settings with segments. For my setup, I’ll leave our defaults as they’re good for spine but there are plenty you can explore. I’ll flesh out the shared settings docs with more visuals when I get some cycles. You’ll find more info there. But the ones we’d want to look at:

  • ikBase |  For our spine we’d want hips but you can explore the other options
  • ikEnd | For our spine we have tipEnd though some might like tipBase or tipMid. Something to try
  • ikOrientToWorld – We discussed this on build from base. You can use this or not. It doesn’t matter to the setup
  • ikSetup | We’re pretty much just using our ribbon though we have the framework for other setups and you could potentially
  • loftShape|– If you have a shape in mind you can change it before going to form. If you’re not sure we’ll look at changing that in the next section
  • numShapers | The number of main shaper handles
  • numSubShapers | The number of sub shaper handles between each handle.
  • numControls | We find 4 to be a good number for a spine with 1 being the hip and 3 for the spine section itself. You’re welcome to try more.
  •  numJoints | For game work we’ve been matching our control count but you can try whatever number you like
  •  segmentMidIKControl | If you want a mid torso IK control or just a two control ribbon.
  • spaceSwitchDirect | If on, each direct control will have space switching setup. We have some concerns on speed for this but if you want the option it’s there.


Next we need to shape our spine. First, push to form state.

  • Select your spine rigBlock in mrsBuilder | 'spine'...
  • Change state | <Form>.

Take a look at the handles you have to work with. Most of this should be familiar from our biped rigs. Look at the handles section of the segment documentation for an overview.

Before digging in too much let’s talk about loftShapes. So you’ll note that by default loft shapes are circles. We’ll come back to that in a moment.

Take time to shape your torso to match your look. It doesn’t need to fancy but something close would be great.

Note – Turning on default material helps usually

  • Form handles | Use these to generally shape
  • Loft curves | These are used to
  • Orient helper | Make sure it goes the direction you want

What if you want another shape?

Changing the loft shape

Save your block dat

Before we change out shape we want to save our blockDat so we can pull it back.

  • Select your spine rigBlock in mrsBuilder | 'spine'...
  • Save your block dat | BlockDat > [Save]


You could have done this at the define step before going to form

  • Select your spine rigBlock
    • Method 1
      • In mrsBuilder, select the rigBlock | 'spine'...
      • Select | Utilities > [Select]
    • Method 2
      • Select the rigBlock dag in the viewport
  • Change the setting
    • Change the enum in the channel box


  • In mrsBuilder, select the rigBlock | 'spine'...
  • Force a rebuild by pressing form again | Push > [<Form>]

Reload your block dat

Now we can bring back our shaping.

  • Select your spine rigBlock  in mrsBuilder | 'spine'...
  • Load your block dat at this state | BlockDat > Load State....[Form]

Note – Currently you can replace out the loft shapes this way however, if you change the count of shapers/handles. This method will not work and you’ll have to reshape your setup.

What are we looking for?

  • Shape| You want your form to generally match the look you’re going for
  • Up| Ensure the up orient is pointing where you want


Let’s go ahead and push to prerig.

  1. Select the master block 'spine'... in mrsBuilder
  2. Then hit <Prerig> | This is to push to preig state

Let’s look at the prerig handles again.

Prerig handles[1]

The default prerig handle is a two part control. There is a split so that we don’t have to have our rig dags match our joints unless we want to.

Dag Handle

The 3d axis looking control. This dag is to define our actual points of articulation structure.

Joint Handle

The sphere shape is the joint handle. The prerig joint loft runs through these.

  • When the joint count matches the handle count these are the exact positions that will be used
  • When the count is different, the splits will happen along a curve very similar to the joint loft

Prerig IK Orientation handle

Sometimes there are special prerig handles that are designated by a colored 3d axis and a black sphere around it.

This denotes that this is an orientation handle. For example, the ik wrist or ankle would use this controls orientation rather than the joint.

Cog Helper[2]

This is our Cog helper. There are two parts to it, the dag and the shape.

  • If you select the pyramids, that’s the shape and you can move it it irrespective of the dag.
  • The dag is represented by the curve text ‘cog’. You can pick walk up once from the shape to get it and move both
  • At rig time:
    • The dag is where the rig Cog dag is generated from
    • The cog shape uses our shape helper
  • It only builds if we have addCog True on your rigBlock
  • The joint loft represents what our joint chain will be at the skeleton state

Joint Loft[3]

The much thinner lofted surface running through our joint handles is for visualizing the joint chain.

What are we looking for?

  • Handles |  Place the points of articulation where you want them. Use the jointLoft as a visual guide
  • COG | you can try different positions for the cog. Remember you can place the dag and shape separately


This state may not be the most exciting but it is important. We want to pay special attention to the orienations after build to make sure they are where we expect them to be and oriented the way we want.

Go ahead and push to to skeleton state and you’ll see a joint added.

  1. Select the spine block 'spine'... in mrsBuilder
  2. Then hit <Skeleton> | This is to push to skeleton state

Changing Counts

One important thing to note is that we can easily change joint counts. Handle counts require re-prerigging but skeleton we can change at will.

  1. Select the spine block 'spine'... in mrsBuilder
  2. Double click it to make it the active block
  3. Go to the active blockDat section and change the numJoints value
  4. Press the <Joint> button again

What are we looking for?

  • Joint orients | make sure they look like we expect
  • Joint parent | make sure the root of your chain is going where you expect. When we get to the head for example, we wouldn’t want that root to go to the pelvis.

Now that we have a skeleton where we want it I’m going to rig.


Save off your file as to be safe we’re not going to be saving rigged blocks in our working file. In my case my file is:

You can name yours what you like.

Go ahead and push to to skeleton state and you’ll see a joint added.

  1. Select the master block horse in mrsBuilder
  2. Check below | to make our context include our spine
  3. Then hit <Rig> | This is to push to rigstate
  4. Wait for it to complete


There’s a lot of things happening when we rig.

  • rigBlock – Our rigBlock is has its .template attribute turned on so that it’s easier to not inadvertently select it post rigging
  • Dag structure – created and setup for all our rig setup for both this block as well as others
  • Shapes – Different nurbs control shapes are generated
  • Rig wiring – The rig is wired so that we can get all the information we need once the rigBlock is removed from the scene. Remember it is a frame to build the rig and  designed to be removed once we have our asset completed
  • Dynparent setup – Based on our settings, the master will have our dynParent setup added as well as spacePivots for that system

Please refer to the segment [rigBlock] documentation for further breakdown on these items and more info.

Dag Structure

For those that care about the rig structure

I’ll lay them out and then discuss them briefly.

  • spine_segment(dag- cgmRigModule)
    • spine_rigNull(dag)
  • spine_segment_deform_grp(dag)
  • spine_segment_animSet(objectSet)

Module Dag/RigNull

The spine segment dag is a tagged mClass node of type cgmRigModule[LINK THIS WHEN DONE]. This is a special kind of dag that holds most pertinent information for the rig wiring.

  • Non transforming dag | this dag is for non-transforming dags/nodes

Deform Group

We have a deform group that is placed under the master control deform group.

  • Deforming nodes for the rig go here.
  • Sometimes I have a separate constrain group under this
  • Typically rig controls end up in here

Object Sets

Each rig Module gets it’s own animation objectSet to which all rig controls are registered

  • spine_segment_animSet– Master anim set for puppet controls. Sub modules have their own sets added to this one

Our object sets are created as cgmObjectSet mClassed nodes which extends their usability in code.


The kinds of controls you see will depend on your rig options for the rigBlock. In our case we start with something like this.


The cog [1]  we looked at previously. During the rig process our cog dag helper has a transform created at it, then the cog shape helper is shape parented to that new transform to make the control.

Because of our options, our cog is our settings control. This is an option. If you had had it off, you might see a gear instead.

Note – Many of these attributes would not be on this control should we have a separate settings control


  • FKIK | float |  Blend between fk/ik mode. It controls that blend as well as the visibility of those controls.
  • visSub | bool | Whether or not the subcontrols of this rig section are visible. In our case, we only have one. If we had used more joints than controls, we’d have more of these.
  • visDirect | bool | Whether or not the per joint controls of this rig section are visible. By default they are cube curves. When the build option of proxyDirect is checked. The proxy mesh replaces those curves.
  • axisAim/Up | enum |  Settings for our aiming system. If you use raycast aiming or other systems these settings will be used per control. If no settings are found, the global defaults will be used.
  • pivot_0/1 | enum | Same as discussed for master.
  • blendParam | floatDetermines how the joints follow the ribbon surface. Floating evenly or fixed to their attach point
  • space | enum | Setup by the dynParent System. Space would denote a parent setup.

Base/Mid/End IK

We are seeing the ik controls  because we are in ik mode

  • Base IK | Hip shape [2] at the base of our spine
  • End IK | chest shape [3]
  • Mid IK [4]


  • axisAim/Up | enum |  Settings for our aiming system. If you use raycast aiming or other systems these settings will be used per control. If no settings are found, the global defaults will be used.
  • pivot_0/1 | enum | Same as discussed for master.
  • blendParam | floatDetermines how the joints follow the ribbon surface. Floating evenly or fixed to their attach point
  • space | enum | Setup by the dynParent System. Space would denote a parent setup.

Segment Handles

We only see one [5] but as we mentioned. The number you see will be determined by our build options. When our control count matches our joint count we don’t need an extra ribbon as we can use the main. When we have extra joints we have a separate ribbon which these controls would influence.


  • followRoot | float|  What the control follows. Be it the root or the blend frame.

FK Controls

If we turn on fk mode we’ll see the fk controls.

Note the shapes hug our proxy we shaped during the form state.


  • axisAim/Up | enum |  Settings for our aiming system. If you use raycast aiming or other systems these settings will be used per control. If no settings are found, the global defaults will be used.

visControl (ON MASTER)

Rember back on the master. The master settings has a new attribute registered with every module that builds that lets us see/interact with our rig guts.


  • spineSegmentRig[bool] — toggle to hide/see but not touch/touch the rig guts

Exploring Options

You can experiment with other processes and options.

Take the spine block back to skeleton state

Options to try:

  • Test your spine
    • If you don’t like the points of articulation, move them
  • Building with different options
    • Different joint counts
    • Try other cog placements
    • Try the different ikEnd options.

Post Processes

Verify Proxy

Remember you can very your proxy to have geo to see while you’re moving things around

And after that?

Let’s give our horse the ability to see where he’s going.

Josh Burton

[MRS Project Lead | CG Monks] Josh is an animator turned TD who hails from Oklahoma, pre-undergrad in the Marine Corps, animation basics at Savannah College of Art and Design, cut his teeth in gaming and commercials before co-founding CG Monks and more recently the CG Monastery. The Morpheus Rigging System is a culmination of years of R&D and he is now thrilled to see what users can create, collaborate and expand on with this open source MRS platform.