Jump to content
Hash, Inc. Forums
itsjustme

Squetch Rig downloads

Recommended Posts

I would worry about people knowing it was there and, as you rotate the EyeAimer it might rotate on its' 'Z' some...which would cause unwanted revealing and hiding of the main eye target.

 

Yeah, good point.

I see now all the bones that are created when you switch on the FACE interface are interface bones. They even appear if you do it with the FACE slider directly. One of the best things about working with the rig in TWO was there was so little scrolling required in the PWS to access all the bones used. These bones alone possibly double the amount of bones you'd normally see. Why didn't these bones appear in the rig used in the TWO characters?

 

If they can't be made "not to key", then I would favor putting a Z at the front of their name so they're all down the bottom and there's no reason to scroll past them.

 

Ideally, I'd love if bone icons in the PWS could be assigned a color so we can easily pick out/identify commonality. But you can only do what AM allows you to.

 

Edit: I also notice that the FACE slider bone controls the FACE slider in the pose window, but it doesn't work the other way around. That could lead to confusing situations if someone takes over someone elses animation. Though laying down a guide to only use one method could solve that.

Share this post


Link to post
Share on other sites
I see now all the bones that are created when you switch on the FACE interface are interface bones. They even appear if you do it with the FACE slider directly. One of the best things about working with the rig in TWO was there was so little scrolling required in the PWS to access all the bones used. These bones alone possibly double the amount of bones you'd normally see. Why didn't these bones appear in the rig used in the TWO characters?

 

Those bones didn't appear because the hiding of the FACE interface used to be done using Smartskin...which meant it needed to be edited by the animator when installing the rig, this way, that editing is eliminated.

 

If they can't be made "not to key", then I would favor putting a Z at the front of their name so they're all down the bottom and there's no reason to scroll past them.

 

That can be easily done.

 

Edit: I also notice that the FACE slider bone controls the FACE slider in the pose window, but it doesn't work the other way around. That could lead to confusing situations if someone takes over someone elses animation. Though laying down a guide to only use one method could solve that.

 

You run into circular constraining problems when you try to have things controlling each other...we used the FK/IK switch method (baking) extensively throughout these updates to get around problems like that. It might be possible to do, but I don't think it's a "deal breaker" that it only works one way. If there is a "standard" method of dealing with it worked out for the production, then it shouldn't be a problem, Ken.

Share this post


Link to post
Share on other sites

Also, I agree with Nancy that the Switch_setup pose should be OFF by default. It's handy enough to turn on now and turning it ON generates fewer bone keys than turning it OFF. It also cleans up the bones when starting up which is a big inspiration plus when you're facing a blank canvas.

Share this post


Link to post
Share on other sites

We could just remove the switches all together, if it's going to be that much of a problem.

Share this post


Link to post
Share on other sites
If they can't be made "not to key", then I would favor putting a Z at the front of their name so they're all down the bottom and there's no reason to scroll past them.

 

That can be easily done.

 

