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
This is the rule I've found across the board and I'm updating my tools to support it.

"Anything other than the content can change, and if by changing the source the content breaks you've failed."

The key is to understand what the content really is, with a rig it's the controls and their animation, with the model its the skinning of it surface, not its id's. With textures it's maintaing the UV's.
__________________
Disclaimer: My opinions are not those of my employer.



Last edited by eek : 02 February 2010 at 03:16 AM.
 
  02 February 2010
Gernerally nice ideas, I like the idea of having something package agnostic. Of course all packages have some special stuff. But shouldnt some decent basic rig be possible that can be transferred between packages. I guess they all can do skinClusters, clusters, some form of cosntraint, basic IK, etc. in one form or another. By having some sort of format that is scene/package independent ( like some meta blabla) it should be doable to create something decent. My guess is that this would also be appealing to the 3D community on a broader range, than just the users of a certain package.
__________________
Digital Characters R&D - Suntoucher Labs
 
  02 February 2010
I forward this thread to two individuals who are already implementing open source rigging tools, Nathan who is the rigger for Durian and was the rigger for Big Buck Bunny and Bassam who was an animator for Big Buck Bunny, and Director for Elephants Dream.

Nathan is currently developing his rigging tool for Durian (the current code is in Blender SVN), and Bassam is developing Rigamarule, for his film Tube.

I think a large scale collaboration is an excellent idea, and I hope this moves forward.

LetterRip
 
  02 February 2010
The concept of OOP relies on abstraction and classification, right? If we where to use the asset paradigm, we could define a basic class which defines an abstract asset. Lets call it, creature class. All other assets, such as biped, quadruped or amorph(customizable) derive from this one class by making its fundamental characteristics (upper body/lower body) more and more specific. So the most basic of methods are defined here, such as template recognition, joint creation methods, joint orientation stuff, metadata IO etc. The derived objects use these functions and static variables as well as stand alone function sets to create specific iterations of 'parts'. That would mean that individual contributers would need to learn and use the functions to create their individual parts, specially if we want these rigs which would have an infinite variety of configurations to work seemlessly/cohesively/uniformly with other parts and with motion capturerigs, deformable rigs and any other type of rig that escapes me. But once contributers become aquainted with these 'helper' functions they will be able to derive their own 'part' (arm - for instance) pretty quickly by reusing the code.

 
  02 February 2010
Nice idea Eric to put this out to the wider community. I've spoken many times to Cory at Autodesk about why they don't do something like this internally, standardize at least a core of rigging tools across Maya. But since they're not, I guess a community open source setup is a damn good idea, and actually probably better than Autodesk doing it anyway. Pool industry experts rather than let the dev team at it in isolation.

We have an internal rigging system with full animation tool support here but have recently been talking about switching the core of it over to Python so like you said, you'd have a build class for each main sub-part, all of which would be capable of bolting to any other part. The key to all of this isn't really the build part of the rig itself, its the core tagging systems that describe everything. How you manage data round the systems and pass that data back to Python nodes when you need it. Once you have a core MetaTag framework the rest is just wiring, and I'm sure that everybody will have their own take on how to rig an arm etc.

A few things from the games side that are worth thinking about is scalability and consistency. We often have a master rig that runs for an entire production across multiple characters, it needs to be able to bind solidly to MoCap yet at the same time be fluid and intuitive for cartoon setups. The same rig, same toolset, just different building blocks in a different order. We also use the rig only as a bind, the actual characters are just bound up when the rig is published out for the animators, this way you leave a layer between the actual game asset and the control systems. If things change on the skeleton, maybe the publishers want the character slightly taller, or to have narrower shoulder, then you deal with this in the bind and therefore don't destroy months of animation work.

Anyway, good luck, if you're looking for help from the games side let me know.

Mark
 
  02 February 2010
I'm no rigger, but this sounds like an animators dream come true! I'm very excited by the prospect!
__________________
www.smootharcs.com
 
  02 February 2010
The concept of OOP relies on abstraction and classification, right? If we where to use the asset paradigm, we could define a basic class which defines an abstract asset. Lets call it, creature class. All other assets, such as biped, quadruped or amorph(customizable) derive from this one class by making its fundamental characteristics (upper body/lower body) more and more specific. So the most basic of methods are defined here, such as template recognition, joint creation methods, joint orientation stuff, metadata IO etc. The derived objects use these functions and static variables as well as stand alone function sets to create specific iterations of 'parts'. Would it mean that individual contributers would need to learn and use the functions to create their individual parts, specially if we want these rigs which would have an infinite variety of configurations to work seemlessly/cohesively with each other and with motion capture rigs, deformable rigs and any other type of rigs that escape me? Once contributers become aquainted with these 'helper' functions they will be able to derive their own 'part' pretty quickly by reusing the code.



