Almost a year and a half ago, I wrote a little prototype tool called eRig, which was designed to be a generic rigging tool for non-technical artists who just needed something to animate with.
I think it’s time for an update post. I finished WPI back in December, and I’ve since been working away as a Technical Lead over at Dejobaan Games (where I previously interned and contracted).
A friend using eRig on some characters recently asked about scaling characters after they’ve been rigged with the tool. I left scaling out to discourage students from doing it, since some game engines don’t play nice with scaled joints.
In other news, I got my picture in a New York Times article. I’m just glad I didn’t have to wear the mocap suit, because I’m not sure I would want *that* picture in the newspaper.
Last year at WPI, I did decided to do an independent study (an ISP) that somehow related to tech-art. The program at WPI teach pretty much zero rigging skills, and yet expects students to rig and animate characters for their games. As you can imagine, this causes some problems for a lot of projects. In my position as a student representative to the faculty, I’ve tried to push the idea of working basic rigging into the curriculum, but I hadn’t made much progress at that point (and I’m still fighting the good fight a year later). I decided that I should focus my ISP on creating a simple rigging tool that even the most non-technical artist could use to create basic, game friendly rigs for their characters. To that end, I created eRig over the course of my 7 week project. It’s nothing fancy, just a quick and dirty tool that was friendly to the non-technical student who needed a rig. It turned out to be pretty successful, and recently found out that students are using it frequently and professors are recommending it to projects.
Yet, the number one comment I heard from other students has been “this is cool, but can you teach me to do it myself?”
So when a space opened this term for me to do another ISP, I decided I would try to find a way to get WPI students (and anyone else) a good resource on basic rigging for games. Now, I’m the first person to tell you that I’m no expert on rigging. But while I don’t know all the advanced techniques, I do know how to make a clean rig that has good flexibility and can be baked down to a simple skeleton for use in games. So with that in mind, I’ve set off to create this resource for the next 7-ish weeks and see what I come up with.
I considered the traditional methods: a pdf tutorial, a series of videos, etc. The problem with these is that they stick to one rigid format, not taking advantage of more interesting and useful methods of presenting information that are available in 2011. Beyond just the format, a straight tutorial tends to go one of two ways;
- It can assume the user knows certain things and just skip them – this is no good for me because some people have no idea what a constraint is or even how parenting and hierarchies work
- It can stop at each new concept and go off on a tangent – this is no good because someone who knows the concept has to either slog through it, or skip haphazardly through the tutorial
So again, a static text or a video both have issues. Thinking about it, I thought it might be nice if I could do something similar to a textbook, placing ‘sidebars’ along the text that explain supplementary items while leaving the main tutorial clean. This idea eventually led me to trying to use a wiki for the project. I can have a combination of text and video (and other things I haven’t thought of) on one page; at the same time, I can have “want to know more?” links when important concepts are first introduced, leading the reader to another page that helps them understand whatever it is.
There’s obviously a lot more that can be done in this area, and I remember seeing some really interesting things at a 3D Stimulus Day a couple years ago on interactive textbooks. Seven weeks isn’t a lot of time though, so I’m going to see how far a wiki can take me and then try to evaluate the pros and cons of the approach. I will post more updates on this project here as it starts to take shape too.
But for now I need to get back to mucking about in Linux system calls.
As a graduation requirement, WPI students must complete a Humanities and Arts capstone practicum. For mine, I chose to create a short film with 3 other students based on the children’s book called Strega Nona. This project took place over one 7-week term, with most of the work in the last 4 weeks. The video can be seen below. Overall I think it came out well, though there are certainly places it can be tightened up, and we intend on doing so in the coming weeks.
I was responsible for creation of the female model, rigging, shading, rendering, scene/reference management, and compositing.
I just released a quick update to eRig. This version fixes issues with the IK creation, and solves the problem of the twist attribute on IK chains not always working correctly.
Read more about eRig or download the new version here.
Maya likes to save the last known location of its windows when you close the program. This is nice because they re-open where you expect them later. However, when Autodesk switched Maya over to QT for Maya 2011, they forgot to put in checks about how big the screen is. So, if you connect a second monitor to your laptop and drag the script editor onto it, when you take the laptop elsewhere without the extra monitor and try to open the script editor, it is stuck offscreen where you can’t access it.
Over at the C4 Engine forums, someone was having trouble with a rigged character and I offered to take a look. Eventually, they asked how they might go about having a violin that the character could take off of her back and hold in her hands. I made the following video to help illustrate how one can animate parent constraints to do just that. It’s a pretty rough example, but I thought it might help others trying to do the same sort of thing:
Of course, you’d want to put some sort of controller on top of all that. And you might not want to be moving the locators. Maybe have some group node constrained to the locators for parenting, then a controller under that for local transformations so you don’t need to align the locators each time, then constrain the violin to that controller as normal.
Over the past couple years, various people have told me to start a professional blog on my site about the projects I’m working on. So, I figured, why not? Better this than post pictures to Facebook occasionally, right?
To explain the title of the blog: somewhere in the planning stages of Blinding Silence, we were discussing what sound looks like. Someone mentioned imaginary colors, I suggested the square root of negative red as an example, and thus a math joke was born.