I am super excited to finally be writing this!

The platform at talk.bindpose.com is now live and open for everyone! There probably are some bugs as it’s still rough around the edges, but most importantly we can start using it!

So head over there to register and start asking, learning and talking about the cool rigging topics you are interested in!

A screenshot of the first post on talk.bindpose.com
A screenshot of the first post on talk.bindpose.com

Thank you

Firstly, I really want to thank everyone who subscribed and now registered to use the website. If we want to have an online rigging community we all should do our best to make sure it’s alive and kicking. So again, thank you to all who supported this endeavour!

The platform has been running hidden for about a week now with no more than 5 people on it and already I have found out ideas that are beneficial to my rigs! Big thanks to those who weren’t scared of the blank page and came in early on to get some content running!

I have talked about why I wanted to create this place previously – here and here – so I don’t want to repeat myself, but I want to share some ideas of what I want this place to become.

Sharing ideas

Most importantly, I wanted to have an active rigging community, so I can pick the brains of people way smarter than me and learn as much as I can directly from them.

That being said, the idea of sharing my knowledge as well has always been an exciting one for me and that is why I have started the blog as well. The thing with a blog is that it is quite one-sided, so it is nice for showing and sharing ideas, but not great for starting a conversation and hearing different opinions on them.

Getting feedback

Having opinions that are never challenged is dangerous. Going through your rigging career without checking your premises would put you in a disadvantage to people who do. In an industry like ours everyone knows how important feedback is. Therefore, I wanted to have a place where people are welcome to criticize my ideas and more importantly, a place where I can easily see that criticism.

Just chatting and lurking

Additionally, I really like rigging, but it’s a niche topic, so finding people to talk to is tricky. And I do really want to talk to people about it, even outside of my professional interest!

I tend to spend a big portion of my free time reading (lurking) through Hacker News and various subreddits about things that interest me. I’d like to be able to do the same with rigging.

Sharing tools

I don’t know about you, but I always get excited about people sharing their tools. Granted most of the time it’s things that pretty much everyone writes for themselves and they often have horrible interfaces, so I rarely if ever use those tools, but even just seeing them is inspiring. The fact that there are so many people out there working on these things and sharing them is kind of cool.

That being said occasionally there are things that are just insanely cool like the Cosmos launcher or ngSkinTools.

My hopes are that if we have a place where people share their tools, we have a place where we can always look for references when building our own ones and hopefully inspiration. I would really like to see more cool tools and I feel like talk.bindpose.com can help!

Additionally, if you are trying to sell your tools, it would be handy to have a place where you know riggers hang out. And if your tool is any good, people will be happy that you posted it.

Conclusion

All in all, I think if we have all that, it will inevitably lead to us improving as riggers, while having fun hanging out with like-minded people!

So head over to talk.bindpose.com to become a part of that place!

Again, thanks to all who supported this!

Firstly, I want to thank everyone who signed up for talk.bindpose.com. I know in today’s internet everyone seems to be trying to get your email and I myself am always very aware of subscribing to anything, so it is much appreciated!

Since I posted the page the other day, I have had about 30 people sign up, which is not an overwhelming number, but to me it says there will be at least 30 people to chat with and exchange ideas when I am stuck somewhere. Additionally, there will be at least 30 people to share and discuss cool rigging stuff with. When I put it this way, it feels like a lot! So, again, thank you!

That being said, any online community would need a bit more than that in order to be sustainable, as we are all too familiar with places that look dead and how unappealing that is. Unfortunately, that has been the fate of many good discussion boards, not only about rigging and computer graphics, but about anything really. Therefore, once the platform is live, we will need to make it grow a bit more in order for it to keep going.

If you have any tips and/or ideas on how best to maintain an online community for riggers like that and make sure it keeps going strong, please share them as comments here or hit me up on email or Twitter.

Additionally, if you have been a part of such online communities that have for one reason or another died, you might be able to point out some of the mistakes and I would be very interested in hearing those as well!

Roadmap

With the numbers out of the way, I want to share what I have in mind in terms of steps for creating the platform and kicking it off.

The way it is going to work is, as soon as I have a proper working solution (which should not be very far off) I am going to gather a bunch of people, from the ones who have subscribed, to give it a test and see if there is anything terribly broken. If that’s not the case then we are going to seed it with some initial information (questions, answers, sharing interesting resources, etc.) just so nobody other than me is faced with the big empty when they come for the first time.

That’s where I’ll need some help. I have some ideas about things I would like to have posted on the platform, but the point of the community is to have variety. So, I would really appreciate it if you have any ideas for specific rigging tips, questions, shares, etc. you would like to see and share them, so I can crack on and make sure we have a variety of content to start with.

Distant future

On top of sharing cool ideas and asking/answering questions, I have a few other notions for features that a platform like ours should have once it has been established.

Job board and freelance area

To begin with, I think it would be really handy if we have a job board and a freelance area. The reason for that is, again, similar to the whole reasoning about the platform. There are other huge places which try to do this, but I think the more narrowed down it is (rigging only) the better. That way, we can rate the jobs and make sure riggers do not have to settle for neither bad employers nor terrible rates, as of course, that affects all of us. I would imagine it would be really easy for companies to find people this way as well.

Workplace information

While we are on the job topic, it might be cool to share information about people’s workplaces. Since our industry is very fast paced and often people have shorter contracts, it would be amazing to be able to read about the work environment at all those other potential places you could work at through a rigger’s perspective.

Rigging challenges

Additionally, I think it would be so much fun if we do some rigging challenges. One of my teammates for my final university projectZeno Pelgrims – started a really cool online place for lookdev challenges – shaders.xyz and it looks amazing! Wouldn’t it be nice to set up a similar rigging challenge, where we all have to rig the same asset and then we all share our processes? It seems to me, this would be the ultimate way for learning from each other.

I am sure that for every one of these ideas, you guys probably have 10 more and I am looking forward to talking with you about them once the platform is live!

Conclusion

For the time being, while I am working on the website, I will be taking time off writing here, as unfortunately, there is only so much spare time. I think it will be well worth it, though!

Once again, I’d like to thank everyone who signed up! If you haven’t done it already, please reconsider it – talk.bindpose.com.

tl;dr: After chatting with a few people about it, I have decided to start an online place just for riggers to communicate with each other easily. Head over to talk.bindpose.com to show your support for the idea by subscribing.

The why

A couple of weeks ago I asked riggers on Twitter where do they go when they have rigging questions, as I was struggling with something that I could not find information about and was wondering how do other people tackle that. I have to say I wasn’t very satisfied by the replies as I hoped there is a place online where riggers hang out a lot and you can easily ask and pick their brain (think StackOverflow for rigging).

People there suggested Twitter, Google and some forums, which are all great, but the main issue I have with these is that that they are obviously not rigging specific, so it is very easy for good and useful information to get lost among all the noise. Another big issue is that some of them are so distracting that it would be a shame to have to open them up when you are actually focused on working.

As a guy who grew up in the times where there was an active discussion board or forum for everything, I find the lack of good and consistent source of information and communication about rigging disappointing.

That same week, in my newsletter I asked whether people would be interested in an online place, dedicated to rigging, where they can ask, learn and share stuff. I had quite a few riggers positively respond, so I decided I will crack on with it and create that place.

