Open Source Rigging System! Opinions?

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

THREAD CLOSED
 
Thread Tools Display Modes
  02 February 2010
Originally Posted by Darksuit: It might be a good place to start with figuring out all the different ways that a given body part or mechanic can be done. I know of at least 4 ways to rig the shoulder area without getting into FBIK. Just different bone and placement setups. The same is true for hands, and feet. It really comes down to a matter of personal preference, and people understanding that there may not be one "Right" Way to do something just a perfered way to do it, and how do you accomodate for those different ways and allow for the ability to expand.


I think that is an excellent suggestion, perhaps we should add a section to the cgtalk wiki and start doing this? Might be useful to have a description, overview of strengths and weaknesses, first place it was described (if known - ie Schiefler Rig, Osipa face rig, etc), a screenshot of the rig, and a file for each rig piece in say Collada format (or format specific if needed, although if Collada can't handle it we should likely request the spec be expanded for it).

LetterRip
 
  02 February 2010
Narann,

In your example you did not pass the class so if the class had data it would not have been passed.

I was just wanting to point out that mixing MEL adds complications that should be considered. I think basing the entire tool in Python with C++ would be the most robust. I dont know of one reason that MEL should be used over Python so why mix them unless needed.

Why use Python only? For a project like this I think these are strong reasons:

Modules protect variables and functions from overwriting each other in the global space
Packages allow for a module called math in two separate folders without conflicts
Classes allow for more robust data management and clearer programming

Buexe,

It really depends on what you are doing. I have written C++ plugins for that were tracing one nodes transform to another and wrote the same thing in the Python API and they processed in the same amount of time. Yes C++ will always be slightly faster, where Python really fails is when you need to iterate over a large amount of Maya data. We have many Python nodes in production at our studio and they are not slow.
__________________
Ryan Trowbridge
Character TD
NaughtyDog Inc
www.rtrowbridge.com/blog
 
  02 February 2010
Originally Posted by Darksuit: As a former instructor I always worry about people taking the shortcut without learning how we got there. Without the knowledge of how you got there, there is a lot of room to have a lot of "stupid" riggers. Basicly people who know a couple of buttons but don't understand the mechanics, principals or theories behind it. If there is a way to preserve this information and make sure that we don't wind up with a generation of button clickers, I am all for it.


It can be frustrating to see those kinds of shortcuts students make, or the flippant attitude by those who "where led to believe there would be no math" in computer animation, but we shouldn't concern ourselves with that argument. There are will always be people who want to take shortcuts and who feel they are better off the less they have to study. This project would benefit those who truly want to learn and contribute.


Originally Posted by Darksuit: Setting a standard is a little bit of a slippery slope, because it gets into the "Right Way" sort of mentality and that really sort of defeats the purpose of the rigger or TA/TD to creativly think outside the box to get something accomplished.



Don't think of it that way. It is just the opposite. The word 'standard' refers to the infrastructure. How you derive individual parts from there woulf really be up to your preference and requirements.

Think of the four ways you rig the shoulder, abstract those methods one level and you begin to see how you can parameterize the shoulder rig. Maybe you may distill the process to two shoulder rigs. or not. Those are some of the questions we will need to answer in the process.
 
  02 February 2010
This is a cool idea but it presents a lot of though that needs to go into it!
Firstly the question of 'open source'. I get paid for my expertise in building such rigging systems and tools and thats what pays my bills! So while I am a fan of open source software it's a slightly different consideration than a research group at a university running it.

Most people seem to be jumping right to a parts based auto-rigger. There are a lot of valid concerns with building a system based on parts. It almost always proves to be magic black box that is impossible to edit/expand/implement to ones desire thus forcing it's abandonment. One of the biggest problem with such solutions is the inability of the different parts to communicate to each other. To do that you usually end up adding a lot of glue code running as post process on top of the main parts build same goes for small changes to parts behavior. So while no system is perfect there's definitely a need to look at each possible paradigm and evaluate it critically.

I will post more of my thoughts in the morning.
Needless to say I'm rather curious and could see myself contributing to the project.

P.S. Definitely agree with Ryan that MEL should be avoided and only used when necessary (such as when certain tools require a global MEL proc as their callback)
__________________
Cheers!

Last edited by ShadowM8 : 02 February 2010 at 09:19 AM.
 
  02 February 2010
Originally Posted by Darksuit:
The Bad.
================================================== ==========
As a former instructor I always worry about people taking the shortcut without learning how we got there. Without the knowledge of how you got there, there is a lot of room to have a lot of "stupid" riggers. Basicly people who know a couple of buttons but don't understand the mechanics, principals or theories behind it. If there is a way to preserve this information and make sure that we don't wind up with a generation of button clickers, I am all for it.

The Good.
================================================== ==========
I am also working in games and find myself doing rig after rig. In fact I am looking at more than likely spending the next month or so writing an auto rigger in MaxScript. Not because I want to, but becuase there is a need for it in the production pipeline. I am only one person and my time is short, therefore I am basically writing this auto rigger so that I don't get bogged down too badly.

I certainly understand the benefits of a rigging tool. That said better standards would be a good thing. There are some "unwritten" standards, then there are prefered techniques. And more over there are some really bad techniques out there. For instance I am not a fan of the methods that Digital Tutors is using. I have corrected and fixed too many of the rigs that came from there not only on this board but else where as well.

General Comments.
================================================== ==========
It might be a good place to start with figuring out all the different ways that a given body part or mechanic can be done. I know of at least 4 ways to rig the shoulder area without getting into FBIK. Just different bone and placement setups. The same is true for hands, and feet. It really comes down to a matter of personal preference, and people understanding that there may not be one "Right" Way to do something just a perfered way to do it, and how do you accomodate for those different ways and allow for the ability to expand.

Setting a standard is a little bit of a slippery slope, because it gets into the "Right Way" sort of mentality and that really sort of defeats the purpose of the rigger or TA/TD to creativly think outside the box to get something accomplished.


You have some good relevant points.
__________________
[ myRiggingBLOG ]
[ myAnimBLOG ]
[ myWebsite ]
"Life is animation and we are our own animators." -i
 
  02 February 2010
Originally Posted by ShadowM8: Most people seem to be jumping right to a parts based auto-rigger. There are a lot of valid concerns with building a system based on parts. It almost always proves to be magic black box that is impossible to edit/expand/implement to ones desire thus forcing it's abandonment. One of the biggest problem with such solutions is the inability of the different parts to communicate to each other. To do that you usually end up adding a lot of glue code running as post process on top of the main parts build same goes for small changes to parts behavior. So while no system is perfect there's definitely a need to look at each possible paradigm and evaluate it critically.


I agree. When I start putting my notes on paper, I realize that to allow as much creativity as possible modules will need to be written with multiple possibilities to allow different options and have them communicate in some way. That can get messy on a longer run. There will definitely be a better way than what I think. So this project requires a lot of thinking and some experiments before committing to a particular paradigm.
__________________
[ myRiggingBLOG ]
[ myAnimBLOG ]
[ myWebsite ]
"Life is animation and we are our own animators." -i
 
  02 February 2010
Originally Posted by Darksuit: The Bad

I'm agree and not.
Agree because when you start in rigg, you have to understand the fundamentals if you want to be a rigger.
But disagree because everyone is not a rigger (or wont be) and a comfirmed rigger wont lost time (most if he can create his hown rigg)
I suppose if this rigging system want to be good, it have to be easy tu use but also give the opportunity to see what's under the "capot".
But verbatimline have a good anwser.
Originally Posted by Darksuit: The Good

Completly agree

Originally Posted by RyanT: I dont know of one reason that MEL should be used over Python so why mix them unless needed.

We are agree on this! Python is more appropriate on a "big" project than MEL (for all the reasons you give).

Originally Posted by RyanT: We have many Python nodes in production at our studio and they are not slow.

So I ask again: Do you think a whole Python writen rigging system (lot of lines) will not be so slower than C++. because as you said, more and more CG app can use python and it could be interesting (because more and more scripter will know Python and could contribute easely to the system).

About the "standards wich decrease creativity", I also don't think that. And for a standard become a standard it have to be used by everyone. So for now, it's not the prob (Your not snapping fingers and say: "Heay! I'd create standard! hop hop hop! Everyone: Use it!").

Originally Posted by verbatimline: Think of the four ways you rig the shoulder, abstract those methods one level and you begin to see how you can parameterize the shoulder rig. Maybe you may distill the process to two shoulder rigs. or not. Those are some of the questions we will need to answer in the process.

As you say, multiple rigg way will be a great question for the futur. System should be able to easely adding (contribute) rigging system. But I don't know how.
Originally Posted by ShadowM8: So while I am a fan of open source software it's a slightly different consideration than a research group at a university running it.

Mmmh... It's interessting to see how CG community reacts when Open Source is discussed. Open source is not confined for university. "Au contraire", for community project, you can't choose better. After, if someone think his expertise is threatened if he give it to a software that everyone can use, it's his choice. But I don't think so.
__________________
My blog (fr)
 
  02 February 2010
Originally Posted by Darksuit: It might be a good place to start with figuring out all the different ways that a given body part or mechanic can be done. I know of at least 4 ways to rig the shoulder area without getting into FBIK.


Darksuit, as a tentative step to one of the possible approaches to kick start this project, why don't you make a list of the strengths and weaknesses to your approach to rigging a shoulder. What are the considerations you take before choosing which solution is most apprpriate, what are the limitations and challenges, does the style of the character come into play? and so on...

I'd be interested to read people's responses and subsequent ideas. This will inevitably lead to more questions and we will go from there.
 
  02 February 2010
Sometimes I wonder how people could actually build and use auto-riggers without Python. LOL
The arguments especially for using the classes dont appear to me as a must-have. A stronger argument for it would the data structures and modules for pipeline stuff be. Even if some people claim speed is okay with Python or only "slightly"slower I think that it is always easy to state stuff like that with relative terms that can be interpretated later as needed. In the scenarios where I could make decent tests ( read intensive calculation) Python was only half as fast, even though I used the Python API to replicate the functionality of c++ nodes and commands. But that is just detail and in the end Python would prolly be the weapon of choice anyway, because it is accessible to more people. But before getting lost in technicalities I would encourage a discussion geared towards the overall design and goals of such an os effort like ShadowM8 mentioned. The paradigms should be clear and robust and accomodate for digital characters in all their sizes and shapes. I guess it would be cool if some sort of modular system could be designed that can build templates from smaller building blocks or whatnot. So peeps could add templates in a modular fashion and expand the functionality of the overall system. But sincw Erick wants to do the work we should just compile a huge wishlist and wait for christmas! : )
__________________
Digital Characters R&D - Suntoucher Labs

