Red9 StudioTools have been born out of frustration at Autodesks reluctancy to add some of these core features and workflows into Maya itself. Why OpenSource, well I want to give something back to the industry as I feel damn sorry for studios without the benefit of a large R&D department to craft pipelines around them. The Studio Pack is designed to speed up a modern animation pipeline. All comments and suggestions are welcomed. For more info mail me :)
Wednesday, 5 September 2012
A few pointers for the new release
Red9 Studio Pack v1.26 is in testing at the moment with a few major upgrades.
Firstly it includes the upgraded MetaData systems, all of which are now integrated into the main AnimationUI calls, these hooks need testing but all seems fine so far.
With the MetaData I've also now added full Mirror animation and Pose support, based on the data that you bind up to the MetaData when it's added.
It also includes a MouseMoCap UI, something that somebody was requesting on one of the forums. It just lets you hook channels up from the channels box for record, then you hit the record button and any changes made to those channels get converted into keydata.
So a few pointers that have come up, be good to get others feedback on this stuff. These are comments on the api and code.
Question: * I'd somehow prefer it if mirrorData was a class/object
Yeah I kind of know what you mean. I was thinking of just a simple verified dict class that forces you to add
the correct data and pass that to the MirrorData arg. I guess I wanted to keep it simple when adding the metaData rather than having to make sure you build and pass in a mirrorClass settings object. The MirrorData ultimately gets built into a class when it's used by the r9Anim.MirrorHierarchy call, .getMirrorSets() builds the class dictionary up for the mirror sets which aree then processed in the main mirror calls.
One thing to note on this is that if you run without the hierarchy setup, the code will mirror matched pairs if it finds they're selected. Ie, you select left and right Feet, both of which have matching mirror slots, and their data will be exchanged. Now I could also have it search for the relevant matching pair object, so oyou select left and it finds right....not sure really. That might just be another wrapper call. Also if you have any center controls selected they're axis would be inverted.
Finally one thing I'm kind of stumbling on.... the axis by default works like this...
IF the mirrorAxis attr is found and has data, then those attrs will be inverted during the mirror
IF the mirrorAxis attr is found and has NO data, then no attrs will be inverted
IF the mirrorAxis attr ISNT found, then I use a default set of attrs to inverse
Does that makes sense? or do you think I should just stamp the defaults in the attr if you don't pass any in? That way the attr is always there and whatever it says is used.
Question: * MClassNodeUI().show() does not display sub FACIAL node from example (Doc's say it will display all)
This UI has an arg for mNodeType which by default is set to 'MetaRig' meaning it'll only show metaData nodes of type, maybe this should default to None so it does show all unless you want to filter it? At the moment it's only used by the Pose UI to find MRigs in the scene so you can choose the character to run the data to.
*Question: * The PoseFiles that get saved out currently load using the internal Filter that stored with the pose itself. Should there be an option to use either the internal PoseFilter, or the current UI Filter?
This is one that I'm mulling over at the moment. The backbone of all the systems is the FilterNode, the part that controls what nodes in a hierarchy get processed by all the functions. Now at the moment the Pose Loader uses the internal filter thats stored with the PoseFile. This has caught me out a few times and yes, I'm thinking that maybe there needs to be a flag in the UI to make this more obvious? thoughts??
*Question: *Should there be a UI to add the MetaData markers or do I leave this as a TD code solution?
What I may do is give people a really simple one that supports the predefined control functs (addWristCtrl.. etc) as well as an open add that wraps the main call addRigCtrl(). Not sure if the Mirror UI should be part of this or whether I should separate the UI's? Then again there's no real reason not to run the MetaData as it goves you so much more from a code point of view. Still a few more things to iron out, I want to be able order the ctrls in the dict that comes back, but not sure of the best way to do this at the moment.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment
Note: only a member of this blog may post a comment.