The how

As I mentioned above I was hoping there was a StackOverflow-esque place with elements of Reddit and Hacker News in there, but obviously, all about rigging. Now since, all of these are immense platforms, when I say similar to them, I mean similar in the effect of making it easy for people to communicate about a topic they are passionate about. That is what I am aiming for. Additionally, you will find that the design I have in mind is almost 100% based on these three websites, just because I find them incredibly easy and straightforward to use, which I do every day.

I have been working on the platform since then and I am feeling very positive about it, as just looking at it, I can imagine how helpful it will be to me and hopefully to other people interested in rigging.

The when

Even though I have some minor web development experience, and I have dabbled with it through the years, I am by no means an expert, so everything I do I double and triple check to make sure I do it right. On the other hand, I do not want to spend too much time on building this initial version as I have no idea if people would even find it useful. The fact that I am so eager to see it live, also makes me speed up the process a bit more, so I have already made a fair amount of progress.

With all that in mind, I decided I will roll out a landing page where people can actually subscribe, so I can see if there is as much value in something like this as I had thought and make sure that what I am building is going to be useful.

The where

For now I have decided I will host the website here on bindpose, until it grows a bit, so I can use the great rigging minds on the internet to actually come up with a proper good name for it, as I am sure you all know, that is the hardest bit of creating anything.

So, head over to talk.bindpose.com to subscribe to the list if you would like to see an online place for riggers come to life.

When it comes to rigging in a production or many productions the name of the game is reusability and automation. In that sense rigging is very similar to traditional software development, as we also have to build systems that are easily maintainable, extensible and reusable. There are a few ways to achieve that in rigging and today I am going to look at some of them. The reason I wanted to write this is that rigging systems are one of the big things I wished I had learned earlier.

Disclaimer: This post will probably come out very opinionated and those opinions are going to be based on my own experience, which really, is not that extensive. Additionally, even though there are going to be informative bits, I am writing this more of a way to share my thoughts instead of trying to teach anything as again, I am not really qualified in any way to do that.

Also, please bear in mind that the larger portion of this post is going to be very speculative since I am talking about tools that I have not really used myself.

A rigging system

I just want to briefly go over what I mean by rigging systems. Essentially, everything that takes a model and produces a rig out of it is a rigging system to me. That means if you just rig an entire thing manually you are the rigging system. If you use a tool similar to maya’s HumanIK that is your rigging system. That means that any system that by following a set of instructions can on it’s own produce a rig is a rigging system. Other than just building actual node networks, rigging systems should provide easy ways to save and load a bunch of properties and settings such as deformer weights, blendshapes, control shapes, etc.

Rigging system types

With the definition out of the way we can have a look at the types of rigging systems out there.

Auto rigging tool

Disclaimer: This is going to be the most speculative portion of this post, as I have never used one of these solutions, other just having a brief look at them.

The auto rigging tool is a rigging system which takes care of everything we talked above by providing you with some sort of a guiding system to define the proportions and often the type of a rig (biped, quadruped, wings, .etc) and then using these guides, it builds node networks which become rig components.

Some examples of auto rigging tools are maya’s HumanIk which I mentioned above and also a popular non-Autodesk one is Rapid Rig.

There are a lot of them online and also they are usually a big part of rigging showreels as it seems that every rigger who starts learning scripting, goes for an auto rigging solution at some point. Including me.

Now, the problem that I have with this kind of rigging systems is the lack of extensibility. I have not seen an auto rigging tool with any sort of an API so far. That means that, for every rig you built you have only a limited number of available components (that number might be a large one but still limited). What I mean by that, there is probably only one arm component available and even though there might be many options on how to build that arm, there is a chance you are not going to find what you are looking for and would like to insert your own logic somewhere in that component, but there is no way to do that.

Mentioning the many options brings me to the next issue I see with auto rigging tools – performance and clutter. The way I see it, the more options you want to support inside of just one single component, the more clutter you would introduce in the logic of that component, in order to accommodate those options. Additionally, if everything is happening behind the scenes, I have no other way of knowing what the tool creates than just opening the node editor and having a look at the networks, which as you could imagine is not going to be fun on large rigs. That opaqueness scares me, as I would not know about potential node clutter introduced in my scene.

That brings me to my next point about auto rigging tools, which is the fact that everything is stored baked down in the scene. What I mean by that is, the auto rigging tool might give you some options for rebuilding parts of the rig after they have been created, but ultimately everything we store is baked into node networks. Yes we can save our weights and maybe some properties outside of the scene file, but these would be things that go on top of the auto rig product. There is no way to store how we actually constructed that rig. Then if I need to change the position/orientation of a joint, how do I go about that? What if, god forbid, the proportions of the model have changed? Do I delete everything and rebuild it? And if I have to do that, what happens with the parts of the rig that I have added on top of the auto rig, do I need to manually rebuild them as well?

The last thing I want to mention about auto rigging tools is UI. I mean, it is usually bloody horrible. I think it is probably all down to the native UI tools that maya gives us, which all feel very clunky. They just don’t seem to work for anything as complex as a rigging system. All of the auto rigging tools I have seen make an extensive use of tightly packed buttons, checkboxes and text fields in loads of collapsible sections or tabs, which just doesn’t seem to cut it in 2017. Again, I think the main issue there is that Maya’s native tools are just not enough to build anything more intuitive. That being said, PySide has been available for a while.

Maya Human IK rigging system UI

So, if you are going to be building an auto rigging tool, please keep in mind the following ideas can improve your work with that rigging system a lot

  • creating some sort of an API for easily extending/modifying the functionality of the tool, mainly by creating new or editing existing components
  • storing information about the actual building of the rig instead of just the baked down version of it, in order to enable you to easily rebuild it when changes need to happen
  • create a more intuitive UI than what is already out there. Node graph maybe?

Rigging framework

Going beyond auto rigging tools, we have rigging frameworks. Those are systems which do not necessarily have any high levels components such as arms/legs/spines built into them, but instead they provide you with the tools to create such components and save them for later use. The only system of this type that I know of is mGear. Incidentally, it does actually provide a high level modular system called Shifter that does give you everything that an auto rigging tool would. The good thing here, though, is that using the actual framework you can build your own modular rigging system and extend and modify it a lot.

Now, since I have never actually used it take everything I say with a grain of salt, but from what I understand, similarly, to an auto rigging tool you would build everything in the viewport and then save it as a baked down version. I do not know how easy or difficult rebuilding components is, but if anything has been built on top of them it would have to be also manually rebuilt.

What I really like about mGear, though, is the open source aspect of it. The fact that you can grab it and build out of it a rigging system that would suit your needs perfectly, is amazing.

Guidable modules

Now, this one I think is the only system that you can create yourself without any scripting. Even though, it might be a bit slower to work with, I think in terms of results you would be able to get everything you get out of an auto rigging tool.

So, what I mean by guidable modules is, say, storing a rigged IK chain with all the controls on it in a file and then when you need an IK chain in a rig you bring the one from the file. The rigged IK chain would have some sort of guides (usually just locators) that would be able to reposition the joints and stretch the chain without actually introducing any values on your controls and also the stretch values would be recalculated so there is no actual stretch on the chain, but instead the modified version becomes the default state.