I vote for that as well (assuming you're talking about the current bones prefixed with interface - could be z_interface_).

 

I notice that the ARM scale to reach switches are limited to rotation only about the z axis, whereas the LEG scale to reach are able to rotate on all axis. Should they be limited to only the z as well? It does not appear that rotating about the other axis'es do anything useful. Except maybe screw something up as I seemed to get the left leg in a funny state that didn't clear up by zeroing values when I didn't realize that it was the z axis rotation that was required.

 

Also might be nice if the Face Interface folder was moved to the topish of animation folder under the switch setup on/off (before hand gizmo?). But not a big deal.

Share this post


Link to post
Share on other sites

Nancy, have you downloaded the new update that David posted on the previous page? The scale to reach leg switches only rotate in the Z axis in v13 and v14. What version of AM are you testing in? David and I do not have v15.

 

I think I know what you're talking about. The rotate manipulator shows all 3 axis, but it only rotates in the Z axis, right?

Share this post


Link to post
Share on other sites
Nancy, have you downloaded the new update that David posted on the previous page? The scale to reach leg switches only rotate in the Z axis in v13 and v14. What version of AM are you testing in? David and I do not have v15.

yes I did download new version - testing in 15b

legswitch.jpg

Share this post


Link to post
Share on other sites

As I said, it only rotates in the z axis, but the x and y axis show when you turn the manipulator on. The switch has and euler limit constraint.

 

FIXED. Would you prefer the manipulator on all the time on the rotation switches?

 

Anything else?

Share this post


Link to post
Share on other sites
As I said, it only rotates in the z axis, but the x and y axis show when you turn the manipulator on. The switch has and euler limit constraint.

 

FIXED. Would you prefer the manipulator on all the time on the rotation switches?

 

Anything else?

 

Manipulator on all the time? - if you mean when you select it - that would be nice - (note the arm manipulator just shows the z rotation)

 

I also notice that the scale to reach gets in a funny state (both for arm and legs) - where it stops responding - for example in the image it shows rotation is set to 0 - yet it is still scaling to reach - even when I manually put in values for z rotation

switchesstopworking.jpg

Share this post


Link to post
Share on other sites
Ideally, I'd love if bone icons in the PWS could be assigned a color so we can easily pick out/identify commonality. But you can only do what AM allows you to.

 

I actually did something similar to this with the rig for Flemm. I changed the color of all the geometry bones to be a red color, all the cosmetic bones are a light blue and all of the control bones are green.

 

Not an ideal situation, but it made sense to me and I was able to visually tell what type of bone I was looking at just by the color.

Share this post


Link to post
Share on other sites

Mark, I believe Ken was referring to the bones in the PWS under the action or chor, not under the models bones folder. David does a similar thing in the squetch rig, but someone requested to change that, due to not being able to see what bone is assigned to which cps.

Share this post


Link to post
Share on other sites

Nancy, is it still scaling when moving the IK foot controller? Or does it just maintain the scale?

Share this post


Link to post
Share on other sites

This is with the new download. If you have fix any of these then ignore it. Since the post are flying in fast and I hate retyping every time I look.

 

needs z turned OFF

right_toes_IK_manual_pointer

left_toes_IK_manual_pointer

right_heel_control

left_heel_control

right_toes_controller

left_toes_controller

 

The eyelid bones have z rotations also ON do they need to be ON?

eyelid_left_inner_corner_control

 

 

z_switch_chest_IO

z_switch_stomach_IO

Is there a control to move the chest and stomach up and down or side to side?

 

I did not see an Eyes Dilate control on the face menu?

 

 

I think this is as far as I can go with my limited knowledge of rigging. :)

 

Also something to suppress the unnecessary data channels like a option to not record thing not needed for animation but needed for setup.

 

I'm not sure exactly what you mean by this, but I'm nearly sure it can be done. I'll let you know if you explain it more fully. :D

 

An example would be the face controller for the menu. When you switch it on AM adds a data channel to your action file. This is not needed to animated. And just add unnecessary bytes to your file. Now add up all of the switch and you will see the problem. But having the option to not record will save on file space and CPU speed, during animation.

Share this post


Link to post
Share on other sites
z_switch_chest_IO

z_switch_stomach_IO

Is there a control to move the chest and stomach up and down or side to side?

Use the arrow keys to translate them. This works for all the bone switches that rotate on the Z axis. This doesn't work for the null switches, except for the direction it can translate. So you can use the arrow keys to turn the null switches on/off.

Share this post


Link to post
Share on other sites

Unless I am missing something the arrow keys are only moving the bone and not the chest/stomach?

Share this post


Link to post
Share on other sites

Sorry, I thought you were referring to the switches themselves, to reposition them.

 

Show_and_Hide_Rig_Components>show_geom_bones. Turn this pose ON and you'll be able to translate and rotate the chest_IO_geom and the stomach_IO_geom bones.