Last edited by Buexe : 02 February 2010 at 03:19 PM.
 
  02 February 2010
Wink great idea !

hi there

as i read through all the posts , while following this discussion within the past few days - i was wondering about the great idea of eric , to create a openRigging_pipeline .

for me , as a juniorTD , while learning on character_creation through the past 4 years , it was extremely difficult to find some kind of industry-conform-examples of professional-rigs ( scene-hierarchy , naming-conventions , joint orientation , classes , assets , modules , dynamic-UI , creation_scripts , deformer_skeletons , skincluster-creation / modification , load and save-routines for information as well as animation , correctiveShapes-handling , muscle-simulation - creating cached animation / bakeAnimation -> rendering_pipeline / animation-pipeline / modelling-and-texturing , back and forward / up and down ) . OK , you find some example rigs on the internet , and there are 2 or 3 books , which handle MEL_pipelines for creating rigs and UIs , but a deeper-understanding is difficult to develope . that's when it gets really interesting .

with a project like openRigger , one the oneside , it would be great for young TDs to learn a "proven infrastructure" in rigging_pipelines , which would be kind of a mix , of all the experience - the developers made , while working in the leading animation-companies . also , it might be extremely helpful for smaller companies that will have an insight in an "example-pipeline" ( to learn how to become more professional ) , as well , as the big studios will benefit - because real qualified TDs are rare and juniorTDs can have a sneak_peak into a pipeline , which might be more or less - what the supervisors in the studios , would confront them with . so the studios would benefit in a way - where trainees would be prepared much better and have a little better understanding , about