I know that sounds a bit weird and it probably won’t sit well with many of you, since referencing/importing files is often considered dirty because of all the stuff that gets carried across. That being said, if you clean up after yourself, that would not be an issue.

Additionally, if you are referencing the components in the scene, you can modify the components themselves and the changes would be carried across all of your rigs utilizing that component.

What is more, the same idea can easily be applied to a rigging framework or an auto rigging tool you built yourself, so it removes the issue which arises when changes need to be made.

Rigging framework with modular rigging system through an API

Now, the last rigging system I want to talk about is one that combines aspects of all previously mentioned ones, but in a way where extendability, maintainability and reusability are all taken care of. That comes at the expense of not having a UI, having rules and conventions and requiring a thorough programming knowledge.

The way an user interacts with this rigging system is entirely through an API. The way the rigs are stored is in actual building information rather than a baked down version, which means that every time you open the rig it is built on the spot, making changes incredibly easy and non-destructive. And the way the components are created is through an actual Python class, benefiting from all the benefits (and unfortunately negatives) of object oriented programming.

So, the rigging process with this sort of a system is going to be writing code. Of course, we still need to paint weights and store control shapes, but these are easily saved and loaded back in. Here is an example of what a rig might look like in this system.

loadModel()
loadGuides()

initializeRiggingStructure() # Creates the boilerplate for a rig - top/god node, etc.

spine = bodyCommands.spine(spineChain)
arm = bodyCommands.arm(armChain, spine.end)

... ## Build all the components you would want

loadWeights()
loadControlShapes()

The loadGuides() function refers to a file which contains all our guides, similar to the previous rigging system. In this one, though, it is up to you what sort of guides you use. For example, for an arm you would just draw out your arm chain and the module will take it from there.

This is the rigging system that I like using. It feels much more intuitive to me as I do not feel any restrictions from anything, be that UI, pre-built components that I don’t have access to, etc. If I want a slightly different module I can just inherit from the old one and make my changes. If there is a model change I just need to reposition my guides and run my code.

The main downside of it is that it might get a while a new person to get used to such a system. Having a nice documentation and examples would help a lot. Another thing, people might feel uncertain about is the complete lack of UI, but again for me it is liberating to not be constrained by buttons, text field, etc.

Conclusion

I am very happy with the current rigging system I am using described in the previous section. That being said, though, I cannot help but think of things I would like to see in a rigging system.

For starters, let us go back at UI. Even though, I feel great about being able to do whatever I want with the code, having an UI for certain things would be much quicker. What ideally I would like to do is be able to have both working at the same time. Whatever I write needs to be reflected in the UI and, the harder bit, whatever I do in the UI I need to be reflected somewhere in my build file, so next time I build the rig it comes with the changes made from the UI as well. Having an UI modifying my code, though, does not sound amazing, so we need a different way of handling that, which could potentially be metadata. The one issue I have with relying too much on metadata is that it is not immediately obvious what is going on.

Another thing I would really like to see at some point is some sort of a rigging system standard where riggers around the world can exchange components and general bits from the rigs with each other. To be honest, though, I am both excited and worried about something like this, as introducing a standard might significantly hinder innovation.

The big thing that lies in the future, though, is getting a higher level of interactiveness while rigging. Complex builds using the rigging system from the last section can take minutes to build, which means that for every single change I make in the guides file or the build I will need to wait a lot to actually see the result. That is making the process a lot more obscure, when you just need to keep changing stuff in order to hit the right values. Imagine, though, that we have all that building happening in real-time. Say I have the guides opened in one window, the build file in my text editor and I have the product in another window. Ideally, what I would like is by moving something in my guides file, to trigger a rebuild of that “dirtied” portion of the build which would result in the changes applied in my third window without actually deforming my model.

I am saying this lies in the future, though, aspects of it are already taken care by the guidable components method described above. That being said, that full level of interactiveness is what I would ideally like to achieve.

As I said in the beginning, a lot of these are just my own speculations, which means that I am still trying to figure most of this out. That is why, I would love to hear your tips, opinions and ideas on rigging systems, so please do share them!

If you have been reading bindpose for a while and have seen my marking menu posts you probably know that I am very keen on getting my workflow as optimized as possible. I am a big fan of handy shelfs, marking menus, hotkeys, custom widgets, etc. The way I see it, the closer and easier our tools are to access the quicker we can push the rig through. That is why today we are having a look at using PySide to install a global hotkey in Maya (one that would work in all windows and panels) in a way where we do not break any of the existing functionality of that hotkey (hopefully).

If you have not used PySide before, do not worry, our interaction with it will be brief and pretty straightforward. I myself am very new to it. That being said, I think it is a great library to learn and much nicer and more flexible than the native maya UI toolset.

Disclaimer: The way I do this is very hacky and dirty and I am sure there must be a nicer way of doing this, so if you have suggestions please do let me know, so I can add it both to my workflow and to this post.

What we want to achieve

So, essentially, all I want to do here is install a global hotkey (PySide calls them shortcuts) on the CTRL + H combination that would work in all Maya’s windows and panels as you would expect it to – Hide selected, but if we are inside the Script editor it would clear the history.

Some of you might think that we can easily do this without PySide, just using maya’s hotkeys, but the tricky bit comes in from the fact that maya’s hotkeys are not functioning when your last click was inside the Script editor’s text field or history field. That means, that only if you click somewhere on the frames of the Script editor would that hotkey get triggered, which obviously is not nice at all.

Achieving it

So, let us have a look at the full code first and then we will break it apart.

from functools import partial
from maya import OpenMayaUI as omui, cmds as mc

try:
    from PySide2.QtCore import *
    from PySide2.QtGui import *
    from PySide2.QtWidgets import *
    from shiboken2 import wrapInstance
except ImportError:
    from PySide.QtCore import *
    from PySide.QtGui import *
    from shiboken import wrapInstance


def _getMainMayaWindow():
    mayaMainWindowPtr = omui.MQtUtil.mainWindow()
    mayaMainWindow = wrapInstance(long(mayaMainWindowPtr), QWidget)
    return mayaMainWindow


def shortcutActivated(shortcut):
    if "scriptEditor" in mc.getPanel(wf=1):
        mc.scriptEditorInfo(clearHistory=1)
    else:
        shortcut.setEnabled(0)
        e = QKeyEvent(QEvent.KeyPress, Qt.Key_H, Qt.CTRL)
        QCoreApplication.postEvent(_getMainMayaWindow(), e)
        mc.evalDeferred(partial(shortcut.setEnabled, 1))


def initShortcut():
    shortcut = QShortcut(QKeySequence(Qt.CTRL + Qt.Key_H), _getMainMayaWindow())
    shortcut.setContext(Qt.ApplicationShortcut)
    shortcut.activated.connect(partial(shortcutActivated, shortcut))

initShortcut()

Okay, let us go through it bit by bit.

Imports

We start with a simple import of partial which is used to create a callable reference to a function including arguments. Then from maya we the usual cmds, but also OpenMayaUI which we use to get a PySide reference to maya’s window.