Share this post


Link to post
Share on other sites

O.K. I found it. :)

 

Will you have an add-on for the chest for females by chance.

Share this post


Link to post
Share on other sites
Nancy, is it still scaling when moving the IK foot controller? Or does it just maintain the scale?

 

I believe it is maintaining the scale even tho the scale rotate value = 0,0,0

 

It does not seem to reset back to zero - it works the same in 14c and 15b

 

I do notice if I move the left ik foot control back close to normal position, them type in 0,0,100 for the scale switch rotate value, the leg resets, then I type in 0,0,0 for the scale and it seems back to normal.

 

try it.

 

move the ik foot control far out - keep ratcheting the scale switch back and forth in the window, note how it never resets back to normal.

Share this post


Link to post
Share on other sites
move the ik foot control far out - keep ratcheting the scale switch back and forth in the window, note how it never resets back to normal.

 

What that sounds like is the "baking" causing that. When something is turned on and off repeatedly, that is what happens. We had the same thing happen with the "Blink" Pose. For the "Blink", we have it where it never really goes to "0"...it goes to ".01". We can't do that with the scale-to-reach Poses though, they have to be turned off in FK. So, that's something that the animator will just have to be aware of, Nancy.

 

Will you have an add-on for the chest for females by chance.

 

All that would need to be added for that would be two geometry bones as children of the "chest_IO_geom", then dynamic constraints on those bones would give you the movement necessary.

 

Also might be nice if the Face Interface folder was moved to the topish of animation folder under the switch setup on/off (before hand gizmo?). But not a big deal.

 

The "Face_underlying_controls" folder has to be over the "FACE Interface" folder, the order of the folders will affect the constraints of some things, Nancy.

Share this post


Link to post
Share on other sites

Here's the next test version. Changes in this version:

 

1. The X and Y manipulator option is turned off on the leg scale to reach controls.

 

2. Put "spine" in front of the hip controllers names so that they are grouped with the other spine controls in the Timeline.

 

3. Put "z" in front of the names of the FACE interface moving bones so that they will not have to be scrolled through in the Timeline.

 

Any other problems? Or new ones created?

 

 

In case anyone needs to refer to the videos or the detailed explanation, they are still located here.

 

 

---------------------------------

EDIT

---------------------------------

 

The next update is here.

Share this post


Link to post
Share on other sites
An example would be the face controller for the menu. When you switch it on AM adds a data channel to your action file. This is not needed to animated. And just add unnecessary bytes to your file. Now add up all of the switch and you will see the problem. But having the option to not record will save on file space and CPU speed, during animation.

 

Ah gotya. You can do this with animation.....by switching off the A icon at the top. With that off, you can make changes to a bone rotation and it won't be keyed. But you can't assign this to bones so they'll always behave this way. But the bones will always create a key at frame 0 (because they're moving) and so be in the timeline.

Share this post


Link to post
Share on other sites
An example would be the face controller for the menu. When you switch it on AM adds a data channel to your action file. This is not needed to animated. And just add unnecessary bytes to your file. Now add up all of the switch and you will see the problem. But having the option to not record will save on file space and CPU speed, during animation.

 

Ah gotya. You can do this with animation.....by switching off the A icon at the top. With that off, you can make changes to a bone rotation and it won't be keyed. But you can't assign this to bones so they'll always behave this way. But the bones will always create a key at frame 0 (because they're moving) and so be in the timeline.

 

You could always just delete the references to those bones and Poses in the Action before saving...of course, you would have to delete the right ones. For the FACE controls, now you would just have to delete the "z_interface" bones and the "FACE off/Joint Controls/Split Controls" Pose references.

 

needs z turned OFF

right_toes_IK_manual_pointer

left_toes_IK_manual_pointer

right_heel_control

left_heel_control

right_toes_controller

left_toes_controller

 

 

