BP_Spline_V2

Instructions:

1. Open the BP_Spline scene.
2. Open the spline3.ms in your maxscript editor.
3. Select the entire contents of spline3.ms and hit ctrl + Enter to evaluate all.
4. In the max scene you can translate the SplineBone1 and SplineBone5.  Eventually I will layer control objects over those.

Hopefully you will get an idea of what I am going for.  All that is left to do is…

1. Create control objects.
2. Hook up the Swivel Angle of each IK handle to the control objects via an expression.
3. Clean up and comment my code.
4. Bask in the glory of a job well done.

SplineModule <— Download

Back to the Production Blog

Thus far I have written some simple code that will find the children of the root template object.  I have hard coded the name of my root object for testing purposes, but later on I will identify the root by looking for it’s object properties.  I then find the child of each template object, and create pairs of parent and child object which are then stored in an array.  Using that array I can build sets of helper objects that are later used as the start and end joints for ik chains.  At this stage my code is messy and full of notes and comments, but I am ok with that.  In my time as a Technical Artist I have learned several important lessons, but I think these two lessons are of paramount importance when it comes to any endeavor.

1. Show your work often.
2. Quickly make your mistakes so you can get them out of the way.

Thanks again for reading my ramblings.  Before I log out, I leave you with my code.

--struct bp_info (bp_name, bpChild_name, bp_xform)

-- Function to get all the children of a defined object
fn addChildren obj hierarchy =
(
	-- add object to the array
	append hierarchy obj
	-- loop over children and recursively add their children
	for child in obj.children do
	addChildren child hierarchy
	hierarchy
)

fn addSubChild =
(
	bpData = #()
	c = addChildren  $BP_SplineRoot #()

	for i in c where i.children[1] != undefined do append bpData #(i, i.children[1])

	return bpData
)

fn drawBone =
(
local bpBones = #()

stuff = addSubChild()
for item in stuff do(
	parentBP = item[1]
	childBP = item[2]

	parentBoneName = substitutestring parentBP.name "BP" "Bone"
	childBoneName = substitutestring childBP.name "BP" "CapBone"
	parentPos = parentBP.transform
	childPos = childBP.transform

	new_ParentBone = point name:parentBoneName size:10 box:on cross:off
	new_ChildBone = point name:childBoneName size:5 box:on cross:off
	new_ChildBone.parent = new_ParentBone
	new_ParentBone.transform = parentPos
	new_ChildBone.transform = childPos
	new_ParentBone.wirecolor = color 140 88 225
	new_ChildBone.wirecolor = color 196 88 225

	append bpBones #(new_ParentBone, new_ChildBone)

	)

return bpBones

)

fn drawIKSpline bpBoneData  =
(
	-- Draw an HIK between each parent / child grp
	for ikBone in bpBoneData do(
		solverName = substitutestring ikBone[1].name "Bone" "IK"
		IKChain = IKSys.ikChain ikBone[1] ikBone[2] "IKHISolver"
		IKChain.name = solverName
	)
	-- Question: What is .count for?

)

fn mainFunction =
(
local bpBoneData = drawBone ()
local ikInfo = drawIKSpline bpBoneData

)

mainFunction()

-- These are some new concepts I got.  I will save them here for later.
--data = #()
--for node in helpers while data.count == 0 where node.children[1] != undefined do append data #(node, node.children[1])

--for node in helpers collect #(node, node.children[1])

