Jump to content

Dana Basinger

Nimble Customers
  • Content Count

    5
  • Joined

  • Last visited

Community Reputation

0 Neutral

Work Experience

  • Skills
    Editing
    Rigging
    Animation
    Rodeo Clowning
    Scripting

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Pieter, Welcome! Happy New Year to you as well!
  2. Thanks, you guys! BOTH your answers helped me out a lot, and I'm happy to say: it is working now! Right after the July 4rth vacation, I got called away to another city for 3 more weeks of freelance work, and consequently, I was far away from the Nimble platform, for much longer than I wanted to be. But I was so happy to see your answers, here, when I got back. First, I tried Jarom's suggestion: the zero group for the cluster - unparented it and separated it from everything having to do with the bow's main control or string control; I made sure that only the arrow could have any impact on the cluster. That certainly helped it to not fly off when the arrow was indirectly moved, along with the bow's main control, and then I found how to set the cluster relative to the parent transform, as Mark suggested. I checked the "Relative" box, in the cluster's attribute editor. It is working perfectly now! At least, this was what I envisioned it to work like. I know that, as a prop for animation, it might still be a bit clunky. The wrist controls of the character who wields the bow would need to be temporarily parent-constrained to both the bow's main control, and the opposite wrist to the cluster, itself, in order for the character to look like he/she is shooting arrows, using this bow. Quite honestly, I have not tried actually animating with it yet. I'll let you all know how THAT goes! But I'm just happy that now I can move the bow's main control around, and the arrow which drives the string will follow the bow's main control, both in translation and rotation, but will not drive the string in any direction, until it is singled out and selected, by itself, and moved specifically in the Z direction; (click below to see what I mean): BowRigFix.m4v Thanks so much you guys! I could not have completely fixed it without both of your answers!
  3. Hello all! This question will be long, what with all of the large images I am posting along with it, to try to explain it. It is a confusing problem to explain, so bear with me: I'll try not to confuse you as much as I have been confusing myself with this one: I have rigged up the bow in the Noa and Ulysse props library. As soon as I can get it working, it can be used as a prop in animation with them. However, I am stuck on rigging the string part of the bow, because I have a cluster of CVs, on the string part of the bow, which jumps way out of whack when I try to move the bow. The cluster is parented to a NURBs circle, which is driven by a NURBS arrow, in the translate Z direction. This is to pull the string, on the bow, back and forth, in the Z direction, and have the entire bow react to the pulling back of the arrow, like so: Now, I will "pull" back the arrow, in the Z direction: Then, when the arrow "let's go" of the string, (but not really, because the arrow is the main object control to animate the bow's string with), the bow reacts to the Z translation of the arrow, in the positive direction as well: Here is where it gets tricky: When I move the bow, the arrow either has to stay put, in it's current place, or if I parent the arrow to the bow, then the string keeps acting very strange, flying off every which way, seemingly reacting to the arrow. I can't move the bow and the arrow together, without the string going nuts. Here, as you can see: the bow's string is fine, as long as the arrow remains in it's current position. I can move the bow as long as I leave the arrow behind: I select the arrow to see if the bow is only remaining stable because the arrow's translations are all still at zero. They remain at zero because the arrow has not moved: If I move the bow but not the arrow, then I can still use the arrow to control the bow's response, to being "pulled" back by the arrow, in the Z direction: So far, so good. But if I parent the string driver arrow to the bow, then I suddenly get strange reactions, from the bow's string cluster, when I try to move the bow and it's driver arrow together: I can not move the bow, if the driver arrow is connected, anywhere in it's hierarchy. Anyway, to summarize: I have a rigged bow that responds to the pulling back, of the driver arrow, in the Z direction, exactly the way I want it to. However, in my animated scene, I'd like to be able to move the driver arrow around WITH the bow, without the string reacting so funky to that. I have tried a process of elimination, to figure out what might be causing the string to respond to the driver arrow, even though the arrow remains all at zero, in it's translation, when parented to the bow's main control. I have tried to eliminate the possibility of constraints causing this problem, by deleting all of the constraints in the hierarchy and simply parenting everything instead. That did not work. I have even tried deleting the driver keys, from the NURBs arrow, and even THAT did not work! It's strange; the cluster is reacting to being driven, but even deleting the driven keys did not save the CVs from jumping out of their spot when the bow and NURBs arrow get moved together. The only way to prevent the bow's string from jumping out and deforming was to leave the NURBs arrow unparented and separate from the bow, but that does not make for a very handy rig at all. Any thoughts are greatly appreciated! Thanks! --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 2 days later, and still exploring: I am adding some more visuals below to show my process of elimination; (This is my attempt to narrow down what might be causing the CVs to jump out of place, when the bow is moved, and the arrow is parented to the bow, by deleting those factors I believed were probably the culprit). I have 2 Maya files. The first Maya file is where the issue first sprang up. That is called "BowForRigging". This maya file has a lot of parent constraints, in the hierarchy of the bow. The constrained objects would also show numbers in the Y and Z directions, (not stay at zero), when moved along with the bow, so I deleted all of the constraints in the hierarchy and saved that bow rig to a new maya file called "BowRigFix". I was way too optimistic when I named it that. In BowRIgFix, there are NO constraints at all. Every constraint was deleted, and then every object simply parented, so as to keep the translation of the parented object at zero when the bow was moved. I applied "Freeze Transformations" to every parented object in the bow's hierarchy, to keep the parented object translations all at zero when the bow is moved. I checked to make sure the parented objects kept translations at zero, even while the parent object, which is the bow, was moved around: The NURBs arrow is now parented to the bow's main control. The Arrow's Z translation remains at zero, yet the cluster it drives still flies off in the opposite direction, just because the arrow moved, when it's parent; the bow, was moved. I tried deleting the driver keys for the Bow's string. To do this, I opened up the graph editor, selected all the keys, and hit "delete". Even after those keys are deleted, the CVs, on the bow's sling, still respond to the movement of the NURBs arrow. The arrow is only parented to the bow. It shows no translation values, when the bow is moved. I went down the tree, selecting each parent to make sure the translation values for each parented object remain at zero, even though the top parent (Main Bow Ctrl) was moved. Anyway, I know this is confusing and perhaps I'll just have to scrap this thing and start over; pray over it since it's clearly possessed, light a candle and make a wish, and/or just take a break for the coming July 4rth week. I'll come back to it later with fresh eyes and new ideas for how to tinker with it. I know there is something I am missing. I will continue to experiment with it later, and if/when I finally figure out this fix, I will post the update here!
×
×
  • Create New...