I missed this, DJ...I'll fix them in the next version.

 

The eyelid bones have z rotations also ON do they need to be ON?

eyelid_left_inner_corner_control

 

I'll add those to the list.

 

I did not see an Eyes Dilate control on the face menu?

 

"Animation_Controls/FACE Interface/BothEyesDilate" or individually in the "Animation_Controls/FACE Interface/IndividualEyesDilate" folder...they are just above the "Blink" Pose.

Share this post


Link to post
Share on other sites

Since I think I can beat anyone downloading the version I posted...here's a quick update.

 

The changes include the ones in this post and euler limits on the 'Z' rotation of the "right_toes_IK_manual_pointer", "left_toes_IK_manual_pointer", "right_heel_control", "left_heel_control", "right_toes_controller", "left_toes_controller" and the eyelid control bones.

 

Any issues remaining? Any created from the changes?

 

 

In case anyone needs to refer to the videos or the detailed explanation, they are still located here.

 

 

 

----------------------------------

EDIT

----------------------------------

 

This file was deleted, the next version is located here.

Share this post


Link to post
Share on other sites
move the ik foot control far out - keep ratcheting the scale switch back and forth in the window, note how it never resets back to normal.

 

What that sounds like is the "baking" causing that. When something is turned on and off repeatedly, that is what happens. We had the same thing happen with the "Blink" Pose. For the "Blink", we have it where it never really goes to "0"...it goes to ".01". We can't do that with the scale-to-reach Poses though, they have to be turned off in FK. So, that's something that the animator will just have to be aware of, Nancy.

 

 

It is not the repeated turning on/off that is a problem - it appears there isn't a way to turn the leg squetch off totally once it's been turned on. The leg or arm maintains the extended length

 

with A:M ver 15b, SAM ver b. Here's how it happens for me: in an action

 

move ik foot to beyond normal - an exaggerated amount

turn scale to reach rotate to 0,0,100 - leg squetches like expected and reaches ik foot

move ik foot

turn scale to reach rotate to 0,0,0

leg does not unsquetch

move ik foot

leg is still the extended length but doesn't scale to reach the ik foot

 

(arms work same way)

 

How do you turn it off and get the leg back to normal size and behavior ?

Share this post


Link to post
Share on other sites
It is not the repeated turning on/off that is a problem - it appears there isn't a way to turn the leg squetch off totally once it's been turned on. The leg or arm maintains the extended length

 

with A:M ver 15b, SAM ver b. Here's how it happens for me: in an action

 

move ik foot to beyond normal - an exaggerated amount

turn scale to reach rotate to 0,0,100 - leg squetches like expected and reaches ik foot

move ik foot

turn scale to reach rotate to 0,0,0

leg does not unsquetch

move ik foot

leg is still the extended length but doesn't scale to reach the ik foot

 

(arms work same way)

 

How do you turn it off and get the leg back to normal size and behavior ?

 

 

Reading your steps, I think you left out turning the scale-to-reach back on. First, you turned it on, then scaled the leg, then turned it off and then expected the leg to squetch...if you turned it back on, the leg would squetch. Once you squetch the leg back to where it bends, turn the scale-to-reach off and it will act as it normally would.

 

Did that fix the problem, Nancy?

Share this post


Link to post
Share on other sites
Reading your steps, I think you left out turning the scale-to-reach back on. First, you turned it on, then scaled the leg, then turned it off and then expected the leg to squetch...

 

No. I expected it to UN squetch (unstretch) when I set the scale back to =0,0,0 (original value). I expected the leg to go back to its original unextended length.

 

I will try to say it hopefully in other ways:

 

It squetches (stretches) fine to the IK control when you turn it on (scale=0,0,100). If you move the IK controller, and then turn the scale back to 0 - it does not UNSQUETCH (un stretch) back to original length (does not behave as it does in initial state). It stays at the extended length but doesn't extend further if the IK controller is moved further away.

 

