confectionary malfunction

this is your rig on sugarcubes

Archive for category math

new yaaaawk, baybee!

Apr 2

Posted by kiki in 3d, math, maya, programming | Comments off

Dimos and I headed out over the weekend to see Mike in New York. The title of this post is what Dimos screamed, cheerleader-on-prom-night-in-the-back-of-a-volkswagen style, every five minutes. Somehow it never got old.

There are amazing pictures taken by Mike of both Dimos and myself on Facebook; hopefully I’ll find some time this weekend to get the pics of my own camera and Flickrize them.

I might talk a bit more about the trip in a few days, but what I actually wanted to write is this:

To project a worldspace point into camera space, you need to multiply the camera’s view matrix by its projection matrix. The projection matrix is grabbable through the OpenMaya API (there’s a function for it on MFnCamera). The view matrix is simply the inverse of the worldspace transform matrix.

Needed to get that out of my head and into a place I wouldn’t lose it. If that makes no sense to you, just pretend it wasn’t there. 🙂

Katt's Mysterious 3D Lectures – Vector Application: A Better Rivet

Jun 20

Posted by kiki in 3d, math, maya, rigging | 8 Comments

You have the aim constraint under your belt. You can guess how a pole vector’s motion will change rotations with a look. You’re feeling a new sense of power and a desire to accomplish… things.

Now what?

Let’s start with something simple. Remember that old standby, the Rivet script, that I mentioned in my last post? Every good tutorial DVD I’ve bought over the years had it. Every rigger I’ve ever met uses it. As scripts go, it’s probably the most useful 2k on HighEnd3D.com.

But did you know it’s also broken?

Let me go back for a moment. A year ago, while I was working under a talented rigger who liked the Farenheit Digital system for creating nurbs ribbon rigs, was saddened by the fact that all licenses of Maya at our company were Maya Complete save two: his, and mine. This meant that the standard way of building ribbons, where you attach a Maya Hair follicle to the surface, wasn’t going to work as Maya Hair only comes with Unlimited. He mentioned something about using an aim constraint and a pointOnSurfaceNode or through the decomposeMatrix node to accomplish the same, although it didn’t work as well. So I was tasked with writing a python node plugin that accomplished the task. It worked well and quickly enough; 40 or so of them were live in the final rigs.

However I prefer to keep the number of non-standard nodes in rigs to a minimum. At my current place of work we realized a need for a follicle-like setup again, so I started researching.

At one point we’d thought we could solve the problem with the Rivet script. Rivet takes two edges, lofts them into a nurbs surface with history, then attaches to the surface a locator using a pointOnSurfaceInfo and an aim constraint. When the lofted surface is relatively square and doesn’t deform much, this works fine. When you try to use just the pointOnSurfaceInfo and aim constraint setup on a longer nurbs surface that deforms and bends, however, we found that the locators do not behave properly. Past a certain amount of twisting, the locators would rotate off in odd directions.

I played with the script and found that the pointOnSurfaceInfo node was feeding the surface normal into the aim constraint as the aim vector, with one of the tangent vectors as Up. Because of this, the aim constraint was causing the locator to flip. The way aim constraints work makes up vectors into suggestions, not rules. It also makes the third axis a product of the other two, as I showed in my last post.

In the end it was a simple fix: instead of using the surface normal (which wasn’t an illogical choice), I fed both surface tangents into the aim constraint and let the third axis, the normal, be the derived one. Since the tangent u and v vectors are always orthogonal regardless of how much you distort the surface, and since they always run in the right directions along the surface, you can be certain that the surface normal — a third orthogonal vector — will still end in the right place. (I bet the surface normal is derived from the cross product of the two tangent vectors anyway, internally.) No need for a custom node or to force the loading of decomposeMatrix; so far I haven’t seen any problems with this setup.

Steps for those who want to try this at home:

1) Create a pointOnSurfaceInfo node attached to your nurbs surface. Set it’s U and V parameters to get the output to the right place on your surface.

2) Use the createNode command to make an aimConstraint node.

3) Plug the pointOnSurfaceInfo’s tangentU into the aimConstraint’s target[0].targetTranslate, and the tangentV into the constraint’s up vector.

katt's mysterious 3D math lectures: how aim constraints work

May 22

Posted by kiki in 3d, math, rigging | 1 Comment

More often than one would think, I’ll come across a post on CGTalk or some similar forum where the following question:

“Hi, how do aim constraints work? I’d like to write my own.”

gets the reply:

“Thats stupid. Why would you want to do that? Just use the built-in aim constraint. It’s more efficient.”

