Search
  • Mike Malinowski

On Demand Rigging

During the R&D stage of Milo & Kate (way back in 2008) myself and fellow TA Ana Elez worked on an approach to Rigging and Animating which aimed at making it quick and efficient to work with high volumes of motion capture data within Softimage XSI.


A typical Rigging and Animation pipeline in Softimage would follow the paradigm of having a Rig built by a Rigger with all the required features for the project/character. Motion Capture data would then be retargetted onto the control rig and the Animator could edit from there. That approach works but it has a few flaws:


  • The rig has to contain much of the functionality required for all sequences

  • ... which results in heavier then required rigs - causing slower framerates with multiple characters

  • The retargeting process can sometimes be time consumingIts hard to made fundamental advances in the rig without paying a high retargetting cost


As a result we took a slightly different approach. Our stored rigs were merely FK skeletons with meshes bound to them. Instead the animator would pull in their Fbx file(s) and could select between rigs - or even just parts of rigs that were most applicable to the motion their were editing and trying to achieve. In this way we could start build very specific rigs that were light weight and focused on partiulur groups of animators or animation requirements.


It also meant a production would never be tied to a specific rig for the lifespan of a project as we could add new rig modules offering better or more efficient techniques at any time without impacting any pre-existing motion.


In terms of usage, the animator has the option to select from modules - in the video we see a full-character module which is actually a collection of four individual modules (arm, leg, head, spine).


Each module is a class which contains a series of metadata requirements. These requirements would allow the tool to know whether a module was able to bind to the selected part of a skeleton. The class also contains a build method which is responsible for the creation of the control setup.


Finally it also contained a binding method that held the logic required to map the pre-existing skeletal motion onto the control rig. Functionality to bake back down to the skeleton and remove the module was all held in a parent class as that is typically the same regardless of the control component.


This made for a very interesting and flexible approach to rigging and animation. The biggest downside is that you're always encouraged to work with baked data - which is not always ideal. For scenarios where motion capture data is the primary input, and Motion Builder is not an option this offers some really fantastic benefits - as shown by Richard Lico here in a demonstration of a technique which shares many similarities.


Sadly this toolset never saw production on Milo & Kate as its development plans and pipelines took some large shifts during the R&D/Early Pre-production stages.




  • github
  • Facebook Social Icon
  • LinkedIn Social Icon

©2018 by twisted.space.