preventing animators from parenting to specific nodes

[Me109]

hmmm.. you could publish your keyable attributes to a asset container.. and lock everything else.. the use 'save as' choose 'options' and 'lock' the file..

Then give the animators a file that references the rig and mesh separately.. and give them no direct access to the original references.. the animator won't be able to change anything.. and if they manage to change the file.. in won't effect the originals...

there's probably other methods of control.. I recommend beatings.....

J

[tonytouch]

@gmask:
you can select the nodes , and then type "lockNode;"

now , they cannot be deleted , unparented anymore . try the MEL-reference for more info

-----------------------
file-referencing would be another possibility , true !

have a good day ;)

[gmask]

I'll look into the asset containers..

I'm already referencing the files so I don't think locknode will prevent them from parenting other nodes to the referenced file..

I don't think my employers would approve of beatings :eek:

[isoparmB]

You can use referencing. One nice side effect is that objects within a referenced file can't be reparented (you can parent the root node though).

[gmask]

You can use referencing. One nice side effect is that objects within a referenced file can't be reparented (you can parent the root node though).

I am using referencing.. the problem is them parenting to the referenced object.. I have provided specific safe nodes to parent to or more specifically to parent constrain to but I've been finding that they aren't using them and they aren't using constraints. :cry:

[TechnicallyArtistic]

You could try bluffing them. Build a window to select the child, select the parent and create the constraint. Tell them if they are going to parent anything, they need to use this window with the new rig/pipeline set up or it'll break a bunch of things.

Might not stop it all together but might reduce the damage some.

You might also be able to write an expression that some how looks to see if there's any child of those controls they're parenting to, aside from any that should be there, and if they add one, it automatically un-parents it or undoes the last action or something and creates the constraint.

Just a couple thoughts off the top of my head. Never had to do it as I got to do the beatings instead. ;p


EDIT:
Just another thought on this. Could you make a mel script trigger that if anything is parented onto any part of the rig, I would at least think you could make a pop up window saying something like "If you just parented something to your character rig, undo your your last step and use a parent constant instead"

Maybe something like that could be a mel script you install on their computer so it's not rig specific? Depends how much parenting they need to do aside from parenting to your rigs. You could put an event trigger on your controls on the rig to tell maya to turn that script on and off when the controls are selected, but that still leaves some holes.

[greatPumpkin]

you are probably not going to have much luck actually preventing it, but what you could feasibly do is prevent the user from saving the file in the event you find transform nodes parented to a reference hierarchy. If I'm not mistaken there is a way to run some mel just before a save or save as event...?

you could try using referenceQuery -editString [name of reference node], you'll have to take a look at the output of this command, I haven't used it before, just going by the documentation.

that should return a list of all the mel commands that have edited that reference. if you search them for ones that start with 'parent', and then abort the save if you find any. you can then force the animator to fix the file themself in order to be able to save. they will soon learn not to parent crap to reference nodes! If that doesn't work there are more convoluted was that should do it, provided you are able to halt a save, worst comes to worst you can always hijack the file dropdown menu and insert your command before the save and save as functions.. but you'll have to make sure you get people's save shortcuts too-

[Gnimmel]

Would it be possible to change their P hotkey so it runs one of your own scripts instead of the parent command. This way your own script can check first it they are trying to parent to one of your rigs and if so take the steps needed to stop them, or even change what they are doing to a parent constraint. If they are not touching a rig, let your script go ahead and parent what they wanted.

I do a similar thing with pickwalk so I can set up pickwalks to step from right controls to left etc. I altered the animators machines hotkeys to run my own pickwalk script and if they do not have one of my rigs selected, then it just runs the original pickwalk instead.

All my rigs have a identification attribute on the top node so my scripts know if the animator is using one of my rigs or not.

Of course the only downside to this is that the animator can still go to the edit->Parent menu, but to type this I had to look up where that was. Who uses it when you can just press P.

Not sure if this would work in your situation, but it's what poped into my head after reading this post.

As a last resort you could always steal the P key from their keyboards ;)

Cheers,

Richard

[gmask]

Would it be possible to change their P hotkey so it runs one of your own scripts instead of the parent command.

Possibly but more likely there'd be a shelf button for parenting instead.

[XminusOne]

