View Full Version : setting Locks on max bones ?
04-09-2006, 02:28 PM
Does anyone here see any value in turning on Locks for the Move, Rotate and Scale settings (within the Link Info tab inside of the Hierarchy command panel) for max bones - or any pitfalls that might occur ?
Of course, one would have spline objects that would move and rotate the underlying bone system.
04-09-2006, 04:13 PM
There's a few ways of doing it such as using the lock axis functions in the hierarchy panel, locking the control in track view but all of them have flaws. Your absolute best bet is to put an expression controller on to each controller you want locked - If you only want an object to rotate on the x axis, give it a position expression controller, a scale expression controller and then put expression controllers on the y and z rot. You don't need to know expressions at all, what will happen is the expression controller will take whatever value the controller held before the expression controller was assigned and use that as a constant (unless you edit the expression). It means you can't accidentally add keys to an fcurve track which is one thing that will mess up any of the other ways of locking a controller.
04-09-2006, 06:44 PM
thanks for the feedback, I've got one more question.
04-09-2006, 11:01 PM
would you say that a script controller with a constant value is 'lighter' or come with less processor load than the default Bezier Float controller?
04-10-2006, 12:14 AM
It doesnt really make that much difference to be honest - it's only when you start using expressions or script controllers that reference a lot of other objects in the scene or heavily layered controllers that things start to get slow. What does affect things though is that if you have control objects for a rig and someone is playing around in the fcurve editor, there's no other way to ensure that they can't accidentally set keys and potentially mess things up - I was setting up rigs on an ad that were stable and fine for the max animators I work with but we got in an xsi animator freelance and he found a few ways to break the rig by accidentally setting keys on tracks he shouldnt have, purely based on a lack of familiarity with the program. This meant that I had to re merge animation from earlier files or repair rigs in a few cases which took up time - changing the controllers to expressions completely locked everything I didn't want changed and solved it so even if there was a slight speed hit, I'd rather go with the solid rig option and find another way to get the fps back (such as make a low res mesh for animation purposes instead)
04-10-2006, 02:18 AM
I think you guys are making things too complicated. The reason to lock the bone is so that the animator will not move it when they are animating. It's just a way to do things on the save side so the character won't break. It's what you do when you are working in a team enviroment, to prevent any thing that might happen. Sometime when an animator want's extra control, they will go in to the bone and try to animate it, it's a big no no, espcially when you have to do cloth dynamic and other stuff like that, you want the character do be in the orginal position.
04-10-2006, 11:06 AM
Er yeah? Thats all we were discussing here?
Initially that he wanted to lock transforms on certain objects and second that he was wondering do expression controllers have any major hit on viewport and interaction performance?
I don't get what you're saying at all here...
04-10-2006, 12:36 PM
Thanks for your feedback, especially on some history to the issue. I did not know there were ways others could key in rotations on bones that are intended to only rotate with their parent bones.
Before, I thought that script controllers (in general) were slow but if they are not depending on any other object's value (but only a constant rotational value) then this makes sense why it would be a simple solution to lock down the bone's rotation value on any axis.
I was thinking of how one could 'remove' an axis from being interactively calculated when it's among other controllers within a Rotation List. Guess a script controller set to a constant rotational value would eliminate the computer's requirement to interactively calculate the "locked" axis' rotational value during animation.
Hope the last paragraph above explains my intent for locking down a rotation.
04-10-2006, 10:05 PM
Ah okay but bear in mind that script and expression controllers are totally different things since maxscript was introduced after expressions - expressions are very quick overall (and even quicker since max 8) and have certain benefits over script controllers (one of them being that they don't have a dependance on the names of objects - something that until max 8 was awkward enough for script controllers) but are no where near as powerful in terms of scope - for locking down a controller you're not gonna notice any real hit in interactivity, it's only when you start doing far more complicated expressions where loads of equations are being run that you'll get a hit (take for example early versions of eeks facial rigs) or in the case of script controllers where values within the script equations are being driven by scene objects.
Either way using expression controllers (again not script controllers) in this case is probably your best option.
04-11-2006, 12:06 AM
04-11-2006, 12:06 AM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.