Then the PySide import might look a bit confusing with that try and except block, but the only reason it is there is because between maya 2016 and maya 2017 they switched PySide versions, and the imports had to change as well. So, what we do is we try to import from PySide2 (Maya 2017) and if it cannot be found we do the imports from PySide (Maya 2016).

Getting Maya’s main window

Even though, Maya’s UI is built entirely by Qt (PySide is a wrapper around Qt), the native elements are not usable with PySide functions. In order to be able to interact with these native bits we need to find a PySide reference to them. In the example for hotkeys we need only the main window, but depending on what you are trying to do you might have to iterate through children in order to find the UI element you are looking for. Therefore this _getMainMayaWindow function has become a boilerplate code and I always copy and paste it together with the imports.

The way it works is, using Maya’s API we get a pointer to the memory address where Maya’s main window is stored in memory. That’s the omui.MQtUtil.mainWindow() function. Then what we do is, using that pointer and the wrapInstance function we create a PySide QWidget instance of our window. That means that we can run any QWidget functions on Maya’s main window. In our hotkey example, though, we only need it to bind the hotkey to it.

The logic of the hotkey

The shortcutActivated function is the one that is going to get called every time we press the hotkey. It takes a QShortcut object as an argument, but we will not worry about it just yet. All we need to know is that this object is what calls our shortcutActivated function.

It is worth mentioning that this function is going to get called without giving Maya a chance to handle the event itself. So, that means that if we have nothing inside this function, pressing CTRL + H will do nothing. Therefore, we need to make sure we implement whatever functionality we want inside of this function.

So, having a look at the if statement, you can see that we are just checking if the current panel with focus – mc.getPanel(wf=1) – is the Script editor. That will return True if we have last clicked either on the frames of the Script editor windows or anywhere inside of it.

Then, obviously, if that is the case we just clear the Script editor history.

If it returns False, though, it means that we are outside of the Script editor so we need to let Maya handle the key combination as there might be something bound to it (In the case of CTRL+H we have the hiding functionality which we want to maintain). So, let us pass it to Maya then.

As I said earlier, Maya does not get a chance to handle this hotkey at all, it is entirely handled by PySide’s shortcut. So in order to pass it back to Maya, what we do is we disable our shortcut and we simulate the key combination again, so Maya can do it’s thing. Once that is done, we re-enable our shortcut so it is ready for next time we press the key combination. That is what the following snippet does.

shortcut.setEnabled(0)
e = QKeyEvent(QEvent.KeyPress, Qt.Key_H, Qt.CTRL)
QCoreApplication.postEvent(_getMainMayaWindow(), e)
mc.evalDeferred(partial(shortcut.setEnabled, 1))

Notice we are using evalDeferred as we are updating a shortcut from within itself.

Binding the function to the hotkey

Now that we have all the functionality ready, we need to bind it all to the key combination of our choice – CTRL + H in our example. So, we create a new QShortcut instance, which receives a QKeySequence and parent QWidget as arguments. Essentially, we are saying we want this key combination to exist as a shortcut in this widget. The widget we are using is the main maya window we talked about earlier.

Then, we use the setContext method of the shortcut to extend it’s functionality across the whole application, using Qt.ApplicationShortcut as an argument. Now the shortcut is activated whenever we press the key combination while we have our focus in any of the maya windows.

Lastly, we just need to specify what we want to happen when the user has activated the shortcut. That is where we use the activated signal of the shortcut (more info on signals and slots) and we connect it to our own shortcutActivated function. Notice that we are using partial to create a callable version of our function with the shortcut itself passed in as an argument.

And that’s it!

Conclusion

Hotkeys, marking menus, shelves, custom widgets and everything else of the sort is always a great way to boost your workflow and be a bit more efficient. Spending some time to build them for yourself in a way where you can easily reproduce them in the next version of Maya or on your next machine is going to pay off in the long run.

I hope this post has shown you how you can override maya’s default hotkeys in some cases where it would be useful, while still maintaining the default functionality in the rest of the UI.

If you know of a nicer way of doing this, please do share it!

Today, I am going to share a really quick tip of achieving an uniform spacing along a curve.

Disclaimer: If you are not familiar with using the API, worry not, we are looking at a very simple example and I will try to explain everything, but it also might be a good idea to get some understanding of how it all functions. A good place to start is Chad Vernon’s Introduction to the API.

Very often in rigging we need to use curves. In quite a lot of these cases we need to get uniformly distributed positions along that curve. A simple example is creating controls along a curve. Chances are you would want them to be as uniformly distributed as possible, but in order to get that only using the parameter along the curve, you would need a perfectly uniform one that also matches the actual curvature. To get that you would need to do a lot of rebuilding, inserting knots and tweaking.

For another tip on rigging with curves have a look at my post about getting a stable end joint when working with IK splines.

I suppose that if you are doing it by hand then you can easily tweak the position along the curve and eyeball the distances between them to be roughly equal, but it sounds like too much hassle to me and also, more often than not, you would want to have that automated as I could imagine it being integral to a lot of rig components.

Let us have a look then!

The issue

So, I am sure everyone has run into the situation where they’ve wanted to create a few objects positioned uniformly along a nurbsCurve or a nurbsSurface, but they get this.

Getting an uniform space along a curve - example of non-uniform spacing on a nurbsSurface

Notice how larger the gap is between the joints on the left-hand side than on the right. The reason for that is that the distance between the isoparms is not equal throughout the surface, but the parameter difference is. What that means is, no matter how much we stretch and deform the surface, the parameter difference between the spans is always going to be the same – .25 in our example (1.0 / spansU).

Getting an uniform space along a curve - example of non-uniform spacing on a nurbsSurface with drawover

That discrepancy between the parameter space and the 3D space is what causes these non-uniform positions.

Getting uniform positions along a curve

So now that we know that, we can figure out that the way to get a reliable position is to find a relationship between the 3D space and the parameter space. That is where the API’s MFnNurbsCurve comes handy.

The 3D space information that we are going to be using is the length of the curve, as we know that is an accurate representation of distance along the curve. If you have a look at the available methods in the MFnNurbsCurve class, you will find the following one findParamFromLength. Given a distance along the curve this function will give us a parameter.

Example

Let us consider the following curve.

Getting an uniform spacing along a curve - example curve with non-uniform CVs

Let us position some joints along the curve using distances only based on the parameter.

for i in range(11):
    pci = mc.createNode("pointOnCurveInfo")
    mc.connectAttr("curve1.worldSpace", pci + ".inputCurve")
    mc.setAttr(pci+".parameter", i * .1)
    jnt = mc.createNode("joint")
    mc.connectAttr(pci+".position",jnt+".t")

All we do here is iterate 11 times and create a joint on the curve at the position of parameter equal to iterator * step where the step is 1.0 / (numberOfJoints - 1), which is .1 in our example.

Getting an uniform spacing along a curve - Example of non-uniform spacing on a curve using just the parameter

As expected, the non-uniform distance between the CVs results in an also non-uniform spacing of the joints.

Let us try a different approach then. We will get a reference to an API instance of our curve, and using the above mentioned function we will get parameters based on actual distance along the curve, hence getting an uniform distribution.