whatIs('A "Characters_Animation_Pipeline" \n')


-----------------
opinions:

if you start from scratch . i also think , no need to use MEL .

Python might be slower ( i personally compared it in several situations , using C++ , python_maya_API , MEL , even compared python_plugins with Expressions ) - e.g. when loading/saving skinClusters , python is "just" 2 times as slow as C++ - wheras MEL takes 20-50 x the time to load in a skincluster. so "in this case" it is great to use a "no-compile-plugin" ( and also , the "OPEN_CODE might be really helpful for others , to understand , what is going on "under the hood" in maya_API ) - if i think about the OPEN_information , which michael comet released with his poseDeformer_plugin and his melScripts , some years ago ... i learned so much about rigging that way.

As ryanT sais , i agree , that pythonPlugins should be implented as well as C++_tools / deformers / rivet_plugins / TimeLag_nodes --- or whatever idea might be implented , by the dev_contributers , e.g. averaging_skinweights will smooth_falloffs ( like the scripts , that jasonOsipa developed ) , loading/saving skinClusters , same for clusters , and all other "deformer-weights" , or any other time-consuming-operation )

i personally would like to see also "skinning-modules" . ( but i am not sure , if this is also part of RIGGING ... anyway , there is a lot information about rigging - but just a few people go one step further and discuss SKINNING_TOOLS and secondary animation_setups ) .

