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: softimage-boun...@listproc.autodesk.com [mailto:softimage-boun...@listproc.autodesk.com] On Behalf Of Tim Crowson Sent: Wednesday, May 22, 2013 1:07 PM To: softimage@listproc.autodesk.com 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> tim.crow...@magneticdreams.com<mailto:tim.crow...@magneticdreams.com> 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.
<<attachment: winmail.dat>>