from maya import OpenMaya as om

def getDagPath(node=None):
    sel = om.MSelectionList()
    sel.add(node)
    d = om.MDagPath()
    sel.getDagPath(0, d)
    return d

crvFn = om.MFnNurbsCurve(getDagPath("curveShape4"))

for i in range(11):
    parameter = crvFn.findParamFromLength(crvFn.length() * .1 * i)
    point = om.MPoint()
    crvFn.getPointAtParam(parameter, point)
    jnt = mc.createNode("joint")
    mc.xform(jnt,t=[point.x,point.y,point.z])

So, the getDagPath function takes a name of a node and returns an MDagPath instance of that node, which we need in order to create the MFnNurbsCurve instance. The MDagPath is used for many other things in the API, so it is always a good idea to have that getDagPath function somewhere where you can easily access it.

Notice we are passing the curve shape node, as if we are to use the curve4 transform we will not be able to create the MFnNurbsCurve instance.

Having that MFnNurbsCurve, we iterate 11 times and following the same logic for getting a position along the curve as before – iterator * step – we get the parameter at that position, using the findParamFromLength method.

Now that we know the parameter we could still use the pointOnCurveInfo as we did before, but considering we are already working in the API we might as well get all the data from there. So, using the getPointAtParam method we can get a world space position of the point on the curve at that parameter.

Notice however that we are first creating an MPoint and we are then passing it to the getPointAtParam function to populate it.

And here is the result.

Getting an uniform spacing along a curve - example of uniform spaced joints along a curve using the mfnNurbsCurve from the Maya API

Using the same approach to get uniform positions on a surface

So, all that nurbsCurve business is great, but how can we apply the same logic to a nurbsSurface. Unfortunately, the MFnNurbsSurface does not have any method resembling the findParamFromLength one, but luckily we can always create a curve from a surface.

So in order to get uniform spacing along a nurbsSurface what I usually would do is create a nurbsCurve from that surface using the curveFromSurfaceIso node and using the described method find the accurate parameters and use those on the surface itself.

While writing this I realized that maybe the same approach can be used to actually get an uniform representation of the surface by getting curves from the surface and using them calculating the new, uniformly spaced CVs of the surface. Seems like we might loose a lot of the curvature of the surface, but it also seems promising, so I will definitely look into it.

Conclusion

Using curves and surfaces is something that I did not do a lot of in the beginning of my rigging path, but obviously they are such an integral part of rigging, that it is very important to be able to work with them in a reliable and predictable fashion. Thus, this tip has helped me a lot when building bits of my rigging system and I really hope you find it valuable in your work as well.

Additionally, I would like to reiterate who powerful of a tool the API is and I would definitely suggest anyone who is not really familiar with it to take the plunge and start learning it by using it. The major benefits are not only functional ones (like the one described in this post), but also performance ones, as the API is incredibly faster that anything to do with maya.cmds.

So, painting skin weights. It is a major part of our rigging lives and sadly one of the few bits, together with joint positioning, that we cannot yet automate, though in the long run machine learning will probably get us 99% there. Untill then though, I thought I would share some of my tips for painting skin weights with maya’s native tools, since whenever I would learn one of these I felt stupid for not finding it out earlier as, more often than not, it was just so simple.

I am sure a lot of you are familiar with these, but even if you learn just a single new idea about them today, it might boost your workflow quite a bit. Additionally, I know that a lot of you are probably using ngSkinTools and literally everyone I know who works with it says they cannot imagine going back. So I am sure that some of the things I am going to mention are probably already taken care of ngSkinTools, but if you, like me, have not had the chance to adopt it yet, you might find these helpful.

I am going to list these in no particular order, but here is a table of contents.

Contents

  1. Simplifying geometries with thickness and copying the weights
  2. Using simple proxy geometry to achieve very smooth weights interpolation quickly
  3. Duplicate the geometry to get maya default bind on different parts
  4. Copy and paste vertex weights
  5. Use Post as normalization method when smoothing
  6. Move skinned joints tool
  7. Reveal selected joint in the influence list
  8. Some handy hotkeys
  9. Average weights
  10. Copy and paste multiple vertex weights with search and replace
  11. Print weights

So with that out of the way, let us get on with it.

Simplifying geometries with thickness and copying the weights

This one comes in very handy when we are dealing with complex double-sided geometries (ones that have thickness). The issue with them is that when you are painting one side, the other one is left unaffected, so as soon as an influence object transforms the two sides intersect like crazy. That is often the case with clothes and wearables in general.

The really easy way to get around this is to
1. Make a copy of the geometry
2. Remove the thickness from it (when having a good topology it is as simple as selecting the row of faces which creates the thickness and deleting it together with one side of the geo)
3. Paint the weights on that one
4. Copy the weights back to the original geometry

Painting skin weights tips - Using a one sided proxy geometry when working with thickness

Now, a really cool thing that I had not thought of untill recently is that even if I have started painting some weights on the double sided geometry to begin with I can also maintain them, by copying the weights from the original one to the simplified one before painting it, so I have a working base.

That means, that if I have managed to paint some weights on a double sided geometry that kind of work, but the two sides are not behaving 1 to 1, I can create a simplified geo, copy the weights from the original one to the simplified and then copy them back to get the 1 to 1 behaviour I am looking for.

Using simple proxy geometry to achieve very smooth weights interpolation quickly

This one is very similar to the first one, but I use it all the time and not only on double-sided geometries.

Very often there are geometries that have some sort of a detail modeled in them that make it hard for weight painting smooth weights around it.

Consider the following example. Let us suppose that we need this geometry to be able to stretch smoothly when using the .translateX of the end joint.

Tips for painting skin weights in maya - Using a simple geometry to copy weights to models which are hard to smooth weights for.

Doesn’t look great with default skinning, but also if I try to block in some weights and smooth them, it is likely that maya won’t be able to interpolate them nicely. To go around it, I’d create a simple plane with no subdivisions so I can have a very nice smooth interpolation from one edge to the other.

Tips for painting skin weights - Using a simple plane without subdivisions to achieve a smooth weights interpolation for copying to complex geometries.

Copying this back to the initial geometry gives us this.

Tips for painting skin weights - Smooth skinned complex geometry using weights from a simple plane.

Very handy for mechanical bits that have some detail in them and also need to be stretched (happens very often in cartoon animation).

Duplicate the geometry to get maya default bind on different parts

So, very often I have to paint the weights on a part of a geometry to a bunch of new joints while I still need to maintain the existing weights on the rest of it. More often than not, I would be satisfied with maya’s default weights after a bind, but obviously if I do that it will obliterate my existing weights.

What I do in such cases is make a copy of the geometry and smooth bind it to only the new joints. Then I select the vertices on the original geometry that comprise the part I want the new influences in and I use the Copy skin weights from the duplicated one to the selected vertices. If the part is actually separated from the rest of the geometry that should do it, but if it s a more of an organic shape, there is going to be some blending of the new weights with the ones surrounding them.

I could imagine, though, that having the ability to have layers and masks on your skin weights would make this one trivial.

Copy and paste vertex weights