so , 'nuff talked ... need to go to work now

-----------
PS:
? back to topic ?
 
  02 February 2010
hi

i work for a time as character TD but long time ago, so im a bit out of the actual rigs

but i think that find a group of Characters TD that join to made something together must try to made more than a auto rig, i think that must try to develope new ideas instead of create the best of the old ones.

in my opinion the actual rigs have the problem that we are always creating the tools in each character/prop that we made, so the rigged asset is at the same time the tool and the data, if we can create tools, out of the model, to manage its animation (for example a ik-move tool, first select one joint or ctrl as origin and we move other , but the ik is not in the character, is a tool like standar move) and a base squeleton to drive the model, we have the control of how a model is moved and a easy way of change between diferent animations techniques

i dont know if this made sense to you and my poor english dont help
__________________
larry@larryvizoso3d.com
 
  02 February 2010
Originally Posted by tonytouch: hi there

as i read through all the posts , while following this discussion within the past few days - i was wondering about the great idea of eric , to create a openRigging_pipeline .

for me , as a juniorTD , while learning on character_creation through the past 4 years , it was extremely difficult to find some kind of industry-conform-examples of professional-rigs ( scene-hierarchy , naming-conventions , joint orientation , classes , assets , modules , dynamic-UI , creation_scripts , deformer_skeletons , skincluster-creation / modification , load and save-routines for information as well as animation , correctiveShapes-handling , muscle-simulation - creating cached animation / bakeAnimation -> rendering_pipeline / animation-pipeline / modelling-and-texturing , back and forward / up and down ) . OK , you find some example rigs on the internet , and there are 2 or 3 books , which handle MEL_pipelines for creating rigs and UIs , but a deeper-understanding is difficult to develope . that's when it gets really interesting .

with a project like openRigger , one the oneside , it would be great for young TDs to learn a "proven infrastructure" in rigging_pipelines , which would be kind of a mix , of all the experience - the developers made , while working in the leading animation-companies . also , it might be extremely helpful for smaller companies that will have an insight in an "example-pipeline" ( to learn how to become more professional ) , as well , as the big studios will benefit - because real qualified TDs are rare and juniorTDs can have a sneak_peak into a pipeline , which might be more or less - what the supervisors in the studios , would confront them with . so the studios would benefit in a way - where trainees would be prepared much better and have a little better understanding , about

whatIs('A "Characters_Animation_Pipeline" \n')


-----------------
opinions:

if you start from scratch . i also think , no need to use MEL .

Python might be slower ( i personally compared it in several situations , using C++ , python_maya_API , MEL , even compared python_plugins with Expressions ) - e.g. when loading/saving skinClusters , python is "just" 2 times as slow as C++ - wheras MEL takes 20-50 x the time to load in a skincluster. so "in this case" it is great to use a "no-compile-plugin" ( and also , the "OPEN_CODE might be really helpful for others , to understand , what is going on "under the hood" in maya_API ) - if i think about the OPEN_information , which michael comet released with his poseDeformer_plugin and his melScripts , some years ago ... i learned so much about rigging that way.

As ryanT sais , i agree , that pythonPlugins should be implented as well as C++_tools / deformers / rivet_plugins / TimeLag_nodes --- or whatever idea might be implented , by the dev_contributers , e.g. averaging_skinweights will smooth_falloffs ( like the scripts , that jasonOsipa developed ) , loading/saving skinClusters , same for clusters , and all other "deformer-weights" , or any other time-consuming-operation )

i personally would like to see also "skinning-modules" . ( but i am not sure , if this is also part of RIGGING ... anyway , there is a lot information about rigging - but just a few people go one step further and discuss SKINNING_TOOLS and secondary animation_setups ) .

