sprockets Learn to create your own tool bars! Behind The Scenes: A:M and Animatronics Jeff Cantin's Classic Splining Tutorial Strange Effect, video demo and PRJ included John blows up a planet, PRJs included VWs by Stian, Rodger and Marcos Myron's band gets its own wine!
sprockets
Recent Posts | Unread Content
Jump to content
Hash, Inc. - Animation:Master

itsjustme

Craftsman/Mentor
  • Posts

    5,776
  • Joined

  • Last visited

  • Days Won

    55

Everything posted by itsjustme

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. We're in the middle of putting the installation rigs together, Ken. It shouldn't be more than a couple of days.
  7. 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.
  8. I'll add that to my to-do list for this evening. Thanks, DJ.
  9. 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.
  10. 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
  11. I'll fix it in the next update...I'll post it late tonight. Thanks, DJ.
  12. 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.
  13. Incredible job, as usual, Stian!
  14. 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?
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. It's looking fantastic so far, Al! Very inspiring.
  21. Okay, here's an updated Squetchy Sam. The changes include: 1. Renamed spine controllers to have "spine" at the beginning of their name (I didn't do that to the "hips" controls...maybe that should be done as well?). 2. Renamed all on-character switches to have "z_switch" at the beginning of their name. 3. Moved the "switch_setup" Pose outside of a folder and put it at the top of the "Animation_Controls" folder. 3. Varied the colors of the "geom" bones. 4. The "head_manual_control" bone hides when the FACE controls are active. 5. All on-character switches are constrained so that they don't move in a way in which they aren't used. 6. All of the normals in the FACE interface now face forward. 7. Renamed all of the FACE interface bones used for hiding FACE that appear in the Timeline with "interface" at the beginning of their names. I think that's everything so far...was there something missed? Any additional issues? --------------------------------- EDIT --------------------------------- In case anyone needs to refer to the videos or the detailed explanation, they are still located here. --------------------------------- EDIT --------------------------------- This test Squetchy Sam has been deleted, the next test version is located here.
  22. 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.
  23. They are locked down in the next version, Nancy. I'll post an update later tonight for further reviewing. We had them "on" by default for this testing, I'm in favor of leaving them "on" in Squetchy Sam (so that people new to the rig will know they are there) and setting the default to "off" for the installation rigs. What do you think? I'll change that. Thanks, Nancy. I'll make those changes as well. Absolutely not, Nancy. We need this kind of input to put a polish on the updates and find the things we missed. We appreciate the time that everyone is spending to help. Thank you, to everyone for your help.
  24. The leg switches turn on/off the IK leg controls and the scale-to-reach switches (visible when in IK) make the leg/arm scale to reach the IK hand/foot controller. In the videos that I posted I show how to use the switches. The added switches is an attempt to make it easier for the animator by eliminating the need to dig through folders for often used Poses while animating. True, it will create more channels, so it depends on the animator whether it will be seen as a benefit. If the switches won't be used, they can be turned off in the "Animation_Controls/Switch_Controls" folder. One thing we could look at is renaming the switches (and anything else that gets in the way) so that they will be grouped away from the other channels...that might help. For the spine, you could use just straight FK or IK and ignore the other settings, Nancy. Not every character or situation will require the use of every knife in the drawer...but it's always nice to have options.
  25. I'll put that on my to-do list. Thanks!
×
×
  • Create New...