sprockets Learn to keyframe animate chains of bones. Gerald's 2024 Advent Calendar! The Snowman is coming! Realistic head model by Dan Skelton Vintage character and mo-cap animation by Joe Williamsen Character animation exercise by Steve Shelton an Animated Puppet Parody by Mark R. Largent Sprite Explosion Effect with PRJ included from johnL3D
sprockets
Recent Posts | Unread Content
Jump to content
Hash, Inc. - Animation:Master

NancyGormezano

Film
  • Posts

    7,863
  • Joined

  • Last visited

  • Days Won

    15

Everything posted by NancyGormezano

  1. After you've browsed - you have to click upload before submitting the response.
  2. Hmmm....either the syntax has changed in ver 15b or the parser has changed - but I can get division to work if I enclose the numerator in parenthesis. ie - (..|..|..|..|controller.Transform.Rotate.X)/1 works in 15b I can hear the response now from the ficticious programmer who might work on this in a couple of months.
  3. Congrats! the previous image was very interesting. Have you tried to compress your final image? (jpeg)
  4. Here's another piece of info - in ver 15b when I try to access the right side of equation - I get a syntax error if I try to copy the statement (in the divided model) I do not get a syntax error in 14c I do not get a syntax error in ver15 in the no division model
  5. Very impressive Mr Boootaaah
  6. The divide doesn't work in any of the cases. I would have constructed my own test - however I can never figure out how to access the properties of another bone to use as an argument when creating/editing an expression. i.e., How do you get this part of the equation to show up in the edit box (other than typing it in) ? ..|..|..|..|controller.Transform.Rotate.X/1
  7. We've already concluded that there are multiple simple workarounds that don't involve expressions for sneering control. And probably other things as well. We're trying to isolate the problem to see just what is going wrong in the expression. Mainly as an exercise, and to see if there is the potential to interfere with other parts of the rig. At least that's what I think we're doing.
  8. None of them work. How about making a project that has 2 bones (A, - and some simple expressions scale a = scale b/1 translate a = translate b/1 rotate a = rotate b/1
  9. The plus 1 no division project works
  10. The z scale of the nostril y translation calc's are =100 and the nostrils don't move using the null (s)
  11. None of them work
  12. The value appears correctly: nostril_left_Y_translation_calc: 0 (did not check the other values) and It also appears that the face sneer nulls are operating correctly -
  13. In 15b those values are set to 100
  14. Because both you and Mark have worked so hard and helped so many of us, I'll play the role of seeing eye dog - who unfortunately happens to be totally blind to working with expressions. The sneer poses are set at 0. I'm not sure how to look at the z-scale value of those bones to see if they are set corrrectly - they are hidden in the action. In addition, something else is also funny between 14c and 15b. There is a difference in which bones show up in the action. You realize this is a crazy making situation ? Something, unfortunately I am perfectly, pathologically able to be drawn into. You don't have 15. That sends the message that you (the squetch rig) doesn't support 15. Or Hash. Or future projects in ver 15 and beyond ... which implies we would have to find workarounds. And if we all didn't subscribe to future versions ...well then...eventually there would be no more A:M...and ... From what I gather, Hash doesn't have a lot of resources to devote to tracking down problems. Especially from those who don't subscribe to the current version. And maybe for even those who do. I have no doubt this "expressions" problem stuff will show up further down the line, somewhere else. This is an exercise in futility to send in a report. ESPECIALLY if I send in a report. And especially if there is a workaround. Talk about K.I.S.S! My reports seem to have the K.I.S.S. of Death permanently attached, and slide straight to the IGNORE from the Looney Bin.
  15. Thanks David. That definitely helped. But... Ummm...ummm...lemme see...how shall I put this?... I am a very firm believer of the K.I.S.S principle. (Keep it Stupidily Simple or more rudely: Keep it Simple, Stupid) And I definitely subscribe to the philosophy of "If it ain't broke, don't fix it". I will spend hours upon hours trying to figure out how to get away with the minimal amount of effort on my part. That's how stupidly simple I am. However, luckily in this case, I could easily see that for my slimy Sneery purposes, having the Sneer poses translate and rotate the nose/nostril geometry bones to produce a sneer would be plenty good enough. No expressions required. I must admit Squetchy Sam has the most beautiful, unforgetable sneer I've ever seen - so smooth, so fluid, so ethereally sublime. However, it's not seductive enough to entice me into looking at Expressions. Thanks again. The Simple Squetchy Sam nose model was a big help.
  16. All 3 are set to 0
  17. Here's part of the confusion (and what I now just noticed in the full SAM model, is also happening): It appears that the influence of the sneer null movement on the CP's is stuck at the extreme. Yet the null is at it's "rest" position. When I open the action (or any new action) - the nose is initialized fully sneered (on frame 0). Moving the sneer null does nothing further. Probably something works differently with expressions in ver15b.
  18. Hmmm. I see. Hash won't sell it to you.
  19. I have sent in a report - a long time ago. I did translate the sneer null - it does NOTHING in 15 And why don't you have 15?
  20. I don't know what you're talking about - moving the sneer null on squetchy sam doesn't appear to do anything in 15b. The image I posted above was after trying a multitude of things (turning things on/off, & MOVING OTHER NULLS, bones, switches) to try and get the sneer slider to have some affect - But eventually the sneer null got misparented in the pws hierarchy. I have never had this happen to me in 13s or before. It has happened only in 14c and 15b. I doubt I'm the only one who has or will run into this problem. Surely you don't think I am deliberately dragging stuff in the pws? The hierarchy gets messed up after some sequence of trying stuff. Why aren't you guys using and supporting 15b?
  21. I tried the sneer 15b (face slider in 1, 2, 3, 4 % ) and the sneer does not work for me either - and after playing around with other things - turning things on off, moving nulls - in the window - not in the pws - the sneer null became a child of the sync null in the pws - more weirdness - I DID NOT MOVE/DRAG THE SNEER NULL in the PWS - I have seen something like this happen before also in 14c with other models (the chief loon) - with his arm bones: http://www.hash.com/forums/index.php?s=&am...st&p=252445
  22. Hi this came up in a thread in 2006 - there are multiple ways but this might be the fastest, easiest: http://www.hash.com/forums/index.php?s=&am...st&p=157164 essentially one can use patch images (not decals) on a 2Dish type ring. please don't hesitate to ask more questions, if there is not enough info in that thread
  23. Tis true. That's the way it works in 15.
  24. Thanks, David. uhhh...I'm using 15 - when editing the pose the compensate button isn't on ...I believe you mean when one first sets the constraint (orient, translate) - that the compensate is on by default? The procedure for resetting in ver 15 and before is the same?
  25. Hi David - I have searched this thread and I know this question has been asked a zillion times - I am really searching for what the objective is and what the exact procedure is for "reset compensate" - For example:I looked at the word doc and the first time I come to: In the "Animation_Controls/HEAD/NECK/head_and_neck_orient_like_chest" Pose, reset the compensate on head_orient_like_chest ("orient like spine_FK_3_chest") at 100% and 0% When you have to recomp at 100% and 0%, set the enforcement to 0% hit the compensate button and set the enforcement to 100%. Then, hit compensate again and set the enforcement back to 0% 1) Is the objective to reset the constraint offsets and to make the offset value the same at both 100% and at 0% of the pose ? 2) Is this the proper procedure?: A) right click on the relationship - select edit with red pose slider at 100: set enforcement to 0. Hit compensate button. set enforcement back to 100. C) with red pose slider at 0: set enforcement to 100. Hit compensate button. Set enforcement back to 0 D) close pose/relationship window Thanks
×
×
  • Create New...