If-Then conditionals

[daniel-brakke]

Im trying to set up my futuristic tank so that when the aim controls Y-translate value is under .791, the missile pods will not rotate. Do I have to use a setRange node to convert the Y-translate to X and Z rotate? If so, how would I do this to replace an aim constraint?

[joojaa]

Connect a clamp node between the aim contraint connection and the translate nodes attribute is the easiest way. Appart from limitting the transforms movement offcourse.

PS: this post should be in rigging forum not animation, because this is rigging not animating per see.

[daniel-brakke]

Ah....Ehm...Sorry about the wrong section, but animation is where Im more comfortable. How do I connect the clamp node between the aim and translate?

[joojaa]

Select the aiming node, open hypergraph connections. Type "createNode clamp" in the mel box a clamp node appears. Visually find the aim at node 4 arrows will be moving out of it the last is a green arrow that when hovered over reports name.translate -> aimnodename.targetTranslate. Grab this arrow in the aimnodes end and lmb drag, drag it over the clamp node and choose input. Then mmb drag from the clamp node over to the aim node and choose other. In the editor that opens choose right display-> connected only, this helps yu find the target. click on output so it becomes selected, then click on target[0].targetTranslate (or the appropriayte index if you have several contraints). change the values in camp to be the range you need, set min y to be .791 y max to be a very big number say 1000000 repeat for the other maxes, set the minimums fo other to be very big negative numbers. Done

However this is not probably what you desire but does the contraint you asked for. You probably want to limit the output angles instead. But in taht case you would need to reorder the rotation so y comes next (by default i suppose), and offcourse you want a polar constraint. OR you can dirve the aims clamp min by distance, ncie thing about this is that it can account for ballistic arcs.

[joojaa]

No it would not affect the aiming translate in any way it will just change what gets passed to the aim node (the aiming would not rotate more down). It does what you asked, unless what you think you asked is something else*. In that case you must ask again.

See thing is theres no such thing as no rotate, at all times does a object have to have a rotate and it has to be piped form somewhere, theres no absentness in any data itas allways present even when its default vaules. There has to be data at all times. Example: Same thing happens with images people think pixels that are trasparent dont have color, they do and the color actually plays a part yiu just dont think about it this. leads to asll sorts of problems.

• 50% of the time failure is because people ask the worng questions yes. They can neither themselves solve or nombody else vcan solve the problem since the question asked is wrong. It often turns out

[daniel-brakke]

What Im wanting is for the rotate of the missile pods to be, in essence, locked until y-translate is over .791

[joojaa]

OK, but locked to what? See you get what you want but its not what you want.

See mayas dg is deterministic, that means at each frame and each value settings maya tries to predict a outcome based on values just at that frames no values outside this. Now if you move the aim past .791 the pod will snap into action. However it will snap in one frame instantly. So it will look like the animator is incompetent it suddenly jumps form one position to another. Worse because if you key the aim you will not know when exactly it will go under .791 and it will snap at a random point in animation. Now youd need to go and fix the snap, this is then a huge step more work than what it solved.

OK so you can simulate in maya and set the lock to be what it was just before it snapped out of bounds. Fine the problem with that is it doesn't work since odds are the animator wont be coming back up at in the exact same spot. Again this causes a jump, and animator looks inept. Second problem it doesn't lock up predictably whenever you animate so the animators feedback is not what he gets when played back, since locally the going under happens at some point while dragging but when played back that point is at some frame before this so they dont align. So now you must manually ensure the key hits exactly .791 this isnt ny easier than having one extra key.

Other problems .791 is not a conclusive position. Its solvable but for angles its not conclusive the minimum angle depends on how close you move the aim to the aiming part. So the end result is that the snap also doesn't occur at a predictable spot.

See what im trying to do is keep it simple, and predictable at all times with somewhat adhering to your condition and tough which will never work as you describe.

What you really want is to let the user key down the constraints weight to 0 to lock down and then lock up. This gives the users power over the transition without popping in animation. See yiu will find no matter how well intentioned the rig is, if it doens't help the animator (you) get there.

Now with that in mind rethink your question.

[daniel-brakke]

Im thinking its as you say, more complicated than it needs to be. In the hands of any compitent animator, they wont move the aim node x or z without moving it above y .791 and keying, and thus locking or restricting rotation is redundant.