itsjustme

Should you be in a compromising mood, it would be really helpful if the FACE interface switch was left at least. Do you mean the pose slider that turns the interface on and off? I would say that is a lot more than simply helpful. I would say it is really necessary to have that because without a switch to turn it off, the face interface shows up in the final renders. Ken was referring to the on-character switches that would make it where you wouldn't have to open the Pose folders to get to things. We have removed the switches from the installations and Squetchy Sam, but, we could have them as an add-on for anyone that wants them. You will be able pick and choose which ones you want to install on your own. --------------------------- EDIT --------------------------- Just to give everyone a heads up, we're going to try to get a release out sometime on Sunday (which would be the day after tomorrow). If we don't find a problem between now and then, that's when it should happen for the biped rigs.

The "BVH" Poses in the "Animation_Controls/Face_underlying_controls/face_setup/Zign_Track" folder are to set up your character so that the data that moves the FACE controls isn't over or under the amount of movement that works for that character. The "BVH" Poses in the "Animation_Controls/FACE Interface/Preston Phoneme Set" folder is to add the things that the motion capture data can't track. Notice that not every phoneme has a corresponding "BVH" Pose, only ones that have tongue movement or lip curling in them. There is some lip curling built into the FACE controls for "oo" type movements, so, the "WQ" Pose doesn't need a "BVH" additional Pose.

The "BVH" sliders only work when using facial motion capture data from Zign Track/AM Track, DJ. They are for reducing or increasing the amount of movement provided by that data generally, but those are for adding movement that is not provided by the data.

You can turn the switches off in the Properties of the character, Ken...then it would default to "off". Is that too inconvenient? Whoever rigs the characters can set it up that way if it is decided that's the way the SO characters should be set up. Also, the bones that are keyed are going to have a "z" in front of their name, so they will be at the bottom of the timeline out of the way.

That is probably from one of the bone name changes...I'll track it down tonight. Thanks, DJ. The leg flexing sliders adjust the percentage of flex which happens when you bend the leg or point the toe, they don't actually flex the thigh and calf. That's why I asked how would be the most economical way to go about it. I can put a blank Pose that can be edited for each character...there really can't be a "one size fits all" for that. Well, of course, if anyone needs the functionality of the switches (eg IK arm), it would be a "rule" that they turn on the switches and switch it there......not go into the pose window for those things. Even if the switches are ON by default, there's still no guarantee everyone would use them over the pose window......unless there was a rule. Turning them off by default is a preference thing that I think Nancy also agrees with. Some more opinions would be nice. Maybe all the bells and whistles doesn't bother most people? I think that a new user wouldn't know that the switches were there initially, that's why I would rather leave them on by default. The individual animator is going to have their own preferences, but it can be easily turned off if they aren't going to be used. Personally, I love the switches...I think they will make animating a lot faster.

Okay, here's the last test version of Squetchy Sam before the next rig release. This one has a few more bone names changed to help keep bones that don't need to be manipulated by the animator out of the way...they have "z_" at the beginning of their names like the others that were renamed. The other changes are pretty insignificant. The first test version of the biped installation rigs are put together, Mark and I are going to do some testing to see if there are any problems that we missed and then we'll release the next update. I'll also have an updated Action for Zign Track/AM Track that will be set up for the Pose export and a couple of things fixed that Luuk pointed out as well. If anyone finds something broken, let us know so that it will be fixed in the next release. In case anyone needs to refer to the videos or the detailed explanation, they are still located here. ----------------------------- EDIT ----------------------------- This test version of Squetchy Sam has been removed, the next rig update is located here.

Do you mean for jiggling, DJ? For that, I would just put a dynamic constraint on those bones. If you mean spine movement and squetching, there are a lot of controls for that in the spine.

The only time that I think an animator would need to have those bones selected is when they are doing the CP Weighting...unless I'm not understanding what you're saying, DJ.

How did you get it to do that, DJ? The "neck_geom" aims at and scales to the head...the controls as well, it's an IK setup. You also don't manipulate the "geom" bones directly (if that's what you're doing)...there are nulls for that. I haven't checked the neck squetching lately, I'll take a look late tonight.

The spine is completely different in the update that is going to be released...so any spine movements won't work well from the previous version of the rig.

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

These I took care of. Limited that one to one axis of movement...it needs that one. That one needs to be able to move. 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.

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

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.

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

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

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.

Incredible job, as usual, Stian!

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?

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.

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. I missed this, DJ...I'll fix them in the next version. I'll add those to the list. "Animation_Controls/FACE Interface/BothEyesDilate" or individually in the "Animation_Controls/FACE Interface/IndividualEyesDilate" folder...they are just above the "Blink" Pose.

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.

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. 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. 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.

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. That can be easily done. 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.

It's looking fantastic so far, Al! Very inspiring.