Hey everyone, So we are currently working with Autodesk to try to find a solution to this issue. We have made this issue the #1 priority for one of our TD's. And for those of you who are also suffering from this problem
ie. Jeremie Passarin, Rafaele Fragapane. This is what we have found. I am pasting our report below. I hope that we can get this fixed. Hopefully this will help you guys out as well. V _____________________________________________________ Alright so here is the testing we have done so far on the "slow keyframing" issue when trying to set keys on multiple controllers. In this case we are talking about a characters 206 controllers with multiple attributes. As it is, trying to do this will take anywhere between 4-6 seconds on all tested computers here at the studio. Although we haven't solved the issue I can confirm the following can be ruled out: - scene files located on the network with referenced assets have no impact on the speed. local scenes with local assets on an SSD have been tested. - Clean Softimage user profiles were tested + freshly created workgroups were tested so we can rule out our custom tools and pipeline scripts from having an effect. Gear was also tested on a workgroup install and under User Add-Ons install. No impact on speed. - Possible bloatware from HP or "dirty" Windows system with various background apps can be ruled out. We clean installed a standard workstation with a vanilla copy of windows 7 and Softimage 2013 SP1 + python + gear. No impact on speed. - Process priority, process affinity, CPU energy saving/downclocking, Windows core parking, hyper threading was verified, edited to max out settings, and has had no impact on speed. - Tested our dual CPU systems with only 1 CPU, and according RAM removed. Also tested if there were any difference between similar Sandy bridge and Ivy bridge CPU systems, no impact on speed. --------------------------------------------- Keeping in mind the testing that was listed above, I should note that our definition of "slow" keyframing comes from the fact that we have replicated the conditions of the test scene on our personal computers/laptops and have achieved timings pretty much cut down by half. i.e. 2-3 seconds vs 4-6 seconds. The only thing these personal computers have in common with each other is a higher core speed than our studio workstations. Although I am hesitant to jump to conclusions, everything is pointing to the fact that keyframing in Softimage is purely dependant on the process running on a single thread. Most of the studio testing was done on a dual CPU workstation with Sandy bridge Xeon 2Ghz with 6 cores each + 16 Gigs RAM. I did a test at home last night on my home computer which is a single CPU i7 930 Quad core nehalem with 6 Gigs RAM (just FYI nehalem is a older micro architecture than Sandy bridge). As I overclock, my CPU is running at 4Ghz. I was able to keyframe all the controllers between 1 and 2 secs. Next, I downclocked my CPU to 2Ghz to match the core speed of our workstations. Keyframing timings matched the 4 seconds it took at work. I disabled 3 out of 4 cores on Softimage process and left the frequency at 2Ghz. Keyframe timing remained at 4 secs. A couple things became clear to me at this point. First of all, it won't matter how many cores you throw at it, since CPU usage during the keyframing only utilizes 1 CPU thread, similar to other various Softimage functions like duplicating. Not that I expect this type of process to be multi-threaded, but I'm just pointing out that a 12 core workstation vs a dual core laptop will have no significant impact on the speed of the keyframing instructions. ----------------------------------- Again all these results are relative for the moment. For all I know, 2 secs to keyframe 206 controllers on a i7 CPU running over 3Ghz should still be considered slow? hard to say really... Still a couple things I'd like to try, like older ver of Python, maybe older version of gear. Wish I could test the scene on older version of Softimage, sadly scenes aren't backward compatible. anyways, will keep playing around with this for a bit when I can. cheers, -John On Thu, May 23, 2013 at 10:46 AM, Raffaele Fragapane < [email protected]> wrote: > We mostly tend to use software, by version, or patched, or by package, > that doesn't shit itself over a meager 700 curves :p > > We have the same problem to some extent, but working in the thousands, and > when it's addressed it's addressed by giving people tools that key things > more conservatively. It's not always done though, and occasionally we pay > the blood price for it and ask for more fixes. > > As for character key sets, the general consensus, and this is across > several apps, is that they are the festering pit where good animation goes > to die, so we tend to stay away from them. They require a specificity of > actions and knowledge, not to mention a maintenance overhead, that means > they simply don't get used by any animator. > > You assume that animators work the way you do, with a thorough > understanding of the software's intricacies, most of the times they don't. > As far as software interaction goes, you have to assume rolling one's face > on the keyboard is as far as basic competence is required, and being able > to roll it both left to right and right to left is considered extreme > software dexterity and makes one an Autodesk Master. > > On Thu, May 23, 2013 at 7:25 AM, Manny Papamanos < > [email protected]> wrote: > >> >> What does everyone else do to keep things from being keyed in ref model >> situations in a production environment? >> >>