so , 'nuff talked ... need to go to work now

-----------
PS:
? back to topic ?




I don't personally think there can be right and wrong way to rigging, I.e there's really no right way to name a rig, skin it or even rig it. But crucially there are conditions and approaches that most solutions need to meet:

Ability to update and change the source, whilst content has already been made
Fast, simple semantic traversal of the hierarchy
Ability to mirror any part against any axis
loading animation data on controls rather than the rig itself
etc..

I'd rather see open rigging standards rather than an open rigging solution, I equate this to W3 standards dictating how a markup language should try follow. There's a ton of young TD's out there following guides to rigging and tutorials without necessarily understanding the reasons why its done that way.
__________________
Disclaimer: My opinions are not those of my employer.


 
  02 February 2010
Originally Posted by eek: I don't personally think there can be right and wrong way to rigging, I.e there's really no right way to name a rig, skin it or even rig it. But crucially there are conditions and approaches that most solutions need to meet:

Ability to update and change the source, whilst content has already been made
Fast, simple semantic traversal of the hierarchy
Ability to mirror any part against any axis
loading animation data on controls rather than the rig itself
etc..

I'd rather see open rigging standards rather than an open rigging solution, I equate this to W3 standards dictating how a markup language should try follow. There's a ton of young TD's out there following guides to rigging and tutorials without necessarily understanding the reasons why its done that way.

Completly agree with that!

About the rigging standards, making it is possible. But it brings some problems because everyone have his vision of how a "good rigging should be" and, as you said, rigg depend of the needed. But I also think that since CG rigg exist, there is a way wich are commonly adopted by everyone and all CG app.

As W3C, it can be a work group wich think about that and make well thinked recommendations (W3C don't make standards, but recommendations). If everyone reconized himself in this recommendations, and know it's a recommendation, he will use it.

It's just my opinion...
__________________
My blog (fr)
 
  02 February 2010
Originally Posted by Narann: Completly agree with that!

About the rigging standards, making it is possible. But it brings some problems because everyone have his vision of how a "good rigging should be" and, as you said, rigg depend of the needed. But I also think that since CG rigg exist, there is a way wich are commonly adopted by everyone and all CG app.

As W3C, it can be a work group wich think about that and make well thinked recommendations (W3C don't make standards, but recommendations). If everyone reconized himself in this recommendations, and know it's a recommendation, he will use it.

It's just my opinion...


I think your right - recommendations is a better word, standards leads to rules and they tend to get broken all over the place. Recommendations or even conditions are more likely to be aleast judged on there merit and taken into consideration - more like sigh posts steering in the common direction. I think i might start this on my blog - there are definate way of proceeding with a rig that everyone tends to do. Making them a resource might be a good starting block.
__________________
Disclaimer: My opinions are not those of my employer.


 
  02 February 2010
Apologies for not having time to read all the messages ( I skimmed through) but I wanted to throw in my two cents. For those who don't know me, I was the author of The Art of Rigging series and since the publication of those books I've spent a lot of time thinking about modular rigging systems.

A few points:

-Python only, no MEL for reasons already discussed.

-There should be a collection of pre-requisite plugins to accompany the python scripts. In order to really get serious about this, we're going to have to extend Maya with new nodes types through C++ (not scripted plug-ins).

-The granularity of the 'modules' is a HUGE design decision. Making a 'biped' module is WAY to big. I would opt for atomic modules with generic functionality. That way, they can be aggregated into larger modules. For example, an "IKHand" module would have 5 children modules (1 for each finger). Then the IKHand has a clearly defined interface to plug into a limb (like an arm, tentacle whatever).

-Use a message connection system to create explicit connections between the components of the rig. that way, a component can truly own all it's nodes by linking with them directly. And I mean ALL it's nodes (every single DG node associated with a module is connected to the module parent node).

I have already written a VERY generic python message system inspired from the work of Justin Leach for Lucasfilm. It's a simple concept that make a world of difference. I would be glad to share this.
__________________
Kiaran Ritchie
Game Developer / Programmer / Rigger
www.bigfatalien.com
 
Thread Closed share thread



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
CGSociety
Society of Digital Artists
www.cgsociety.org

Powered by vBulletin
Copyright 2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump
Miscellaneous

All times are GMT. The time now is 01:43 PM.


Powered by vBulletin
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.