While browsing the interwebs recently, I noticed that for $20, you can buy something called "universal uv randomization script" on creativecash. Seeing this made me realize I should give my scripts way cooler names from now on. So get in quick and grab a copy of djPFXUVs, while it's still free. Soon it will be simply called "XP€N$IV $H1T".
This time last year I started a new job at a new studio. For me, this was a big change since I had been at the previous studio (one that I helped build from almost nothing) more than 20 years.
My new job has given me the opportunity to learn several new applications and as a result I have found little time to update my blog and it has been very much neglected.
So to begin a new year of enthusiastic blogging, I've decided to write a (long, possibly boring) post about what I've been doing the last 12 months. It is just a quick rundown of changes affecting my general workflow. If you are still interested, keep reading (btw... the photo is my new puppy, Hollywood) (more...)
Last week I downloaded and installed the "Maya 2011 Subscription Advantage Pack". This is really just "Maya 2011 Service Pack 1" with a couple of extras thrown in to sweeten the deal for subscribers.
For some reason, so far unknown to me, the autodesk devs decided to distribute the subscription advantage pack as "2011.5" while continuing to call service pack 1 "2011". I'm pretty sure the code base for 2011.5 is the same as for 2011 - at least all the 3rd party plugins I've tried still load and behave correctly (and usually a version change requires a recompile of 3rd party plugins).
By default the subscription advantage pack gets installed to "C:\Program Files\Autodesk\Maya 2011 Subscription Advantage Pack". I know I could have redirected it to a more sensible and shorter path name, but I like to stick to defaults since they make some things more straight forward and less prone to human error (for example, deployment on a render farm).
The thing that really bothered me was the way my prefs folder would now have to be named "2011.5-x64". I know it's only a few extra characters, but it makes transporting prefs messy (for example, when I need to work on a system that does not have the SAP).
Ok, enough whinging. There's an easy solution. And it goes something like this. (more...)
A couple of months ago Ryan Brady posted a question on the CGTalk forum where he asked "What is your favourite mouse for maya?". This aroused my interest because I had been recently looking for something to replace my ancient 3 button logitech ball mouse.
I have used this well built piece of hardware ever since I migrated from my old SGI indigo2 to my first PC. After all those years in constant use it still works, but requires regular cleaning to keep it rolling smoothly and I have noticed it is starting to click. So now it is time to upgrade. (more...)
I'm going to start by saying that I do not consider myself and expert on this subject, but I'm going to write about how I have adapted my methods to deal with the "linear workflow" thing in my day-to-day work.
If you have never heard the term "linear workflow" then you must have been really busy doing something else for the past year, because it has been discussed over and over in forums and blogs. I've done a lot of reading and managed to confuse my thinking on numerous occasions, but lately it all seems to be falling into place and I feel like some kind of born again "linear workflow" convert. And like most new converts, I feel compelled to spread the word.
When I'm rigging a character in maya I generally use some kind of auto rigging system. My current preference is Hamish McKenzie's zoo toolbox (zooCST). This means that things pole vector constraints are created for me. Recently I was helping Jeremy rig something where the auto rigger just didnt seem appropriate. When we got to adding the pole vector constraints, Jeremy asked why we couldn't just put the control objects where we wanted them. He was getting frustrated because the joints would rotate when he added the constraint.
With zooCST I knew how to put a control object at the exact location that would not cause this rotation, but my collegue insisted that we should be able to just place the control object where we wanted, click a button and let maya figure out how to keep the joints in place.
After some searching I found a little mel script on highend3d called nilsNoFlipIK.mel (written by Nils Lerin). It lets you specify a vector and an ik handle and it calculates the twist value required to keep the joints from rotating. Since the ikHandle.twist can be calculated for a given vector, I just needed to figure out how to calculate that vector from the location of the control object.
The result is djBuildPoleVector.mel.
Select a control object and an ik handle and type djBuildPoleVector
A pole vector constraint is created, the ikHandle.twist attribute is set and there is no joint rotation.