In essence, this sounds like a Lockian agreement between the cg community that decides to step out of the state of nature and into a social contract. The individual will forfeit some freedoms but will garner all the benefits of the larger society.

so count me in

Last edited by ekramer : 02 February 2010 at 05:49 AM.
 
  02 February 2010
Eric Miller said:

"A Modular Open Scripted Rigging Framework (probably based in Python w/ lots of MEL)"

I am not sure what I think about the open source part at the moment. I must consider that I get paid for what I do and I need to make a living. I wanted to point out an issue that I see with the above statement.

MEL is not designed to work well with Python objects. Example:

You have a Python file with several rigging objects.


import maya.mel as mel
  class armRig():
  	"""
  	My class for working with arms
  	"""
  	def createArm(self):
  		print "Create an arm rig."
  		mel.eval('melfunc self.setupFKjoints')
  	
  	def setupFKjoints(self):
  		print "do stuff"


Now the statement mel.eval() I typed would error. There is no way to pass functions from a class to MEL.

Lets say someone creates a procedure in MEL that you want to use in Python but that procedure requires that it can use the setupFKjoints function in the armRig Python object. It starts getting really complicated to pass data between a non object oriented language and an object oriented one. In fact sometimes it is impossible to find a work around without rewriting the MEL or Python code to accommodate for its weakness. Python allows you store your data in much cleaner easier to use ways by using classes. It would be a shame to mix it with a non object oriented language and weaken what can be done with it.

Also MEL is not designed in a way that works well with a large group of programmers. Python contains all of its functions and classes in each modules namespace. MEL turns every procedure it has into a global. This could turn into a nightmare with a large group of people in an open source project. If someone adds new MEL code who is to say they made sure to not stomp anyone else's global procedure or variable.

My only point is that I would stay away from using MEL in any way on a project like this. If you set it up in Python some of the solutions might be easier to port to other applications that already use Python like XSI. It is already possible to work with 3ds Max with Python as well. If the community does rise to the occasion there are people that might create special libraries for multiple applications.

And finally I would suggest creating your UI's with Python and QT. This would again allow users to create UI's that in the future could be used with multiple applications.
__________________
Ryan Trowbridge
Character TD
NaughtyDog Inc
www.rtrowbridge.com/blog

Last edited by RyanT : 02 February 2010 at 07:30 PM.
 
  02 February 2010
Originally Posted by RyanT: I am not sure what I think about the open source part at the moment. I must consider that I get paid for what I do and I need to make a living.

Mmmh... I don't think that an Open Source Rigging system could make a rigger to loose his job. There are many arguments against this way of seeing things but it's not the thread there.

Originally Posted by RyanT: I wanted to point out an issue that I see with the above statement.

MEL is not designed to work well with Python objects.

Yes, but the idea is not (or shouldn't be) to use MEL inside Python.
If you wrote a asset class in python, you not call MEL, you just call Python.
MEL should maybe be to interface the Customs nodes.
Originally Posted by RyanT: Example:

You have a Python file with several rigging objects.


      import maya.mel as mel
        class armRig():
        	"""
        	My class for working with arms
        	"""
        	def createArm(self):
        		print "Create an arm rig."
        		mel.eval('melfunc self.setupFKjoints')
        	
        	def setupFKjoints(self):
        		print "do stuff"


Now the statement mel.eval() I typed would error. There is no way to pass functions from a class to MEL.

I'd maybe not all understand but I have the impression that you try to launch a Python method (def setupFKjoints(self)) in MEL mel.eval('melfunc self.setupFKjoints'). It doesn't make senses.

But I maybe don't have understand the code (But I'm pretty sur that this code is wrong). Should be:


      import maya.mel as mel
     class armRig():
     	def createArm(self):
     		print "Create an arm rig."
     		self.setupFKjoints()
     	
     	def setupFKjoints(self):
     		print "do stuff"
     
     armRig().createArm()


This work!

Originally Posted by RyanT: Lets say someone creates a procedure in MEL that you want to use in Python but that procedure requires that it can use the setupFKjoints function in the armRig Python object. It starts getting really complicated to pass data between a non object oriented language and an object oriented one. In fact sometimes it is impossible to find a work around without rewriting the MEL or Python code to accommodate for its weakness. Python allows you store your data in much cleaner easier to use ways by using classes. It would be a shame to mix it with a non object oriented language and weaken what can be done with it.

Agree with that. But I suppose the idea should be to wrote all of that in Python. A MEL proc is easy to convert in Python.
Originally Posted by RyanT: Also MEL is not designed in a way that works well with a large group of programmers. Python contains all of its functions and classes in each modules namespace. MEL turns every procedure it has into a global.