The problem is getting it back to it's original state ie unextended length (when first start the action) and having the scale switch off, after having moved the IK control, and stretched the leg.

 

Please try it for yourself. Following my steps in the previous post.

 

Let me know how you intended it to work. It is not obvious.

Share this post


Link to post
Share on other sites

When you use the scale to reach switch, you need to bring the IK controller back within reach before turning the switch off.

 

If you scale to reach and then type in 0 in the Z rotation axis to maintain the scale, you then need to move the IK controller within reach of normal scale, set the Z rotation to 100 either by typing it in or using the switch. After doing that, you need to type in 0 again in the Z rotation of the switch to maintain the normal scale.

Share this post


Link to post
Share on other sites
Please try it for yourself. Following my steps in the previous post.

 

Let me know how you intended it to work. It is not obvious.

 

I followed your steps, Nancy. The confusion may be that "squetch" means both squash and stretch...I should have used the separate terms in my explanation. Mark explained it better, I think.

Share this post


Link to post
Share on other sites
When you use the scale to reach switch, you need to bring the IK controller back within reach before turning the switch off.

 

If you scale to reach and then type in 0 in the Z rotation axis to maintain the scale, you then need to move the IK controller within reach of normal scale, set the Z rotation to 100 either by typing it in or using the switch. After doing that, you need to type in 0 again in the Z rotation of the switch to maintain the normal scale.

 

I had an icky feeling you were going to say that.

 

I thought 0 meant don't scale to reach IK control (original state) and 100 on the dial meant scale to reach the IK control 100%. I thought it was a continuous dial. And setting it back to 0 means go back to original state.

 

Seems to me you have multiple states being defined by the dial instead of the one: % scale to reach. The 0 setting on the dial has 2 meanings- current scale to reach is off (0%) and maintain current scale at whatever it is. The meaning of 0 setting depends on what order things get moved, changed. To have to toggle the zero position seems a bit strange to get back to original state.

 

I won't noodle this any more. I done.

 

I recognize it's not always a perfect world.

Share this post


Link to post
Share on other sites

Dave how did you turn off the z on the right_heel_control and others. Since the handle is still present?

Share this post


Link to post
Share on other sites

The switch controls the pose slider, that's all. Having it set at 100% and then typing 0%, is like an on/off switch, instead of a percentage slider. Setting it to 0% creates a scale offset, just like turning the FK/IK switches on and off to allow the bones to hold their position. The auto keyframe, that was introduced to allow FK/IK switching, is the cause of this problem. It doesn't just keyframe the translation and rotation, it keyframes the scale as well when a constraint is turned off.

Share this post


Link to post
Share on other sites
Dave how did you turn off the z on the right_heel_control and others. Since the handle is still present?

He used an euler limit constraint.

Share this post


Link to post
Share on other sites

O.K. That may explain a few things.

 

On the face

The eyelid bones also have the translate ON you may want to turn that off.

"eyelid_upper_right_outer_control"

Share this post


Link to post
Share on other sites
O.K. That may explain a few things.

 

On the face

The eyelid bones also have the translate ON you may want to turn that off.

"eyelid_upper_right_outer_control"

 

I'll fix it in the next update...I'll post it late tonight. Thanks, DJ.

Share this post


Link to post
Share on other sites

Here is the next update. In this one, the eyelid controls have translate limits on them.

 

Any other issues? Any new ones created?

 

 

 

 

In case anyone needs to refer to the videos or the detailed explanation, they are still located here.

 

 

 

About the second file:

-------------------------------------------------------------------------------------------------------------------------------------

 

The second file is a Project that has this update of Squetchy Sam along with the test Action for setting up a BVH file that has been exported from Zign Track v1.2. Luuk changed how things work a little, so I had to change the Expressions in the Action. If anyone that has Zign Track v1.2 could double check the setup Action, I would appreciate it.

 

