Crane Wars!

OK so I have been super busy lately, as evidenced by the frequency of posts since GDC. Sorry world! Touch KO is wrapping up in a matter of weeks, as is our new Blurst game, Crane Wars. Ben did a little walk through today to show the internets what we’ve been doing. Around 2:00 to 7:00 I show a face rig I did up Monday for one of the characters. It is entirely bone-based. Take a look!

Hip Constraint and Shoulder Constraint Update

Following in my pattern of frequent updates, I uploaded more revisions this morning to both the shoulder constraint and hip constraint.

The revision, which is the same in both, is another exception to handle a possible singularity. I never actually had it happen to me in practice, but I realized it was possible when I stopped to think about it. Enjoy!

Hip Constraint Release and Shoulder Constraint Update

This morning I finally finished the hip constraint! You can now download it here. Just like the shoulder constraint, it comes with MEL scripts designed to assist in setup.

Speaking of the shoulder constraint, I found some pretty egregious math errors in my shoulder constraint node, so I have uploaded another update to it. Not only does it actually work as intended now, the math is greatly simplified and more closely resembles what you need to do to port it into game code.

Enjoy, and please let me know if you have any problems while using it!

AM_ShoulderConstraint Update

I have been working the past couple evenings on another Maya plugin, a hip constraint. It is finished, but the setup tools are not yet ready for it, so expect it probably by this weekend! While working on, however, I discovered a couple bugs in my shoulder constraint node, so I have uploaded an updated version of that (1.1). The update is not a big deal and the chances of it affecting anyone are very slim, but I did primarily two things.

First, I now cast the incoming enum for rotateOrder as short instead of as int, as there is a known problem in Maya Python accepting pointers to integer as reference to enums. For whatever reason it did not appear to cause a problem in my plugin, but I would rather be safe than sorry.

Second, I slightly adjusted the math for building the final quaternion. Though I never actually saw a problem with it, there was the possibility of building a weird rotation if the shoulder’s pretransformed up vector was exactly 180 degrees from the world-space target up vector (i.e. there are infinite different possible quaternions to build the rotation from one to the other). The problem can still happen only if the pretransformed up vector is exactly 180 degrees from the world-space target up vector and the shoulder’s transformed (world-space) up vector is exactly 180 degrees from the target up vector. Because the chances of this happening in a human range of motion are infinitely small, and the chances of this configuration of vectors is infinitely small, I didn’t bother to devise a more elegant solution. However, please do let me know if any of you have a different suggestion of how to address it!