I am guilty of writing my own version of this tool just out of the ignorance of not knowing that this exists. Basically what you can do is select a vertex, use the Copy vertex weights then select another one (or more than one) and use the Paste vertex weights command to paste them. Works cross-geometries as well.

A cool thing about the tool that I wrote to do this is I added a search and replace feature that would apply the weights to the renamed joints. For example if I am copying a vert from the left arm and I want to paste it on the right I would add “L_” to “R_” to my replacement flags.

Use Post as normalization method when smoothing

So, I have met both people who love and who hate post. I think the main reason people dislike it is because they don’t feel comfortable with their weights being able to go above 1.0, but I have to say that sometimes it is very handy. Especially for smoothing. Everyone knows how unpredictable maya’s interactive smoothing is, and that’s understandable since in a lot of cases it is not immediately obvious where should the remaining weights go to.

Smoothing on post is 100% predictable which I think is the big benefit. The way it works is that it smooths out a joint’s influence by itself, without touching any of the other weights. That means that the weights are not normalized to 1.0, but instead of verts shooting off in oblivion post normalizes them for our preview. That is also why it is not recommended to leave skinClusters on Post as the weights are going to be normalized on deformation time which would be slower.

So more often than not my workflow for painting weights would be to block in some harsh rigid weights, then switch to Post and go through the influences one by one flooding them with the Smooth paint operation once or twice.

Move skinned joints tool

I am not sure which version of maya did this tool come in, but I learned of it very recently. Essentially you can select a piece of geo (or a joint) and run the Move skinned joints tool, then you can transform the joint however you like or you can also change the inputs going into it without affecting the geometry, though, you’d have to be careful to not change the tool or the selection as that would go out of the Move skinned joints tool. Ideally any other changes than just moving/rotating them about should be ready to be ran in the script editor.

I would not recommend using this for anything else than just testing out different pivot points. Doing it for actual positioning in the final skinCluster feels dirty to me.

Reveal selected joint in the Paint skin weights tool influence list

Only recently I found out what this button does.

Paint skin weights tool - reveal selected joint in influence list

It scrolls the list of influences to reveal the joint that we have selected, which is absolutely brilliant! Previously, I hated how when I need to get out of the Paint skin weights tool and then get back inside of it, the treeView is always scrolled to the top of the list. Considering that the last selection is maintained, pressing that button will always get you back to where you left off. Even better, echoing all commands gives us the following line of MEL that we can bind to a hotkey.

artSkinRevealSelected artAttrSkinPaintCtx;

Some handy hotkeys

I have learned about some of these way too late, which is a shame, but since then I’ve been using them constantly and the speed increase is immense. I hate navigating my mouse to the tool options just to change a setting or value.

  • CTRL + ALT + C – Copy vertex weights
  • CTRL + ALT + V – Paste vertex weights
  • N + LMB (drag) – Adjust the value you are painting with
  • U + LMB – Marking menu to change the current paint operation (Replace, Add, etc.)
  • ALT + F – Flood surfaces with current values

For more of these head on to the Hotkey editor, then in the Edit hotkeys for combobox go for Other items and open up the Artisan dropdown.

From here on I have added some of the functionalities that I have written for myself, but sadly the code is very messy to be shared. Luckily, it is not hard at all to write your own (and it will probably be much better than mine), but if you are interested, do let me know and I can clean it up and share it at some point.

Average weights

This one I use a lot. What it does is, it goes through a selection of verts and calculates the average weights for all influences and then goes through the selection once more and applies that average calculated weight. Essentially, what this results in is a rigidly transforming collection of verts. Stupidly simple, but very useful when rigging mechanical bits, which should not deform. Also I have used it in the past on different types of tubings and ropes where there are bits (rings, leafs, etc.) that need to follow the main deformation but not deform themselves.

Copy and paste multiple vertex weights with search and replace

In addition to the above mentioned copy and paste vertex weights, I have written a simple function that copies a bunch of vertex weights and then pastes them to the same vertex IDs on a new mesh. It is not very often that we have geometries that are copies of each other, but if we do this tool saves me a lot of time, because I can then just skin one of them, copy the weights for all verts and then paste them to the other geometry using the Search and Replace to adjust for the new influences.

Comes in particularly handy for radially positioned geometries where mirroring will not help us a lot.

Print weights

Quite often I’d like to debug why something is deforming incorrectly, but scrolling through the different influences can get tedious especially if you have a lot of them. So I wrote a small function that finds the weights on the selected vertex and prints them to me.

This is the kind of output I get from it.

#####################################
joint2 : 0.635011218122
joint1 : 0.364988781878
#####################################

As I said, there is a lot of room for improvement. It works only on a single vert at the moment, but I could imagine it being really cool to see multiple ones in a printed table similar to what you would get in the component editor.

What would be even cooler would to use PySide to print them next to your mouse pointer.

Conclusion

Considering that we spend such a big chunk of our time on painting weights we should do our best to be as efficient and effective as possible. That is the reason I wanted to share these, as they have helped me improve my workflow immensely and I hope you would find some value in them as well.

IK splines are a big part of a rigger’s toolset. They come in super handy for anything that needs to behave similarly to a rope. Funnily enough, that behaviour is often desired in many parts of the body and is also often preferable to a ribbon, mainly because ribbon’s stretch is not always desirable. Examples include spines, soft limbs, tentacles, some cases with lips and eyebrows, etc. Additionally, IK splines are a necessity in prop rigging, so we definitely need to have a stable way of setting them up. That is why today I am looking at a quick tip on going around the issue where the end joint does not sit at the end of the spline when stretched or deformed a bit more extremely.

The issue

If you have ever used a spline IK you have probably noticed an annoying stability issue at the end of the chain. Basically, when the chain is stretched or deformed a lot, our joints become longer and it is harder for them to assume the proper positions and rotations along the spline in order to follow it correctly. Effectively, as we stretch the spline it is almost as if the joint chain becomes with lower resolution than needed.

Here’s an example of the issue. Notice how the end joint has trouble sitting at the end of the chain.

IK splines - end joint issue

Depending on the amount of joints in the chain this issue will be less or more pronounced. Since I very often have two layers of control on spline setups where the lower resolution one drives the higher one so the animators have a lot more control than a single one, I also need to provide the fix for both layers. So, let us have a look at it.

The setup

Depending on the way the spline is driven you will have to adapt the setup, but I think it will be fairly straight-forward how to do that.

Essentially, all we do is we create another joint chain with just 2 joints, where the base is rooted at the end of the spline (essentially driven by whatever drives the end of the spline) and it aims at the second to last joint of the chain. Effectively, giving us this.

IK splines - end joint issue fix

Stretching

You’ll notice that I haven’t added any stretch to that aimed joint. I have found that most of the time I really do not need it. It seems to me that in order for that to become an issue, the chain needs to be stretched quite a bit, which is not very often the case. If you know, though, that your spline IK setup would be stretched a lot, it might be a good idea to plug the distance between the end point of the spline and the second to last joint of the chain into the translateX of the tip of the aimed joint chain.

Up vector

Depending on the result you would like to see from the setup you have a few different choices for the up vector of the aimConstraint. If you want it to behave exactly like the rest of the chain behaves, you can use the up axis of the last joint in the chain to be the up vector. I would usually suggest going that way, as then however you decide to twist the chain the additional joint will always be following that. Other options may include, the joint we are aiming at, the base of the chain (if we do not want any twist) or whatever drives the end of the chain, so we get the full twist out of it.