Back to the Production Blog ]]> http://griffinanimation.com/archives/952/feed 0 http://griffinanimation.com/archives/939 http://griffinanimation.com/archives/939#comments Thu, 26 Apr 2012 17:10:07 +0000 admin http://griffinanimation.com/?p=939 Continue reading →]]> It has been to long since I posted on this project, but I do hold down a full time job and I have a family that gets upset if they are neglected for too long. I am happy to report that I have been making some great progress. I simply wanted to get my work to a certain point before doing a write up. This morning I made a major breakthrough where I finally got the whole rig working as expected. I can now successfully transfer animation data from motion builder to a mocap skeleton in Max. The mocap skeleton then drives my custom animation controls without keying the controls, thus leaving them free for hand keyed animation. Before I show the fruits of my labors, I want to talk about the rig and some of the design choices I made. I found that it was easy enough to hookup things like FK controls and IK arms. The real problem areas were the feet and spine. I could have gone with a simple FK solution for the spine and a straight reverse foot for the feet, but I wanted to use something that was a lot more animator friendly.
The Spine
I tried a lot of different things when it came to the spine. Originally I thought I could do something like a Schliefer spine, but the built in spline IK in Max just plain stinks. I then thought I would try my hand at a ribbon spine, which actually worked well, but was a nightmare when it came to solving for my mocap skeleton. I finally ended up creating a custom solution which is similar to a spine rig I got years ago from this book.
The spine uses a motion path to control the position and aim of my bind bones. The twist is controlled by several HIK chains hooked up through float expressions. Here is a video of the spine in action.

The Feet
A good foot rig is hard to come by, and I have spent a lot of time experimenting with different designs. Generally I prefer an attribute driven foot that uses an Ik solver to keep the ball and toe planted on the ground. The IK handles are grouped under dummies that are arranged like a reverse foot, and the rotation of those dummies are controlled by custom attributes on a main foot control. I don’t plan on creating a tutorial for this setup as hundreds probably exist by now. The tricky part of the foot setup is getting the mocap skeleton to drive the attributes without locking up the ability to create hand keyed animation later on. To be honest, I am still working on perfecting this part, but thanks to Brad over at RiggingDojo, I am very close to getting it just right.

I will get a couple images up showing the animation controls at work along side the motion capture data. I am away from my home machine ATM.

What needs to be done?
I think my rig is pretty solid, although I have yet to polish the skin weighting Next I want to work on creating a nice space switching system for the arms, legs, and weapon controls. I also want to go in and fine tune a few details, and make sure that everything is still working with animation layers. Lastly, I want to rebuild the whole rig, because I have been patching things together for the purposes of rapid prototyping. Now I need to clean up my mess. Rather than build everything from hand again, I intend to use Maxscript to do my work for me. Fortunately I have been scripting out parts of this process as I go, so this hopefully won’t be an enormous task… yea right.
In closing, I would like to thank everyone that helped me get this far. You know who you are, and you ROCK! I will like to give a special thank you to Denis Trofimov, with whom I have the honor of working with. Denis has been in the industry forever and has been using Max since the day it was born. You may even be using some of his tools without knowing it. Perhaps you have have a script that starts with LUX or DT? Anyhow, I am very grateful to have Denis as a constant resource, even though I feel like my brain is going to burst from the constant information dump. Funny enough, I am assisting Denis with some Max auto-rigging tools, which is perfect considering the nature of this project. I imagine my next post will be pretty Maxscipt heavy, but I do plan on doing a little side piece that delves into controllers and transforms in Max. I find that Max handles transforms and hierarchical relationships a little differently than Maya, and I would like to talk about some of my findings with the goal of making these concepts a little easier to understand.

The biggest problem I am facing in finding a suitable solution to my mocap transfer problem is dealing with a custom foot rig. I like to rely on a reverse foot or an attribute driven foot because they make life much easier for the animator. Both types of feet are causing issues when trying to use any of the above solutions, but I am optimistic that an answer is just on the horizon. Aside from the foot problem, I am having a lot of success, and I look forward to getting this system worked out so I can dive into some serious scripting.
As always, please feel free to share your thoughts and experience on any of the topics I am discussing here.

Back to the Production Blog