To check the setup Action, export a BVH from Zign Track v1.2, open the Project file in this post, open the "v12_BVH_Setup_02_29_2008" Action (it should already be open), expand out the Action until you find the "Action Objects" folder, select the "BioVision BVH File1 Action Object", right mouse click, select "Capture Sequence" and browse to the BVH file you exported from Zign Track. Once all that is done, you should be able to compare the source video with the movement in the Action. To increase or reduce the movement provided by the data, use the sliders in the "Animation_Controls/Face_underlying_controls/face_setup/Zign_Track" folder..."1000" is equal to 100%, so you can reduce the movement to 0% or increase it to 500% using those controls.

---------------------------------------------------------------------------------------------------------------------------------------

 

 

 

About the third file:

---------------------------------------------------------------------------------------------------------------------------------------

I did a lot of experiments using the Pose output from Zign Track, but it slowed the FACE controls down whether you were using MoCap data or not. So, I decided to keep it as just BVH support. I've done some experiments that will convert the BVH data to an Action, but there are a few issues that still need to be overcome. What I have done is use the KFM export to convert the results of the BVH data and tweaking by exporting as a KFM, importing the KFM into a new Action, deleting all of the references to the "BVH" nulls in the Action and leaving the "Maxilla_base_BVH" and "LowerTeeth_base_BVH". The problem I've encountered is that the KFM format appears to handle bone rotations differently...the translate data seems right though. If you delete the bones that rotate ("Maxilla_base_BVH", "LowerTeeth_base_BVH" and "head_control"), in addition to the nulls with "BVH" in their name, it appears correct for what is left.

 

The third file, "TEST_v12_Zign_Track_transfer_02_29_2008.mdl", has just the bones, nulls and constraints necessary to export the Action with the BVH data out as a KFM file. When you export to KFM, every bone and null in the model will be keyed on every frame, so this model will reduce the number to only what is needed. To use it, save the Action that has the BVH data in it, close the Project, open the "TEST_v12_Zign_Track_transfer_02_29_2008.mdl" model, import the saved Action, open the Action, export as a KFM file by right mouse clicking and selecting "Plugins/Export/KFM". Then open Squetchy Sam, open a new Action, import the KFM by right mouse clicking, selecting "Plugins/Import/KFM" and browsing to the KFM file you saved. Then, you will see that the rotation data is incorrect...delete all of the bones/nulls with "BVH in their name and the "head_control" bone and the FACE nulls that translate correctly will be left. I'm doing experiments to adjust for the incorrect rotations, but I haven't solved it yet.

 

 

--------------------------------

EDIT

--------------------------------

 

I got the KFM export/import to work a little more, but with a lot more jumping through hoops. I had to split the Action into two, replace the Expressions for the "Maxilla_base_BVH", "LowerTeeth_base_BVH" and "head_control" using Squetchy Sam as the model and exporting a KFM for those. Then, I had to use the "TEST_v12_Zign_Track_transfer_02_29_2008.mdl" to export a KFM with just the FACE nulls data and combine the data from the two to get it to work. I'll add the fourth thing I used to this post in case anyone wants to mess with it. The fourth thing is an Action that has the Expressions for the "Maxilla_base_BVH", "LowerTeeth_base_BVH" that I changed in the original Action (TEST_KFM_Expressions_exchange_02_29_2008.act). Yeah, I know, way too much work at this point. I'm going to let this experiment rest for a while until I have more time.

---------------------------------------------------------------------------------------------------------------------------------------

 

 

 

The next test version of Squetchy Sam is here.

TEST_Zign_Track_1_2_with_Squetch_Rig_02_29_2008.zip

TEST_v12_Zign_Track_transfer_02_29_2008.zip

TEST_KFM_Expressions_exchange_02_29_2008.zip

Share this post


Link to post
Share on other sites

Some more things I have found. :)

Jaw_geom

LowerTeeth_geom

needs translate off

 

