Open Source Rigging System! Opinions?


#1

Hello to all the Riggers, Creature TDs, Char TDs, Tech Animators, and all other smart, creative or interested folks:

   [Erick Miller](http://www.linkedin.com/in/erickmiller)here, you might know me from authoring a bunch of the [HyperReal](http://www.amazon.com/s/ref=nb_ss?url=search-alias%3Daps&field-keywords=hyper-realistic+creature+creation&x=0&y=0) books, DVDs and MasterClasses, or maybe from talks I've given on character work in like Spiderman3, or Surf's Up ([click here](http://portal.acm.org/author_page.cfm?id=81335494902&coll=GUIDE&dl=GUIDE&trk=0&CFID=76047164&CFTOKEN=46087211)for a couple Siggraph talks).  Anyways, doesn't matter as much who I am, as why I'm writing this post!
 
 Well, I'm a big fan of the [Open Source initiative](http://www.opensource.org/) spearheaded by universities, research groups, and cool companies like [Google](http://code.google.com/opensource/), etc. - it's a brilliant way to advance a community to build something much better than any of us ever could on our own.
 
  For years now, I've been thinking about building and releasing a completely Open Source, fully extensible character rigging system (for Maya).  Something built from the ground up, that can grow to full maturity through contributions of new rig-parts and scripts contributed by our vast and talented rigging community. A modular rigging framework that is easy, extensible and compatible - both simple to use as a creative end-user, but also easy to extend by adding new reusable parts and rig-types if you're on the technical side. So any smart rigger could easily extend it with new awesome rig-parts (like some cool new "ikHand" for finger crawling or something) without having to build an entirely rig, you could just make that part by starting from the existing hand part, and re-use it forever.   Then, anyone who uses the open source tool, and builds a new useful part, would contribute the updates they make back to the open source project, for all of the rest of the rigging community to benefit!
     
 Now might just be the time and chance to create this system.  There's a certain set of circumstances right now that might allow us to make this a reality.   I've even made the first move.  I registered the domain OpenRigger.com -- but before I even begin think about getting us started on coding this thing, I want to put my finger on the pulse of this community and hear your thoughts.
 
   I'd want to build something that would not only make pro-level rigs good enough to use on any production, but would allow younger TDs to learn and more experienced TDs to contribute new rig-part scripts - something, ultimately, everyone could use! Something that would cover both Anim/Ctrl Rig, Skinning, Facial, Mocap (any new rig layer, like "rag-doll" or "full-body-ik"). Something you could drop mocap into just as easily as you could hand animate it w/ squash and stretch. A script based rigging architecture that's logical, TD approved, and with fast rigs that Animators will love to use. Something that would clearly work for vfx and animated feature production and also would work out of the box with game exporters like Unreal, or other middle-ware being used in the recent emergence of incredibly impressive high-quality next-gen console game characters.
     
   The whole idea here is production usable, customizable, high quality rigging automation framework that everyone can use, and many can contribute new rig parts to.    
     
   Unfortunately, I've written or seen thousands upon thousands of lines of reusable modular character and animation tools, ideas, work-flows, scripts, functions, plug-ins and nodes over the years.  Of course this is a good thing, but it also makes me biased towards immediately thinking of certain ideas. I'm sure some of this domain knowledge clouding up my brain will influence my decisions in a good way, but I am quite eager to hear your ideas first even more.
     
   I'm thinking the full scope of OpenRigger's freely available code-base would start at rigging and end somewhere in animation tools to include:
       * A Modular Open Scripted Rigging Framework (probably based in Python w/ lots of MEL)
   * Set of decent predefined templated "parts" (like "hand", "foot", etc) and rig assets (like "biped") -- these would define the standards other parts would be built similar to
       * Lots of reusable MEL libs, Python and C++ Utilities, Nodes, etc, used for all types of rigging
       * A series of useful Anim tools or utils that work well with the rigs (anim mirror, anim save, etc)
   * Possibly some extra pose tools, motion related tools, or mocap and animation/keyframe related tools that aren't specifically tied to the rig parts, but still useful and cool

We also have the less likely chance to converge, over time, on a rigging standard, that could mean compatible animation between studios, across industries, on all characters! But that’s a far-more lofty goal, so I’m not concerned about right now at all right now…

   Now, there's only one thing left.  Don't want to allocate the extra effort involved in building this thing unless I really think you -- the strong, awesome and powerful global rigging community would benefit, use and contribute new parts or rig-types you build within the rigging framework as you need them for production, so the rest of the community could have access to so many new and cool diverse rigged parts.
     
   This is where you all come in. I want to hear your thoughts. Your dreams. Your excitement. Even confused, jaded or fearful comments if you feel so inclined. Please let your voice and ideas be heard!

#2

This seems like a very good idea. Systems have been built and given to the world so I’ll add and edit my post with some tools that I’ve used and liked (regarding setup/skin/anim setup), as well as their weaknesses:

Setup:

- Advanced Skeleton by Oyvind Nostdal:

The pluses:
[ul]
[li]free, made by someone who knows his shit[/li][li]very easy to use[/li][li]library of skeletons available (and you can add your own)[/li][li]somehow modular, copies SDKs[/li][li]cool twist bone system[/li][li]all-node approach[/li][li]set of tools to create controllers, low poly versions of your model (a little experimental though)[/li][li]a pose system with screen captures for set up[/li][li]a nice, easy to use UI for selecting ctrlers (with mirroring, IK>FK and FK>IK)[/li][/ul]The minuses:
[ul]
[li]Very sparse documentation[/li][li]Some bugs (try adding more than one eye)[/li][li]Joint orientation sometimes goes haywire[/li][li]Some hacks are not that clean (I believe IK>FK / FK>IK function keys bones on top of deform bones which are not reset on bind pose)[/li][li]Not too fond of the ikSpine system (it might be just me)[/li][/ul]That being said, it’s free and awesome and is the system I’m using right now.

I’ll add more as I go.

bernie


#3

Completely agree with that! :wink:
Open Source for dev and Creative Common for artists is for me a great thing that create a good community!

Modularity is key in the success of an Open Source project so I’m also agree with that :wink:

Good thing!

Mmmh… Don’t know if this is a good idea. Most of the time, Open Source programs already have a ground. Releases are made when the system work and the architecture of the code is done. This is made by One (or maybe two persons). And it’s only once the architecture is done, the code run and all is ready that peoples are called to give idea for the rest of the dev. Ask people at the beginning of the dev in open source is not a good idea I think.
If you would create that, I suppose you already have a background as a rigger and know what you have to do at the first place.
First, create “Your” rigging system (most modulable as possible). And then, after you made a lot of demos, peoples will follow the project and add there own “modules” (Me, I can create “Custom locators” :rolleyes:).

I completly uderstand that! I’m almost agree but don’t “think to younger TDs” when you have to make a dev decisions. What make a program (or plugin) sources easy to understand is documentations. Not the program himself. The program have to be easy to use. But decrease his possibilitys “because of the younger devs” is a choice that can be disaster in the end.

Great! But once again, all of this can be modules. Not inside the program as a All-In-One solution but could operate separetly if they are thinked like this.

I have the impression that you really understand problems! All of that are great ideas!

And this is a very good thing! because you will know where to go! :slight_smile:

All of that is: :bowdown:
A good think could be to recode the parent constraint node for a more specific use (not a "all in one node like it is now).

Mmmh… Standards already exists. :slight_smile: But if your platform is easy to use with them (import/export anim easely) this should better.

As I’d said, this garanty is impossible to have. But if you believe in your project and after some versions, it seem to be interesting, peoples will use it, and, after, purpose thing to add. It’s the traditionnal march of an open source project: “Do it for you, let community create, and work together”! :wink:

I’m not personally a rigger, (that’s why you even don’t have to read my post! :D). I will talk in a pipeline view:
[ul]
[li]Stable![/li][li]Modular.[/li][li]Fully scriptable.[/li][li]Good dev/scripter documentation.[/li][li]Good artist documentaion (you know, with lot of pictures)[/li][li]Easy to “lock” rigg (bones are separate from the controller in order to only let the controllers selectable).[/li][li]Preset thinked (in, for example, xml for rigg lib, setup lib, etc…).[/li][li]Not “breakable” (for example, sometime, if animators add constraint, all the rigg is break).[/li][li]Great import/export possibility.[/li][li]Stretch attributes by IK.[/li][li]Not a All In One solution (!!!)[/li][li]Order manager for deformer (a kind of stack max like).[/li][/ul]That’s it for me but once again, I’m not a rigger.

I also think you should look at this (use it a see what is good/not goo).

Good luck! :bounce:


#4

I remember seeing AdvancedSkeleton years ago, but haven’t taken a look at it recently. It’s promising that it’s survived all these years. I’ll definitely give it a closer look. Also maybe contact it’s authors about their interest or ideas on their involvement in a project like this.

The time-line with rolling dev. for the idea would be to officially announce it, and then start with one or two highly qualified guys (I have a very solid guy I’m thinking of, but still open if someone out there is really passionate and wants to be involved). Then go quiet for a while, probably posting updates on forums, or some movie files as we make basic progress. Get basic build framework, and core design and set of libraries into a decent usable state - take it to a place where a decent rig can be built using the modules. That would still be pre-alpha, & start going from there, testing and using it in a limited capacity- knowing there’s need to build lots of the framework out - but the basic rigs themselves should stay fairly compatible, and able to be extended - but the rigging framework would still have stuff to be worked on. Then, set some milestones, split up, and build out the basics for the rest of the framework: parts-tester, ui-modules, rig-metadata, any file formats if needed, clean build-system, auto-docs-building, etc - this is all the yet TBD stuff.

At some point, after the time is right, and it’s fleshed out enough, but still needs some work, then open up the development team globally to maybe one or two more folks from the industry (pref. one film and one game), and based on their experience, motivation and need to write new rig parts for use in production. I’d guess we’d be somewhere close to late beta at that point.

The initial team would probably stay that size for a while longer, or it would be unmanageable. Of course, any time someone used the system and made an update, we would always want their update back in order to merge/integrate it into the code base if it’s really useful, since that’s the whole idea behind all this. The important thing is all the contributions be vetted for simple compatibility and that new parts function correctly with basic connectivity to other rig-parts, and all parts can be used with all the other rigs or parts. Or, parts may be able to define a typed compatibility list… anyway, not sure about that yet.

Agreed documentation will be key (and docs that are easy to read and understand, both tech-facing and artist-facing) - but also want to build the usage (both code-framework and rigs) as obvious as possible so reading the docs isn’t crucial at every step of the way - but be sure not to overbuild or limit it trying to cater to over-designed simplicity.

I can post what I’m thinking in terms of the basic foundations for the code, if there’s interest. Haven’t laid the complete design of this stuff out yet, but have a pretty good idea of the direction we should go, in terms of using object oriented python, etc.


#5

:cool:
A question:

It will be a cross app rigg system (like Character Studio could be)? (With port for each app, Maya, Max, etc… And rigg and skin could be compatible, could be interesting). Or it will be a Maya rigg system?

I know it’s hard but “think” multi app could be a good way to “drive the code”. (But of course, it’s harder…).


#6

Will be a cross app rigg system (like Character Studio could be)? (With port for each app, Maya, Max, etc… And rigg and skin could be compatible, could be interesting). Or it will be a Maya rigg system?

Well :slight_smile: I have thought about it. It’s a noble idea for sure. It could be totally realistic to build a core set of scripts that are completely agnostic set of self-contained 3d rigging functions or utilities in Python, without using any Maya libraries, that read a set of interchange formats, and enabled something like this. But then you start to want certain complex 3d data structures and algorithms, and other stuff, that it’s just quicker and smarter to use a pretested library for (like matrix transposing or something, not that it’s hard, but do you feel like writing that over again? lol). To further complicate things, stuff like basic tools, nodes, deformers and plugins that exist in one app and not in the other then make it really an ugly cross-compilation mess. When you start to think of the whole picture of it all, and the types of dependencies and complications this, it becomes a different problem to solve – you’re no longer solving the idea behind the project, so non-viable and not worth the effort because it would likely impact the quality or versatility of the rig and is outside this scope.

But all hope is not lost!

Autodesk will unify their formats and app frameworks… since they own just about every app these days – they already have some decent FBX interchange now, and if other unifying file format and application compatibility initiatives become a reality, then this might make the idea more viable – or just work. Meaning, yeah, if the rigging system is built in Maya, then you might need Maya to build the rig, but then if there’s unity between the apps at some core library level, you could possibly compile the whole rig into 3d Studio Max binary machine code, for example, and then load it as a shared library into Max (ie, a like the way a plugin works — but without needed to compile the entire Maya app into it to load your character, lol). And, this is talking realistic possible future - at some point there will be something close to, or like this - it’s the inevitable convergence Autodesk has been talking about at trade shows and cautiously planning for years now (ever since they started buying all the best content creation apps) - the part that is interesting is how and when they work the real-time game and world building part fully into the equation if they want to achieve complete convergence for digital content creation… but I digress.

Yeah, agreed. It would be nice if a “rig” worked in multiple apps. Not a landmark goal of this system, but there are bigger fish working on that problem.


#7

This is very interesting subject Erick.

I’m actually interested in building that kind of framework that would allow multiple riggers and rigging styles to share assets. I implemented something like this once, more along the lines of a rig repositioning and assembly system. This handles the construction of the rig, skinning is a different part of the problem.

Think of it this way. You can hard code the creation of multiple rigs of a particular “style”, and that is useful, but to a limited extent. You can add a certain amount of variability in the script, like say have a script build the hand joints with a different set of digits per finger or different number of fingers, or different number of spine joints, etc. But if you had to create another rig with a different rigging style, you would either have to revise your code or come up with completely different code to handle this new piece of data.

What if we actually had a library of parts, or treated rig components like they were just nodes, or lego, which is I think what you described earlier. Say, a library of just arm setups (excluding the hands), different kinds (doesn’t really matter), spines, hands, heads and necks, and had a system that was rig-agnostic, with another rig layer built on top of it purely for orientation and repositioning purposes, but with a system smart enough to know how to bring together all the different parts, apply all necessary rig components and processes that can only be applied after rig positioning (such as ik, joint orientation, etc.)? That would cut down on having to revise code, instead you would just need to build your template rig component once (or use an rig creation script), and would just “condition” a rig for repositioning and component attatchment.

So the process would go like: first, import all the necessary rig components (doesn’t even matter if it’s a biped, quadruped, snake like rig, or a vehicle rig even), you then reposition all the rigging parts via the top-layer reposition rig of the asset to the geometry that you want to rig (possible with the help of guide locators), you then “link” certain pre-defined attatch points of one link to that of another via tags (nodes that are recognized by the assembly scripts to be used later on), possibly with a simple generic interface that both registers all the components already present in the scene and that tells you what parts are linked to which, you then use the reposition rig’s controllers to visually reposition the orientation of joints and controllers, and when everything is clear you then execute a script which is a series of pre-defined procedures that go through the scene and look for the tags, and based of the definition of the tag (there can be different tags that just tell the assembler to apply ik, or reparent something to something else, or delete reposition rigs and tags once they’re done, but in a specific order), and then you’re done.

So basically these are your components: Your rig part library (which is a library of parts of bicycle setups, arms, spines, wheel setups, weapon controls, and whatever else you can think of), a reposition rig with every one of these parts used to reposition the component upon importation, an interface system used to import, register, connect and “tag” these parts once they do come in, and pre-defined assembly procedures that do a series of rig functions such as ik reapplication, reparenting, cross-component expression or node connection, character-set consolidation (bringing sub-character sets together under one main character set, if you use them), and a host of other rig prep procedures, which is generic (there shouldn’t be an assembly script for quadrupeds, and another for bipeds, it should also be form agnostic and should define rig procedures as basic as possible).

The system should be generic enough that the rig component’s rigging style shouldn’t matter, which means all the basic rigging issues have to be accounted for and handled in the assembly script, or that there should be a procedure for every conceivable rigging issue, and all components of the library would have to be pre-rigged in a certain manner so as to be recognized by the system. It won’t be able to mix ALL parts with all OTHER parts (not all parts should be compatible with each other as some rig components using a particular rigging style will be dependent on another’s components, i.e., a space switching system for an arm rig, as not all hip or head components would have the necessary constraint node needed by that arm rig), but for the most part you should be able to mix and match arms, hands, spines and what have you, and should look and feel like you really are just assembling parts of a big lego asset. It would be a framework that allows people to share assets, as long as they follow a generic enough pattern and ruleset that should be able to accommodate almost all rigging styles.

Well, these are my thoughts on the subject.


#8

Had an interesting discussion about this a while back that might be interesting:

http://forums.cgsociety.org/showthread.php?f=88&t=657764&page=1&pp=15&highlight=rig+reposition


#9

So how do we begin? Erick has laid out the mission statement and there are particulars still to be determined. What is the infrastructure that has to be laid out before we can begin to contribute practical assets?

tim


#10

First is to decide how and what to build as the foundation, since key design decisions are pretty important at the very beginning.

What I’m currently thinking is the build system components would be based on the idea of assets and parts with “templates”, where an asset is essentially a full rig-type consisting of a bunch of different parts/part-templates. So, a part has a “template” that you move around to position it, and a “script” which is a Python class that attaches to the template and runs the build-code. The template and the part together define where to position the rig and how to generate the rig. The asset template would consist of a collection of “part” definitions that “connect” to form the “asset” – So, each “part” would have a “template” and each “asset” would consist of a collection of “parts”.
Example of an “asset” is a character or creature, like “biped”, “quadruped”, “avian”.
Example of a part is a “hand” or a “leg”, or “arm”, or “tail” – and it’s “template” is a file containing of the positional, orientation and layout information that tell that part’s build script where to build the joints and controls.
Totally along the lines of the legos idea.

There would also be a deformation template that would be an entirely separate file where you could define deformation only joints, and would support a few basic deformers (skincluster, cluster, etc) skinned to a generic mesh that could be used in your asset build script to transfer nice clean, pre-painted weights from a generic mesh right onto your custom character’s mesh.

The whole idea here is production usable, customizable, high quality rigging automation that everyone can use, and many can contribute new scripted rig parts.

I am thinking that Python is the right language – where all new parts or sub-parts, etc, should be declared, and a derived Python object should be the place that triggers the build process. Python is nice because it’s extensible, easy to prototype, and easy to bust-open and look at the source. But, the full source code of the entire project tree would most likely contain lots of libraries and scripted tools or plug-ins, etc, that would be a mixture of Python, MEL and C++, just for practicality and in some cases necessity. I am thinking, though, for the core build system, that Python would be the smartest thing as the foundational “frame-work” piece. Might look at using JSON for reading and writing templates or asset definitions if this is necessary, but to be honest, I haven’t fleshed the design through that far. I’ll admit, I haven’t gone all the way w/ class diagrams, uml or refreshing up on my design patterns, but I’m starting to give a few of the key ideas and concepts some thought. I’m also thinking I want the community to build rig parts and contribute them back, so there should be an easy rig-testing and validation system that makes sure the parts all have the right stuff and are built properly. Nothing too restricting, but checks for errors using an automated testing process during the build to catch errors that could cause any incompatibility with the rest of the system immediately. So, there will probably be a set of generic unit tests and a simple testing framework built in, but now that’s getting into too many details at this stage.

The idea is the system would use object-oriented Python to design and create new basic building blocks. So Python objects would be the core engine used to define a new character “asset” type and to trigger the process of creating the custom rig. This way you could use your own user defined class with inheritance to derive and create new parts (like “tail” or “wing”), and then internally construct a new generic creature-type “asset” class, such as a “bird” or “quadruped”, by defining your own new collection of overloaded “parts” or a new overloaded “asset” etc.

Trying to think about stuff like, how could build the system so you can easily inherit from, say, the “biped” class to create your own 2 legged creature, like a “werewolf” creature or a “robot” or something, so you can easily customize, without needlessly duplicating all the source templates and code from the “biped” class. Making sense so far?

The other cool thing about using OOP w/ Python, besides it seeming natural and the obvious benefits of OOP, is that Doxygen has native support for Python, so each new release of new rigs or rig parts means they’d have a full rig-part library documentation, as new rig-types/scripts are added, they’ll be easy to discover and learn what they do by reading through the documentation.

In terms of the Ui for building the character, the rig-type build UI would probably dynamically build itself based on which parts your rig is using. There would be pre and post callbacks all over the place, and some series of basic “connection” objects or code so that connecting parts together is simplified and consistent. I’m also thinking an “asset” class could have a defined (optional) attribute that stores it’s character UI based off of a basic UI template, so each character loads with it’s own built-in simple UI that can have a custom background image, used for basic control selection, or for firing off scripts that can control the rig (like Ik/Fk switch, right-click context menus, etc).

All right. Those are some more thoughts… and yep, I’ve thought about this before… but still seeking gut reactions and new ideas.


#11

All of these is interesting. So a new asset (biped, bird, etc…) will be a derivate of a Python class asset?

Is it that? Do you think it’s the best idea (I just ask :wink: )

About the choice of OO Python I completely agree! Combined with Doxygen it’s very cool! But you have to well wrote your code to be “understanded” by Doxygen…

I will follow the project :wink: If you have time, could you do shema (UML or not) to well explain how all of that will work? (difference and group “asset”, “part”, etc… :slight_smile: )

So the code will be Maya oriented? Right?


#12

Hmmm.

My initial thoughts are, yes, python would be the way to go. But regarding setting up classes as character/asset types, I’m not completely sold on the idea. It makes sense, but it might also be limiting if you have to create a character that doesn’t completely fit into any of the pre-existing molds (i.e., a biped with 3 pairs of arms? or 2 heads). It seems to make more sense to me if the individual components were the classes, and whatever higher conglomorate of parts was left up to the user (if an artist decides to call it a biped, that makes sense as a conceptual marker for working with the thing, but if followed to closely for the purpose of rigging it might tend to limit your choices). I’m just saying it would be useful for 90 percent of the time, but it might stratify the code to not be able to handle special cases.

Although these are just my thoughts at the moment, I could be convinced to change my mind. I have to finish this post later as I think I’m about to get locked in the office. :smiley: Got me thinking though…


#13

It is very interesting that this came up on the forum at the same time I am putting diagrams of my autorigging tool with a very similar concept. I was thinking about the same OOP design to abstract the template and the rig itself. So for creating a new part you create a new template class that uses derived template objects for defining structure and define rig as another class that builds the control skeleton system. The main application identifies these new objects as a new rig type specified by other riggers it is integrated into the character rig.


#14

Biped isn’t and I don’t think every would be as not many people really like it. CAT already is as it is in XSI and Max, who knows, Maya might get it one day. It is not open source and although it has some great features it also has some flaws and it is not open source.

I like the idea over all, it is weather you can get a bunch of TD’s to agree on a system, every one tends to do it their own way.

Here is a take on it that I have and built for Max. If you have a look on my site here you can see RAIC Referenced Autonomous Intelligent Control (http://www.penproductions.ca/technical/raicSystem/raicSystem.htm). This is not a rigging system in it self, it is a control system and animation system for any rig. The rigging system that we use here is not shared at this point. The idea is it is a unified control system where each control in the rig hold information about who it is and what its role is in the system. When added to the root node for the system it become part of that system and at that point the rig sort of knows all of its parts and what they do and how they will be worked with. The idea is I don’t get stuck with a single rig system that will work only in certain instances. This is one of the problems with CAT, if you make a change to a part you can break other features easily. Change the spine to just FK and you can’t use mocap any more. In the RAIC system I can tell the control what it is and how it will work with other parts of the system or out side resources like motion capture data. The controls don’t really care what is hooked to it, they just care about what it is they have been told to do. This way the rig can be anything that we want and there is always a unified control system wrapped around it. RAIC is a plugin based system written in Max script at the moment so it is easy and fast to update and any updates are propagated to the rest of production just by updating the plugins on any system.

Would be interesting to see some thing like this cross platform, because each of the major apps works so differently with the rigs it would be impossible to make one tool to rig an arm, but if a unified control system were developed and took into account certain data it might be possible to write tools to port animation easily from one system to another because the control system would be similar. Once again, it wouldn’t matter what they are pulling around or how that all works, just matters how the system interprets animation data.


#15

No no no no! I never wanted to say that! lol Sorry if I was not clear…

Yes, CAT was a better exemple than CS. :slight_smile:

As you, I think the “Open source” way could interest many TDs.


#16

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.


#17

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.


#18

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


#19

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.


#20

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