The next goal of this project is to design a rig that can easily accept motion capture data.  The rig should be able to be animated in tandem with the motion capture data.  Motion capture data will be set to an animation layer, while any hand keyed animation can be created on a second layer.  This makes it possible for the user to blend between systems, or to turn one source of completely if needed.  To achieve these goals, I designed a system of layered controllers.  I recently found a video on The Area that discusses a method for doing something very similar to what I am trying to achieve.  I won’t be explaining my entire rig structure in this post, so go ahead and check out the video on The Area if you want to get an idea of how my Hero rig is structured.  I will be providing an in-depth look at my rig once I settle on a final design.

So this week I got the rig working fairly well.  I still see some hiccups where my hierarchy’s are not setup perfectly, but for the most part, the mo-cap animation is transitioning smoothly to my custom setup with little more than an FBX import.   I can still use my custom animation controls to make changes to the animation I am getting out of Motion Builder, and the whole process looks to be easily automated.  I would call this a win.  This video will show the custom rig being driven by the motion capture animation.  Keep in mind that the custom rig has no baked animation on it.  All of the attributes are still pristine and ready for some hand animated goodness.  In my next post I will show how these multiple systems can be brought together to create a polished animation.  I will also be working on finding a better video compression for my Vimeo uploads.  The videos are coming out choppy.

Back to the Production Blog

• Animator Friendly.
• Works with animation layers.
• Can allow for animating in parallel to motion capture data.
• Can be procedurally generated.
• A modular system.  This means individual limbs or modules can be hooked together to adapt to any character type.

Before I set out to fully design the rig, I thought it would be a good idea to get a feel for Motion Builder and it’s requirements.  For this test I used a biped skeleton, with some very rough skin weighting.  I got the motion capture data from CMU’s free motion capture library.  Here is the result.

Next I wanted to test how easy it would be to get the motion capture back into Max.  That process is actually very easy, but remember that I need to get the data on to my rig in such a way that I can still animate my control objects in tandem with the mo-cap data.  I have seen a couple ways of achieving this.  One way is to use CAT or Biped as your rig.  That idea was not appealing at all.  I have also seen people bake the motion capture data on to the skeleton via a character definition which defines which bones attach to which controls.  This is probably a simpler method, but I would still end up with baked key frames and no easy way to control the amount of influence the motion capture and hand keyed animation would have over my final game skeleton.  So like most things, I decided to try doing this the hard way.  I started with a single leg that has something similar to a reverse foot rig as it’s animation controls.  I then layered in new nodes that would act as a buffer between my imported mo-cap and the animation controls.  The end result is promising, but a still have more tests to run, and of course I will need to make this work for the whole body.

As I was creating this setup, I tried to be vigilant about scripting the steps in Maxscript.  This will make it much easier for me later on when I write the final rigging tools.  I would like to thank Randall Hess for lending some guidance while I am transitioning to Maxscript. Randall wrote this excellent post that shows how to generate bones from a biped.  That post gave me the boost I need to confidently begin writing a Max auto rigger.

In my next post, I will reveal the results of my attempt to apply this mo-cap transfer method to an entire custom Max rig.  I will also be talking about some of the rigging choices I made.  Finally, I will reveal a bit more behind the scenes info on how I am constructing the rig.  For now I leave you with this image that shows a sample of the hierarchical structure I used to design the foot.

Back to the Production Blog

[Show as slideshow]

[View with PicLens]

Back to the production blog

• The Mammoth
• The Hero
• Hero Armor
• Hero Weapons

To create my assets, I started off my modeling my assets in 3DS Max while paying careful attention to drawing edge loops that would best define my forms while facilitating good deformations. Here are some screen shots of my initial attempts at modeling the Mammoth and my Hero character.

It is worth noting that as I went through the process of creating these assets, I often polled the CG community to get feed back on form and topology.  My advice to any aspiring artists, is to not be afraid of showing your work often, and to anyone willing to take a look.  Personally, my best critics are my wife and daughter.  They have no fear of telling me that my art looks weird.
 

[Show as slideshow]

[View with PicLens]

Next up on the production schedule will be modeling the characters, so stay tuned.

Back to the Production Blog