Yes, but code organisation for C programs have sames problems and there is "methods" (but in Python, this prob will not apear).
Originally Posted by RyanT: This could turn into a nightmare with a large group of people in an open source project. If someone adds new MEL code who is to say they made sure to not stomp anyone else's global procedure or variable.

For already have contribute some to Open Source projects: "Open Source is not Chaos" lol. Every time someone want to add something, he post a "patch" wich is in a queue. And it's lead (kind of "project moderator") wich include them, renaming variable etc... Open Source way of work is most organised than many programming companies. Precisely because people are far. And there is alway almost One lead.

It's not nasty . But I think you don't really know what is open source (project and/or generally) and how it work.

Originally Posted by RyanT: My only point is that I would stay away from using MEL in any way on a project like this.

Yeah, I also think this is important. But convert MEL code to Python code is not a prob. Anyway, you don't have to. If you really need MEL proc:
MEL code: (execute it in mel):
global proc pythonIsCools(float $radius){
     	polySphere -r $radius;
     }

And this in Python:
import maya.mel as mel
     class myPythonClass():
     	def createArm(self):
     		myPythonRadiusValue = 2.5
     		mel.eval("pythonIsCools("+str(myPythonRadiusValue)+")")
     
     myPythonClass().createArm()

Work without prob.

But for this kind of project, I don't think this is a good solution.

Originally Posted by RyanT: If you set it up in Python some of the solutions might be easier to port to other applications that already use Python like XSI. It is already possible to work with 3ds Max with Python as well. If the community does rise to the occasion there are people that might create special libraries for multiple applications.

Mmmh... The fact that Python don't need to be compile is a very good thing (it is not dependent of the version of your software). But write a full rigging system with it could not be effective. 3D is math and at this race, compiled langages are far away from interpreted langages. That's why I think it's not a good idea (to be "forward looking"). Depending of how the system will work, if there is 10 or 20 rigg, your Python could fall while C++ could eat 10x more.
I hate compiled langages (specialy because we have to compile it ^^ ), but I'm also realistic.
As you, I think the best way is to keep the code less platform specific as possible and put it platform specific "on his doors" (with ports).
More: You talk about wrote the whole code in Python will be easy to port (for devs). It's true! But it's also a very good thing to have a framed code. It force you to have a mastered interface to your Core code.
Originally Posted by RyanT: And finally I would suggest creating your UI's with Python and QT. This would again allow users to create UI's that in the future could be used with multiple applications.

Not a bad idea but you musthave the pyQT lib on your station (don't talk about "Maya will have QT", because if it's like OpenGL, it will not be cross platform) and make two différents interfaces to communicate (Maya and your custom QT interface) is not very effective when you need speed. It should anyway be possible.

After, I said all of that but I'm not someone wich will dev this rigg system (maybe maybe). And this kind of decision depend of them. I only contribute to the debate.

__________________
My blog (fr)

Last edited by Narann : 02 February 2010 at 10:01 PM.
 
  02 February 2010
I would be ok with using solely Python code. there will inevitably be hickups along the way.
 
  02 February 2010
"Mmmh... I don't think that an Open Source Rigging system could make a rigger to loose his job. There are many arguments against this way of seeing things but it's not the thread there."

That is not what I said. I said that I work to make a living and working on open source projects does not pay the bills. A contractor does not build houses for people for free.

"I'd maybe not all understand but I have the impression that you try to launch a Python method (def setupFKjoints(self)) in MEL mel.eval('melfunc self.setupFKjoints'). It doesn't make senses.

But I maybe don't have understand the code (But I'm pretty sur that this code is wrong). Should be:"


Yes, you are not really understanding my point. The example I gave was an example that was intended to not work. You can not pass class functions to a MEL procedure by passing the entire class itself. The main issue is that you will indeed have to rewrite your MEL procedures to do some of the things that you will need to do. There is really no reason to use MEL at all because it provides no advantages. You use any of the Maya commands with Python and Python is a better language for setting up the type of system that is being talked about.

"Mmmh... The fact that Python don't need to be compile is a very good thing (it is not dependent of the version of your software). But write a full rigging system with it could not be effective. 3D is math and at this race, compiled langages are far away from interpreted langages. That's why I think it's not a good idea (to be "forward looking"). Depending of how the system will work, if there is 10 or 20 rigg, your Python could fall while C++ could eat 10x more."

It was already stated that this project would involve C++ plugins. I dont think there is an issue with using C++ at all. Also you should know that Python can process math problems as fast as C++ as long as you are not touching the Maya scene. Most custom nodes can be written in Python as long as they are not deformers and they will run just as fast as a C++ version.