body_SQUETCH_control

body_SQUETCH_scaler

translate off

 

body_SQUETCH_base

rotate off

translate off

 

right_finger_thumb_2_target an all other fingers

rotate off

 

tongue_SQUETCH_target_1

translate off

rotate off

 

tongue_SQUETCH_target_2-4

rotate off

 

head_back_target_SQUETCH

head_front_target_SQUETCH

head_side_target_SQUETCH

rotate off

 

 

I don't know what they should do and nothing seems to happen when I move the slider. Can you elaborate on what and how to use them.

 

body_SQUETCH

body_SQUETCH_pivot

neck_SQUETCH

Left_Finger_End_Joints_Bend_N_Y

Share this post


Link to post
Share on other sites
I don't know what they should do and nothing seems to happen when I move the slider. Can you elaborate on what and how to use them.

 

body_SQUETCH

body_SQUETCH_pivot

neck_SQUETCH

Left_Finger_End_Joints_Bend_N_Y

If you unhide the body_SQUETCH_controls and use the null to squetch the body, you can change the pivot point of the squetch. The body_SQUETCH pose is automated and should be a hidden pose.

 

Setting the neck_squetch pose percentage will squetch the neck when you translate the head_manual_control.

 

The Left/Right_End_Joints_Bend_N_Y sets a percentage the end finger bones rotate while using the hand gizmo.

 

I'm unsure why you would want to turn the translation off on the jaw_geom and tongue_SQUETCH_target_1.

Share this post


Link to post
Share on other sites

Thanks

 

In my list I put body_SQUETCH_base. I don't know If you need to have the

translate and rotate off or on. I will leave that one up to you.

 

For the non-tweak bones, menu bones(not the switch) and some others. Should there manipulators be disabled. So the end user dose not make the mistake of moving these in the action windows. I leave this up to you since there is a lot of them.

Share this post


Link to post
Share on other sites
Some more things I have found. :)

Jaw_geom

LowerTeeth_geom

needs translate off

 

body_SQUETCH_control

body_SQUETCH_scaler

translate off

 

body_SQUETCH_base

rotate off

translate off

 

right_finger_thumb_2_target an all other fingers

rotate off

 

tongue_SQUETCH_target_1

translate off

rotate off

 

tongue_SQUETCH_target_2-4

rotate off

 

head_back_target_SQUETCH

head_front_target_SQUETCH

head_side_target_SQUETCH

rotate off

 

 

I don't know what they should do and nothing seems to happen when I move the slider. Can you elaborate on what and how to use them.

 

body_SQUETCH

body_SQUETCH_pivot

neck_SQUETCH

Left_Finger_End_Joints_Bend_N_Y

 

 

I'll have to go over this late tonight, DJ...I know a few of them don't need the limits on them, but I'll have to go over it to give you a list.

Share this post


Link to post
Share on other sites

I have found some CP’s not assigned correctly. When I stretch the face forward I saw two CP’s not working correctly.

head1.jpg

Share this post


Link to post
Share on other sites
I have found some CP’s not assigned correctly. When I stretch the face forward I saw two CP’s not working correctly.

head1.jpg

 

I'll add that to my to-do list for this evening. Thanks, DJ.

Share this post


Link to post
Share on other sites
Some more things I have found. :)

Jaw_geom

LowerTeeth_geom

needs translate off

 

body_SQUETCH_scaler

translate off

 

right_finger_thumb_2_target an all other fingers

rotate off

 

tongue_SQUETCH_target_2-4

rotate off

 

head_back_target_SQUETCH

head_front_target_SQUETCH

head_side_target_SQUETCH

rotate off

 

These I took care of.

 

body_SQUETCH_control

translate off

 

Limited that one to one axis of movement...it needs that one.

 

 

body_SQUETCH_base

rotate off

translate off

 

That one needs to be able to move.

 

 

 

tongue_SQUETCH_target_1

