Since the last chapter, I made some tweaks to things. Use this file for a starting point. Your Object Manager should look like this:
Here's the list of changes: 1. Added a Rig null to the root component(will get into why I did this later in this post). 2. Added a parent to the hips_con+ called hips_algn(will get into why later in this post). 3. Added spine_rig_elements null and put the spine_spl and spine_01_bnd under it(will touch on this in the post). 4. Cleaned up the neck's orientation values to follow the rest of the spine. 5. Froze all necessary things that needed to be frozen.6. Added some adjustment rules to the root component that might not be necessary, but just to be safe I added them. We will get more into adjustments and rules in a later post. Sorry about that. This particular component is an evolution. In addition to teaching you about the settings of the Component tag, I am trying to make a completely functional template that maybe I will do more with down the road. So as I go through things, ideas come up, and changes get made. I will try to always keep anyone following along updated.
Now, if you open the file, remember we had created two groups for our components. You might recall that we added the component tag to the Root_component null object. That made sense for that case because it was the first component of our template. That means everything needed for it and future components could be contained inside of a single group. But like I said then, I can't guarantee that going forward. So normally, those groups are just meant for organization.
Not everything here will have the same parent object.
When you look at the list of objects, most should follow the layout_con+ controller, but the hips_bnd should be in our bind joints group. In fact, looking at this component, one thing that stands out to me is there there are 3 sort of cases here. We have 1. controllers and controller targets(ie something that determines where a controller should be. 2. Bind joints. 3. Rig elements. Rig elements might not make a ton of sense, but consider we have a spline object for a splineIK, and we have a group of nulls that has the spline IK on it. These are not controllers, and they are not bind joints, but they might influence one or both of those things. (THIS IS WHY I ADDED THE RIG GROUP. TO HOUSE THESE RIG ELEMENTS).
The important bit is that they don't belong with the bind joints which we want to be a simple hierarchy of the joints that bind our character so we can potentially export or bake down to the joints for speed. It's not required to be a single hierarchy or anything, this is personal taste/preference. But I like it because it gives you a centralized place that if you bake the animation to those joints, you could have a light version that is just joints and create motion clips and blah blah blah.
So now we have a place we can dump all the various rigging elements outside of our controller hierarchy. None of this is a requirement to make these things work. This is just things I'm trying out as I build more and more components, trying to keep things tidy as I work etc. Trying to know where to look for certain things.Alright, jeez, let's get cracking for real.
Any one of those children of the Spine_component object could be the home for our main component tag. I'd maybe not do any controller so they can be tagged as a controller later. So picking at random, I'm just going to do it to the bind joints. Right click on hips_bnd and add a Component Tag. In the Tag Tab, set the type to be Spine(again this part doesn't matter so long as you choose the right genre of type). Set the Name to be "Spine". For the main controller, I'm going to choose hips_con+ Selecting this controller and moving would basically move the whole component, so it can be the main. Then be sure to add the head_con+ to the user data list, as it is the only thing with user data.
This is how the Tag tab should look
Jump to the Insertion tab. Add an Insertion rule like we showed in the last one. The gist of this rule, is we want to only be able to make a spine if the root is selected. So with our rule selected, set the Parent Attribute to be "Only". This means that our Spine component can only be built when the component in the component field is selected. The object that you put in the component field needs to be the object with the component tag. That is to say, the component tag, set to one of the buildable component types. If it is not, it won't work. So add the Root_component object into the component field.
For the Insert attribute, change it to be "First Child". This means that it will be inserted as the first child of the object in the Object Field. Because we put the Component Tag on the bind joints for the spine, we want these to be inserted under the 'Bind' group we made. So put the Bind null into the Object slot. Lastly, set the Allow attribute from Multiple to Single.
How your Insertion tab should look.
Lastly(for now at least), jump to the Include tab. We need to add all the stuff we want to include here. Remember that the Component Tag Buildable type will automatically add all the children of the object with the tag. But we have other objects so we need to make sure they are included as well. Pretty much everything underneath the Spine_component object needs to be in the include field.
How your Include tab should look.
Move the Spine_component object underneath the Character_grp object, and then save you file via the Character menu, and try to build your new spiffy spine component. On paper it might look like you've successfully built and insert it. But you're not quite there yet. Try to select the root or layout_con+ and you'll see nothing is following it. Switch the Character Object's display tab setting to show the full hierarchy in the Object Manager, and you will begin to see the issue.
Everything's brought in, but all the stuff up top is in the wrong place.
Since we only have the tag on the hips_bnd, we only have control over where the bind joints are being inserted. We can successfully include everything, that is to say that everything is brought in, but not placed where they need to go. To do that, we will use some of the Component tag helper types.
Select "head_world_orient_targ", "hips_algn", "head_algn", and "spine_rig_elements" objects from the OM. With all 4 selected, right click and add a Component tag. With them all selected add a Component Tag. Then go into the Tag tab. Set the type to be "Component". This Component mode is a helper type. They will not show up as a button. They are just a piece of a component. When you switch to this type, the number of tabs drops significantly. Really, all that matters for our purposes is the Insertion tab. This helper type let's us specify custom insertion rules/points of insertion that differ from what the Button component types are. So select the "hips_algn", "head_world_orient_targ", and "head_algn" component tags. Go to the Insertion tab and add a rule to them. Set them to be Only, pointing to the root component(like in our main Spine Component tag).
So the way these objects get inserted is from the top down. So in our case first it will insert the "head_world_orient_targ". Then "hips_algn". Then "head_algn" We can re-order things to make them insert differently if we want to. How we want to insert is important here as these will guide rig construction, and potentially could introduce priority issues that you don't see until you build. So you could reorder them, or you could simply use different Insertion rules for this. Keeping the order as it is, we can start with "head_world_orient_targ". Because this will be the first thing inserted under the layout_con+, we can set it to be First Child, and layout_con+ as the object. You can then set the "hips_algn" to be either Last Child and pass in the layout_con+ object, or you can say you want it to be After, and pass in the "head_world_orient_targ". Both would be valid. I set mine to the Last child option. The Last child will make it a child of the object, but it would be last or bottom child. The Before/After options would make the object with the component helper tag type insert as a sibling, either before(ie above in the OM) or after(ie below in the OM).
For "head_algn", you want it to be set to After, and you want it to be the "hips_algn" in the object slot. This is all meant to ensure that the world orient target is higher up in the OM than the head align(as it is needed to constrain the head controller when in world mode), and that the head_algn to be after the hips align which has the other target for the head controller. This is just because of how the rig was set up. In theory you could edit the priorities in such a way that where they were positioned in the OM wouldn't matter. But to me it's easier and clearer to be in control of where things are being placed. Lastly, set the rule for the "spine_rig_elements" to be Only, layout_con+, then First Child, and object set to "Rig". This will place it all under the Rig group out of the way.
So let's quickly talk about why I added a "hips_algn" in the first place. An area we haven't really talked about is the Transform section of the Insertion tab. Generally you don't need to. But that's where it will try to do nice things like freeze transformations reset the PSR after adjusting etc. It's generally very confusing, and you shouldn't worry about it here. But one thing that can happen, is that things that are Posable via position and rotation, and are like a world space controller, cannot get proper frozen coords after an adjustment. Some of this has to do with how the character object does this stuff under the hood. This generally would affect like the hips/torso, or the IK controllers. Because those sorts of objects would be under our layout_con+ and not under other specific things. But having clean position and rotation values are super important. So the way around this is to defer this issue to a higher object where it doesn't matter. By grouping the controller under a null, it gives our controller clean values, and passes off the problem of forever unclean values(hyperbole and a reference to The League) to the null where it won't matter as we won't be animating on it. Hopefully that makes sense. Basically any controller that would be under our layout_con+ directly, should probably be grouped in a null or it may suffer the same consequences.
The very last thing we will do for this now, is to tag all of our controllers. Anything that has _con+ at the end(not just in this component. We should have done this for the root component as well, but I wanted to try to keep that one as simple as possible). That part is easy. Select all the _con+ objects, add a component tag, set the type in the Tag Tab to be "Controller". That's all we gotta do for that. If we needed the controllers to go somewhere specific we could do Insertion rules, but because we've done this to their parents, it's not necessary. Just adding the Controller type is enough. And that will be where we stop for tonight. Here's the file where I left off. It could change between then and now, but I will keep you posted with links.
Comments
Post a Comment