>What does everyone else do to keep things from being keyed in ref model >situations in a production environment?
We used to use parameter locking until we discovered that it doesn't always work for parameters in referenced models. A number of built-in Softimage tools don't function properly with locked parameters either causing tools to abort prematurely (due to lack of error handling) leaving our work in a funky state. We don't use character key sets because that would force us to create a character key set for every asset in the game the animators touch. If the rigger forgets to insert a parameter into the keyset, then the animator can't work until the rigger can update the key set. Since other artists touch the rigs for different reasons, such as FX artists inserting their effects into the rig hierarchy, that's a lot of maintenance. Our custom simulation tools have over 400 parameters per emitter, and sometimes an individual rig can contain up to 15 emitters (rare, but it happens). That's too much to maintain without being bitten by human error. Currently we remove the Keyable and KeyableNonVisible parameter flags for parameters that shouldn't be keyed. This too is a bit high maintenance, but it's more acceptable if something goes wrong. For example, in the case of a character keyset, only parameters in the keyset can be keyed. If the rigger forgets to add a parameter to the set, the parameter cannot be keyed. If using 'keyable' flag on parameters, most parameters default to keyable being active. Therefore, if the rigger forgets to remove the keyable flag the parameter is still keyable allowing animators to work. It's just a matter of when they key something that wasn't intended to be keyed that we can go in and quickly isolate the problem and fix it. In both cases there is human error involved leading to undesired results, but using keyable parameter flags results in less time spent on troubleshooting when things go wrong. Matt From: [email protected] [mailto:[email protected]] On Behalf Of Manny Papamanos Sent: Wednesday, May 22, 2013 2:25 PM To: [email protected] Subject: RE: Setting and Manipulating Keys Very slow in Referenced Model Hi Enrique. I repro the issue in 2013SP1 QFE1 x64 with your test scene sent to support. The keying issue is nonexistent in 2014 x64 with your test scene but the f-curve editing issue is still there. Also, I tested my own gear character and things are fine with gear and ref models. I recreated a character keyset on your scene where I included all rotation and all translation on all controllers. Making it heavier than usual and things still seem to go a lot more smoothly when keying or editing. You may have omitted a very critical step in your pipeline: As you may know, 'Key all keyable' is the worst option to use because it will key all the parameters sr+t unless you edit them in bunches in the "keyable parameters editor" under (KP/L). At the end, inside the keying panel (KP/L), if we take the finger bones as an example, only rotation should be present if you use this option>'Key all keyable'. I personally use 'character key set' method for blocking then go with marked params... Key sets are good because you can interactively see what you are keying in one list by selecting the (two keys icon on bottom right)>inspect plus when you open the fcurve editor it reflects all keys in the char key set. If you have omitted this, then you're looking at 3x more data that has to be processed. Without this due diligence, the entire scene bogs down because you're dealing with too much data and this probably gets compounded with reference models. The real time playback will also suffer. Tips: Only include controllers in the keying list. There are a big pile of nulls that are being keyed unnecessarily in your scene. Also, the little man icon objects, don't include that either. Most likely someone may be using "key all keyable" and this may be bogging things down. To be on the safe side: I would go to the model level and lock what you don't want the animators to animate like all the scaling on all controllers and things like translation on controllers meant to be rotated such as finger bones. Subsequent scenes will profit from this, I don't know about current ones though. What does everyone else do to keep things from being keyed in ref model situations in a production environment? Manny Papamanos SI and Mobu support From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Tim Crowson Sent: Wednesday, May 22, 2013 1:07 PM To: [email protected]<mailto:[email protected]> Subject: Re: Setting and Manipulating Keys Very slow in Referenced Model Gotcha. Just making sure the vocab was clear. Yeah that's just asset management then... I have to say we don't have a good system in place for asset versioning either (also a small shop with real constraints), but it's something we're aware that we need. -Tim On 5/22/2013 11:55 AM, Sandy Sutherland wrote: Tim - it would be a system that controls VERSIONS of rig models for e.g., they would be tested, then passed on to become the 'current' version, which would then update the references. Basically to avoid say a rigger just writing out the model that is used by a bunch of animators, possibly adding some 'feature' or changing a hierarchy or whatever that then breaks the animation in the scene on the reference model. S. On 22/05/2013 17:40, Tim Crowson wrote: Just to make sure I understand the terminology... when you say 'versionned' referencing, do you mean a workflow that uses controlled 'resolutions'? -Tim C. -- Tim Crowson Lead CG Artist Magnetic Dreams, Inc. 2525 Lebanon Pike, Building C. Nashville, TN 37214 Ph 615.885.6801 | Fax 615.889.4768 | www.magneticdreams.com<http://www.magneticdreams.com> [email protected]<mailto:[email protected]> Confidentiality Notice: This email, including attachments, is confidential and should not be used by anyone who is not the original intended recipient(s). If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage mechanism. Magnetic Dreams, Inc cannot accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of Magnetic Dreams, Inc or one of its agents.