"Not a bad idea but you musthave the pyQT lib on your station (don't talk about "Maya will have QT", because if it's like OpenGL, it will not be cross platform) and make two différents interfaces to communicate (Maya and your custom QT interface) is not very effective when you need speed. It should anyway be possible."

Why is it an issue to need to install py qt on the system? Many studios already do this. It will provide new interfaces that can not be done in Maya currently.

Just my two cents.
__________________
Ryan Trowbridge
Character TD
NaughtyDog Inc
www.rtrowbridge.com/blog
 
  02 February 2010
HI RyanT,

Quote: That is not what I said. I said that I work to make a living and working on open source projects does not pay the bills. A contractor does not build houses for people for free.


Software has different costs and benefits from house contracting - a lot of open source is common infrastructure things that save every developer reinventing the wheel, and to benefit from scaling of marginal cost/marginal value. It might take 10 hours to do a simple function, one that it would basically be impossible to sell due to the overhead involved in selling even if it is somewhat useful.to most other riggers. Giving it away might have little or no immediate benefit. However, if you get reciprocation ie 500 other devs give away 10 hour dev time functions, you might have now saved yourself 5000 hours, for the cost of 'giving' 10 hours.

Of course there isn't perfect reciprocity, not all contributions will be equally valuable, and there are plenty of freeloaders, but that is the general value proposition.

For most open source projects the contributor to freeloader ratio is fairly low (note that a non coder isn't necessarily a freeloader either, bug reports and documentation, and organization are big contributions made by non coders), but that still results in a phenomenal dev rate.

LetterRip
 
  02 February 2010
Originally Posted by RyanT: That is not what I said. I said that I work to make a living and working on open source projects does not pay the bills. A contractor does not build houses for people for free.

Ok, I did not understand (Sorry :buttrock that and this is an approach I really understand. But if you finish by use it (the open source rigging system) in you compagny, you will win money participating to this and profit of all the code of others dev.

Originally Posted by RyanT: Yes, you are not really understanding my point. The example I gave was an example that was intended to not work. You can not pass class functions to a MEL procedure by passing the entire class itself. The main issue is that you will indeed have to rewrite your MEL procedures to do some of the things that you will need to do. There is really no reason to use MEL at all because it provides no advantages. You use any of the Maya commands with Python and Python is a better language for setting up the type of system that is being talked about.

This work:
import maya.mel as mel
  class myPythonClass():
  	def createArm(self):
  		print("do thing")

global proc pythonIsCool(){
  	python("myPythonClass().createArm()");
  }
  pythonIsCool()

It's not that your talking about?
This don't work:
import maya.mel as mel
  class myPythonClass():
  	def createArm(self):
  		myPythonRadiusValue = 2.5
  		mel.eval("pythonIsCool("+str(myPythonRadiusValue)+")")

global proc pythonIsCool(float $radius){
  	polySphere -r $radius;
  	python("myPythonClass().createArm()");
  }
  pythonIsCool(2)

Give me a loop:
# Error: RuntimeError: Error occurred during execution of MEL script # 

But it's logical. So I don't really understand the prob. But it appears may be in another specific situation.

Originally Posted by RyanT: It was already stated that this project would involve C++ plugins. I dont think there is an issue with using C++ at all.

I also think that (I was may not enough clear).
Originally Posted by RyanT: Also you should know that Python can process math problems as fast as C++ as long as you are not touching the Maya scene. Most custom nodes can be written in Python as long as they are not deformers and they will run just as fast as a C++ version.

To be honest, I'd never wrote a 3D Math Massive Plugin in Python. And with your experience in Python, I suppose you know what you're talk about.

The only Bench I see was this:
http://www.osnews.com/story/5602/Ni...File_I_O/page3/

And Python is far Behind. But I seen another bench somewhere (with Python with Boost and it was better but not magic...).

Originally Posted by RyanT: Why is it an issue to need to install py qt on the system? Many studios already do this. It will provide new interfaces that can not be done in Maya currently.

Not really a problem but one additional depency. But yes indeed, maybe this is not so important.

Regards

Dorian
__________________
My blog (fr)

Last edited by Narann : 02 February 2010 at 11:02 PM.
 
  02 February 2010
I havent seen a python command or node that is as fast as its C++ version.
__________________
Digital Characters R&D - Suntoucher Labs
 
  02 February 2010
I think I have caught up on all the posts so far.



first I think its both a great Idea and a Bad Idea at the same time. Let explain the Bad first.



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.
__________________
There is no one right way to do anything.
Only the un-explored ways. =)
 
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 11:24 PM.


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