Hey G, at the risk of sounding like a smarta$$ and a dumba$$ in the same sentence, could you possibly just have a conversation with the anim sups and let them know that this behavior has to stop. That would be my first solution, if that conversation has already happened, and they're still doing it, the shelf idea and seperate "parent" curve would seem to be the easiest solution, but probably not error proof.

[gmask]

haha yes of course.. but the shelf thing is really the answer

[GrimPixel]

Just a thought from an animators perspective, but maybe there is a way to create a script or tool that would allow the animator to achieve what ever their desired result is while still maintaining the correct hierarchy you require? Some kind of front end script UI to a parent constraint control, etc... I have found that the best way to get someone to stop a behavior like this is to present them with an easy route to achieve the same result that fits into both your needs.

You might even be able to bind it to the P key thus allowing them the same ease of work flow while accessing a most constructive solution for you both. Just a thought from the outside though.

Grim

[gmask]

Just a thought from an animators perspective, but maybe there is a way to create a script or tool that would allow the animator to achieve what ever their desired result is while still maintaining the correct hierarchy you require?

I totally want that input but don't allways get it when I need it ;-) (hint hint add some stuff to standards and practices thread)

anyway another thing we've been fighting is that Maya being open ended as it is which is powerful gives you enough rope to hang yourself with. Too often the maintaining consistancy of the options of certain functions across the facility is difficult and I don't really want to cripple the program.

[BoostAbuse]

Assets in Maya 2009 will provide you with a solid foundation of what you're looking to achieve. With Assets you can lock the Asset, thus preventing any modifications to objects or attributes that are not published to the container. An example is a character rig like you have where you wish to publish only select controls that can be parents (i.e. are able to accept children) such as hand controls let's say. By specifying the hand controls as a Published Parent Anchor you assure that the object will only be able to accept child objects and never be parented (be made a child of) another object.

The other nice thing about the use of Published Anchors is the ability to cull the display of complex rigs. Let's say you've got an extremely complex character, you expand it in the Outliner from the root node and it stretches to the far reaches of the Outliner. By specifying what we call a 'Published Hierarchy' and defining Published Parent Anchors (can accept children) and Published Child Anchors (can accept a parent) as well as Published Root Transform (a specified transform the container will use as a selection mask in the viewport for manipulating the asset) and turning the Black Box attribute on you are able to only display your Published Hierarchy. This allows for the TD to manage what is visible to the animators and also helps the animators to be able to reduce the amount of clutter that fills their Outliner. Also, by using Black Box and Lock Unpublished you can further secure your character or asset by making sure that any non-published objects/attrs are not modified downstream and can also take it a step further by locking during Save As before referencing the file into a new scene.

I posted a brief summary of the work that was done for Assets in Maya 2009 here: http://forums.cgsociety.org/showpost.php?p=5628569&postcount=3 If you have any further questions feel free to drop me a line and I'd be more than happy to help you out.

-s

[gmask]

nice.. we aren't using 2009 yet but I'll definately want to use this when we do

[BoostAbuse]

The other thing I would suggest is setting up either a meeting or an email thread with your animation team and start defining some pipeline rules. It's easy to use lockNode and shut down an entire rig from having any nasty operations performed on it but you have to be careful how restrictive you are to an animators creativity. When I worked as a TD I always liked to sit down with the Animation Sup and lead animators to discuss what needs they had and go over the shots. They'd give me their needs for controls, freedoms they wanted, areas they wanted to be kept locked off and organized layers/hierarchies for easy selection. Anytime I had animators who needed extra controls or wanted objects to use as placeholders or attach points I welcomed them to use constraints and locators and had a nice tidy up script for them to organize their additional controls into their own layers/groups in the scene hierarchy.

The more flexible you can be, the better :) I've had animators come to me before with questions like "ok, so I've animated this squid swim cycle.. but now I need it to grab onto an object, still oscillate it's tentacles but I need them to stay wrapped around the other creature and I also need to be able to rotate around the creature it attaches to and then blend back off back to my animation when it releases the creature" which often leaves the animator with a curious face and the TD with a "WTF?" type look.

-s

[gmask]

The other thing I would suggest is setting up either a meeting or an email thread with your animation team and start defining some pipeline rules.

in a perfect world... :cry:

[BoostAbuse]

in a perfect world... :cry:

Heh, you know too many TD's get lost in the idea that Animation & TD cannot co-exist without disagreeing :) As long as you address their needs and they understand the reasoning as to why you have to do something a certain way there shouldn't be a problem.

[CGTalk Moderation]

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.