Additional potential issue

If you have another look at any of the GIFs above you’ll notice that at a certain pose of the CV, not only the last joint is flying off, but also the second to last one goes past the end of the spline. That is caused by the exact same issue I mentioned above. Our fix will not behave amazingly when this happens as the aimed joint will have to pop in order to aim at the opposite direction.

To be honest, similarly to the stretching bit I mentioned above, I haven’t had issues with this mainly because the chains are rarely stretched or deformed that much. That being said, there is a potential solution, which seems quite heavy, but I suppose if the functionality is needed the cost is irrelevant.

What you would do to completely go around this issue is having a second spline IK chain with the exact same joint chain but in reverse. You would also need to use a reverseCurve before the ikHandle, as well. Essentially, we are duplicating the setup but in reverse, so the problematic area is not only the end of the initial chain but it is also covered by the base of the new one and we know that the base of the IK spline behaves correctly. Therefore, all we need to do after that is paint the weights using both joint chains and smoothly blend them somewhere in the middle.

I have to say that I have never actually used this setup, but I have only tested it out, so if you manage to get it to work or not I would be happy to hear about it.

Conclusion

I really like how in rigging there is almost always a solution and coming up with these solutions is always so much fun. By no means is this fix bulletproof, but most of the time it would do the job. I hope it helps you with building your own spline IK setups, since they are just so useful.

I was so amazed the first time I learned about the script node. Now that I look at it, I feel like it is a necessity, for sure, but back before I had no idea that they, callbacks and scriptJobs existed, I often thought that it would be amazing to have a way of running code at different points of interaction with rigs (and any other maya scene). So when I finally learned about them, naturally, I tried to think of cool things I could do with them as, and today I will have a brief look at some of these alleged cool use cases and some not really cool ones.

Disclaimer: Raffaele over at the Cult of rig has some great videos that go over callbacks, script nodes and a great explanation of how they fit in the overall maya event loop. Once I saw those videos everything started making much more sense, when working with callbacks and script nodes, so I cannot recommend them enough. He goes over the use of script nodes to manage callbacks and I will not be going over that, so definitely have a look at his latest videos.

Additionally, this post will be mostly speculative since a lot of these ideas are just that – ideas that I have not yet tried, but sound like they might be cool.

Also, there are a few examples of unethical behaviour mentioned as potential uses of the script node, so I want to make it clear that I DO NOT encourage them, but instead I want people to be familiar with them, in order to be able to protect themselves.

Table of contents

script nodes in rigging

When I think about script nodes I instantly picture animators opening/referencing scenes and cool stuff happening without them having to touch anything, and yeah, I suppose that is probably the major use case scenario. I wouldn’t imagine myself needing a script node in my files, since I can easily run the code I want to run whenever I want to.

Rigging systems

That being said, though, say we have a rigging system, where we script most of the rig, but we still do certain things in the viewport as well, quite possibly through some cool custom UI we’ve built. That UI will very likely rely on some metadata inside of the scene and probably some message connections between nodes. Wouldn’t it be nice if this UI auto-populates itself and pops up ready to be directly used, without you having to touch anything? Sure, you can probably do that with just pressing a single button after the scene is opened, but I think having it happen automatically feels cooler.

Additionally, I know a lot of people have debug modes of their rigs, which take care of what I am about to say, but if you don’t it might be nice to have a script node remove the restrictions you have added for animators and turn on any diagnostics you have in the scene.

Analytics

Recently, I have been looking into running some minor analytics on rigs and I have to say I see why every marketing person out there praises analytics. It is an eye-opening experience seeing how many unitConversion nodes you have in the scene and maybe plotting that against the performance results you are getting to see if they are slowing you down (they probably are) and by how much (probably not much).

Again, this one is going to be purely speculative, but maybe we can gather some data on our own practices when rigging. Say for example, query the time spent working on a specific rig or maybe even run performance tests on opening or closing the file in debug mode and store that data over time.

script nodes in animation

So, even though, there might be some use cases for script nodes in rigging, I think they can be really useful for automating boring stuff for animators. Whether it is going to be related to building and loading certain UIs, creating certain connections between assets or similarly to the previous paragraph – analytics – we can use the script node to make animator’s and our work slightly easier, more intuitive and informative.

Attaching props

This is probably the best use case of the script node that I know of. I know different places and teams definitely have different approaches to this issue, whether it may be custom tools that are used to bring in and attach props or, god forbid, having all props in a character rig file and using switches to turn them on and off, it is a common aspect of pipelines. I think a nice solution are script nodes. Let’s imagine the following case.

Say we have a character that needs to have all kinds of different weapons, clothes and other wearable props. Let’s suppose all these are their own separate assets, so maintaining them is easier and nicer. The way script nodes would help us in this case is by executing a piece of code that would attach our prop to our character on bringing that prop in a scene where the character exists. That would be a nice and simple solution. Of course, it could lead to some issues, for example, having animators bring the prop in before the character or maybe have multiple instances of the character, so our prop does not know to which it should attach, but generally these issues are either solved or prevented by having some pipeline rules.

Building interfaces

This one is probably more appropriate for freelancers, free rigs and cases where the people working on a project don’t necessarily share a pipeline.

Animators often have to do a lot of animation in a short time. Anything we can do to help them out is going to be great for our production. A nice way we can do that is by giving them easy to use interfaces to speed up their workflow. I know a lot of animators use pickers, so maybe we can use script nodes to build them with all their jazz on the spot. Additionally, they might be like me and love marking menus. Wouldn’t it be great to be able to build it for them on the spot and maybe even show them a message, so they know how to bring it up? Then of course, clean up after ourselves when they close the scene, so we do not mess about with their other work.

script nodes in pipeline

Now even though script nodes can be quite handy for rigging and animation, I think where they really shine is in pipeline. Granted, pipeline would probably use scriptJobs to do most of the things I am going to mention, maybe small teams or even freelancers can sort of simulate a pipeline by using script nodes.

Analytics

I talked about analyzing our behaviour when rigging, but I think it is much more practical to actually analyze the working files of animators and lighters, as the data in there will probably be a bit more interesting. For example, we can run performance tests on certain scenes when opening/closing them and then at the end of a production identify problematic areas, so we can potentially have a look at improving them.

Additionally, this one feels a bit unethical, but if we are upfront about it, it might be cool to store some data on how people interact with our rigs. Create some callbacks on nodes and attributes we are interested in, and have a look at how they are being used. Then when closing the file save that data somewhere we can have a look at it, or in any other way send it to ourselves. We might just find that 50% of the control we are adding to rigs is not actually being utilized.

Licensing

How can we prevent our files from being used by people we do not want to use them? I think “do not let them have our files in the first place” is the reasonable solution, but maybe we cannot entirely prevent that. In cases like that, we can add a level of protection by using script nodes.

Since we can fire a script on opening a scene file, that means that we have some room for licensing our rigs. Now, while I am not entirely sure what the best way for forbidding access to a rig would be, I have a couple of ideas.

Inform us