translate off

rotate off

 

That one needs to translate, but I limited the rotation.

 

The "jaw_geom" used to translate with the jaw in/out, but now that is handled by the "Jaw_base", so I don't think it will hurt anything to have it tied down. These limits are kind of overkill in my mind, but I don't think they will hurt anything...we can always take them out if something gets in the way.

 

I also fixed the CP Weighting on the head.

 

Here's the updated Squetchy Sam.

 

 

Any other issues? Any new ones created?

 

 

 

 

In case anyone needs to refer to the videos or the detailed explanation, they are still located here.

 

 

----------------------------------

EDIT

----------------------------------

 

The next test version is located here.

Share this post


Link to post
Share on other sites

Woah! Did those limiting changes just add 300kb to the model? It seems so. If they did, I'd also agree they're overkill especially if the animator doesn't interact with the bones regularly/at all.

Share this post


Link to post
Share on other sites
Woah! Did those limiting changes just add 300kb to the model? It seems so. If they did, I'd also agree they're overkill especially if the animator doesn't interact with the bones regularly/at all.

 

 

Good point.

 

I am going to dig through the file in note pad and see how much mem it takes to do each. It may not be overkill if it lessens the end user from changing something should by mistake. You need to weigh the pro’s against the con’s

Share this post


Link to post
Share on other sites

David/Mark, is the rig mature enough now to start putting into the SO characters? If so, how do we get a blank version......just delete the Sam mesh? Also, is the installation similar to before?

Share this post


Link to post
Share on other sites
David/Mark, is the rig mature enough now to start putting into the SO characters? If so, how do we get a blank version......just delete the Sam mesh? Also, is the installation similar to before?

 

We're in the middle of putting the installation rigs together, Ken. It shouldn't be more than a couple of days.

Share this post


Link to post
Share on other sites

1) I noticed with your new rig that (in a new action) - if I set switch setup = off that some right arm bones show up (along with z_switches) - but for the right arm only - either none should be set ? or left arm bones should be set as well? (see image)

 

2) I notice if I create my own version of Sam such that the default switch setup=off and Steves hand controls are on - that in a new action the Steves hand controls get initialized as OFF (ignoring my default)

 

3) I notice that even tho the default switch for Spine fk_iK_iksquecth blah blah etc = 1 (under torso) , it is initialized set to 0 in a new action

unsymmetricalOFF.jpg

Share this post


Link to post
Share on other sites

Fixed #1

 

#2 and #3 are due to the fact that the switches are still active, just hidden when the switches are turned off. You still can modify the poses in an action or chor, but resetting them in the user properties doesn't work, the switch will reset it at the start of a new action. I tried turning the smartskin off when you turn the switches off, but I got funny results doing that. I'll look into it again, maybe I missed something.

 

Also, once you modify the settings is the user properties, the switches will no longer work correctly, it's keyed from the default settings that we have set.

 

So with that said, do you want the switches removed? Since they seem to be more trouble than they're worth for you and others.

 

I think we just get rid of them just for you and the heck with everyone else. ;)

Share this post


Link to post
Share on other sites

O.K. I did some looking into the mdl file. Between the Limit Manipulators or the Euler Limits, Translate Limits and Spherical Limits it depended on what you used it for to determined which one used more file space. For future reference you may want to stick with Limit Manipulators for constancy on the bones that dose not need to be move by the end user.

 

Now back to testing.

 

The hands, arms and legs have a bunch of geom and bow geom bones that have there Manipulators set at random. I don’t know which one should be set which way.

 

Also look at the Neck geom

 

Can someone tell me how to set the hidden relationship since it seems to be hiding from me. :blink:

Share this post


Link to post
Share on other sites

Limit manipulators are only good for keeping the user from using them. Most of the bones that have constraints set to them, need it, either limiting the amount of movement or constricting them all together for other reasons.

 

Why am I looking at the neck, what's the problem.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...