I hate that reply. It’s generally true that the internal node or whatever that handles the aim constraint in your software *is*, in fact, much more efficient than rolling your own through scripting or API-level programming, but without knowing *how* the node works internally, without understanding *why* it behaves the way it does, you’ll only ever be able to use that constraint in a limited number of ways.

The examples in this post are going to focus specifically on Maya, but the thought process is the same regardless of your software package. You may not have the same level of control when modifying the aim constraint in your package, however. In that case, knowing how it works so you can build your own and extend upon the behavior that’s there becomes all the more important.

Anyway, on to how aim constraints work. I’ll be using “target” and “constrained” to refer to the two objects connected by the aim constraint.

The first thing that happens when you aim constrain one object to another is that constrained’s position is subtracted from target’s. This gives you a vector in the direction of target that passes through both target and constrained.

Why is this important?

Actually the vector is very important — it’s one of three that are needed to describe the orientation of an object in most 3D packages, due to the fact that matrices are used to hold object transforms. In a 4×4 matrix (where the upper-left corner is referred to as m00, and the bottom right is m33; a two-dimensional array of values), m00 – m02 represents the vector along which the object’s X axis lies. M10 – m12 and m20 – m22 are the Y and Z axes respectively. Each vector must sit at a 90 degree angle to the other two — must be orthogonal — just like their respective axes.

This first axis we’ve gotten can be plugged into one of the matrix axis spots to align the first axis on your object. So if you’re aiming the positive Y axis at target, the vector would go into m1. If you’re aiming the negative Y axis, you can either flip the vector you’ve gotten from the earlier subtraction or, if you’re smart, save the extra calculation and just subtract target from constrained instead.

Alright, one axis is constrained. How about the other two?

Next up is the pole. It’s just another direction vector, and the pole vector axis is snapped to it in the same manner that the first axis was set to aim at the target object. Pole vectors can be calculated in any number of ways: you could create a second vector through subtraction again, use a world vector (such as <0,0,1> for the world Z axis), or even just plug in the direction vector from another object’s matrix directly. Put the pole vector into the matrix for the axis that’s pole vector constrained and we’re halfway there.

Now, remember I said that the three axes in the matrix need to be at 90 degree angles to each other? I’m betting that if you draw out the two axes you’ve currently got plugged into your matrix, they’re not aligned. This is expected. If you create an aim-constrained object and target in a 3D scene right now and move the target around a bit, you’ll see that the pole vector axis will aim along the pole vector, but it won’t often snap to it. The pole vector is actually only there to get the third, unconstrained axis. If you do a cross product on the aim vector and the pole vector, the third angle you get will be at a 90 degree angle to them both. We’ll call this the “unconstrained” vector. This means that the first and final axes are finished. Afterwards, another cross product is done between the aim vector and the unconstrained vector to make sure the pole vector is orthogonal to the other two. While this makes the pole vector-constrained axis not always point exactly along the pole vector, you do have all three axes accounted for and the system is relatively stable. Pop the vectors into your matrix and voila — constrained aims at target.

As far as I know any aim constraint based on Euler angles works like this in most packages.

Now on to what’s interesting.

Take Maya, for example. For years I’ve been using the river script by Michael Bazhutki. In fact, I’m willing to bet there are few riggers out there who haven’t used it from time to time. However, until recently I hadn’t ever stopped to look at how his script works.

If you’ve never used rivet, it basically takes two edges or four vertices and lofts a nurbs surface between them, with construction history on. Then it snaps a locator to the center of that surface. The locator rotates perfectly with the surface even after joint and blendshape deformations, so it’s great for sticking buttons or other decorations to character meshes.

It turns out that the script’s main trick is using Maya’s aim constraint node in a neat way: he gets the surface normal from the nurbs surface at the position he wants through a pointOnSurfaceInfo node, uses it as the aim vector, then uses the same pointOnSurfaceInfo node to get the nurbs surface’s tangent vector at the same point and plugs that into the constraint’s aim vector slot. Since the constraint doesn’t care what vectors get plugged into it, and since a nurbs surface at any point can be evaluated to get three orthagonal axes (not unlike the X, Y, and Z axes), this works out great. It also keeps working regardless of how the mesh bends since all the construction history is kept, forcing updates down the line as a character deforms.

This is a trick I’ve used in the past few weeks on our current project at work, and it’s something I plan to expand upon in the coming months. It’s also something that’s gotten me thinking: just what else could I do if I, instead of using the constraint commands to constrain objects together, just created nodes in Maya and used the connections in ways the developers hadn’t envisioned?

But the better question is: how would someone even know to pull apart a set of node connections to a constraint if they didn’t know, roughly, how that constraint works?

I hope this helps someone. As soon as I have time, the next topic I want to write about is something I did with vectors over the weekend: replicating the smear effect from the Pigeon Impossible blog in Cinema 4D.