This first option is not necessarily forbidding anyone from using our rig, but we might be able to setup a way of informing us of unauthorized access to our rig. For example, we can check if the user is unauthorized by looking for a specific environment variable that members of our team would have, looking up maya’s license or maybe even the OS username. If we find that the user should not be using our file we can send the information to ourselves by using a simple HTTP request.

I know this can easily be bypassed, but chances are it might just work in certain cases.

Obviously, this involves an amount of tracking users, which I really DO NOT encourage, but I could imagine certain people in certain cases might want to do that.

Break the rig

If the file is being opened as opposed to referenced we have the ability to break connections, delete files, etc. If that is the case we can easily destroy our rig on opening it, so people cannot even see it.

If it is being referenced though, we do not have that level of control. In cases like this it might be worth having an obscure way of breaking your rig, built into the rig itself. I do not think this could ever be bulletproof, but I think it is certainly possible to make it way too annoying for anyone to mess with it. That being said, it is likely that doing that is going to introduce some overhead in your rigs, so it is not an entirely too graceful way of going about it.

Close or hang maya

I feel like I am getting silly here, but I think that for people that really do not want anyone touching their rigs, they can certainly do a maya.cmds.quit(f=1) in the script node and be done with it. Additionally, if you would like to be extra nasty, I suppose you could do something along the lines of

import maya.cmds as mc

while True:
    mc.warning("All work and no play makes Jack a dull boy!")

Alternatively, if you do not want to be nasty I think the nicest way of denying access would be to just unload or remove the reference, but you would need to have a stable way of finding the reference node. If you cannot do that, you could also do a mc.file(new=1, f=1) to pop out of the scene.

script nodes security

So, escalating from the previous section, I am sure you could imagine that if we could hang and crash maya we probably can do much worse things. Since we are able to run python, even though we have a smaller than the default amount of packages included with maya, we are able to actually execute code entirely unrelated to maya. You know, create/read folders and files, run native OS commands, etc. What if we create and read files from the user’s machine that we really shouldn’t be? Additionally, there are included libraries in Maya that are making it trivial to send data over the internet. You can see where I am going with this.

I do not want to carry on mentioning unethical schemes, but I do want to raise your awareness about the extent to which script nodes can be used. Essentially, everything that is available to the user running maya is available to the script node and therefore to the person that published that file. Which leads us to the next point.

Protection

Now, depending on your OS, the ways that we can protect ourselves from malicious vary, but there are a couple of concepts that we can apply to all of them.

Careful when downloading files

The easiest thing we can do is to not use any files created by other people. Depending on what you are doing in Maya that might be okay, but I for example, very often open popular rigs to see how have they done certain things and how can I improve on top of them.

If you like me do occasionally load up files from the web, there is another check you could do. Open the .ma file with a text editor and check if there are script nodes in there. Since text editors can have a hard time with larger files, you can always write a small python function to check that for you. If the file is a binary file, though, you are out of luck and there is no way to check what is inside of it other than opening it.

Permissions

The obvious one. If the user running maya does not have access to a certain directory, maya doesn’t and hence the script node doesn’t. Please DO NOT run maya as a super user or administrator as that would obviously give maya access to anything.

The practical way of doing it I would say is to create a specific user which is going to run Maya and give it permissions only under a specific directory where you would store all your Maya work. That way, everything else is out of reach.

Firewall

Limit Maya’s access to the internet. That can be a reasonable solution, but Autodesk probably wouldn’t be happy with it, as that way you cannot sign into your Autodesk account.

Conclusion

As you can see script nodes can be really powerful in terms of use cases in a proper production or freelancing and also powerful in malicious ways. I like to believe, though, that people in CG are generally quite intelligent and nice, so therefore I can safely say I am not troubled by the potential exploits.

Rigging clothes of not very high res cartoon characters can get very tricky as with a lot of the designs intersections are inevitable. It can get very frustrating for animators to fix issues like that, and the easier we can make it for them the better. Today, I am going to have a quick look at a setup that can help with fixing small intersections, but can also be used to achieve a variety of effects. It is a nice simple tool that maya provides us – the softMod deformer – but they have not necessarily provided us with a great interface to interact with it, so we will have a look at a way to make it work a bit nicer for us.

Maya softMod deformer - demo

Essentially, what we have is a couple of controls, where one of them defines the origin of the deformation and the other one is actually deforming the geometry. The nice thing is that by placing the deformer after the skinCluster in the chain we can have the controls follow any of our rig controls, in order to be able to easily pick them up and deform our geo in world space.

tl;dr: You can connect your own matrices to the softMod deformer’s softModXforms attribute, in order to have your own controls driving the softMod deformation in world space after the skinCluster.

Figuring it out

When I was trying to figure out what matrices I need to plug to which attributes, I was having a hard time making sense of the available documentation on the subject. I found a few people online making use of the preBindMatrix attribute, but I could not get that to work properly, so naturally, I thought screw it, I am going to write my own softMod out of frustration.

After a couple of minutes of setting up the boilerplate code I was up and running, and it was a really simple effect that I needed, so the code was quite straightforward. I was having issues with the deformation not being accurate in world space though, so I had to account for that, which meant I would multiply by the worldInverseMatrix of the origin object I am using, then deform by the local matrix of the deforming object and finally multiply by the worldMatrix of the origin object in order to bring it back to world.

Doing that after having a look at making it work with the vanilla Maya softMod, though, made me think that I have seen similarly named matrices in the deformer attributes. Namely, the children of the compound softModXformspreMatrix, weightedMatrix and postMatrix. Connecting the proper matrices to these attributes, gave me the result I was looking for.

The reason I am saying this, is because I wanted to point out that is really helpful sometimes to just try and write your own node/deformer/plugin/script in order to understand what Maya is doing and why. I did this exact same thing when trying to figure out how to account for joint orientation in my matrix constraint post.

The actual softMod deformer setup

With that out of the way let us have a look at the graph.

Maya softMod deformer - node graph

So essentially, by making use of the softModXforms we are building exactly what I mentioned in the previous chapter, where we account for the world positioning of our deformer controls, by bringing back the deformation to local space, deforming our object and then placing it back in it’s world position.

Of course, these locators are there just so I can have a nice and simple example. In reality, the way this would work is that these locators would probably be replaced by two controls – one controlling the origin of the deformation and the other actually deforming the object. Additionally, exposing the falloffRadius attribute of the softMod deformer somewhere on these controls would be a good idea as well.

A nice benefit of having our own controls driving the softMod is that we can get rid of the softModHandle since it won’t be doing anything, which would result in a cleaner scene.

Using the tool in production

Now, I could imagine a couple of approaches for using this setup. The first one would be to build these into your rigs before passing them to the animators. Depending on the geometry, though, this could easily be an overkill if they are not used in every shot. If that is the case, the better approach would be to build some sort of an UI for the animators to create these into their scenes.

Additionally, while looking for info on this setup, I stumbled upon a few people having a riveted object be the origin control, so essentially achieving something similar to the infamous tweaker dorito setup.

Conclusion

Even though, the softMod is a very simple deformer, in cartoony productions I could imagine it being very handy for fixing intersections and giving the animators control over finer deformations.