Tuesday, November 08, 2011

Creating non-renderable "implicit" spheres, cones, cubes

Not sure how I didn't know about these until recently. The names sound so passive-aggressive. . .

createNode implicitSphere -n "name";
createNode implicitBox -n "name";
createNode implicitCone -n "name";

Each of these commands basically creates a non-renderable object (sphere, cube, cone) that has a very basic shape node (no components) and a transform node. You can still go into the shape node and change color using the drawing overrides and all. Doubt I'll be using them all the time or anything, but cool to know they are there if ever you should need them. 

Note on "distanceBetween" nodes . . .

A kind fellow named Maarten sent me an email asking about the distanceBetween node when using objects that have frozen transformations. More specifically, that it didn't work correctly after freezing the tranforms. Absolutely correct and I should have mentioned it in the video.
Basically once you freeze transforms on an object you sort of "reset" the matrix that the object lives in. As far as Maya is concerned internally, these objects now all live at 0, 0, 0, despite the fact that their pivots might be any old place.

Since I don't know much (read: anything) about matrix math, I'm not sure exactly what the technical description of what is happening is, but you're probably familiar with the results. If you're not, try this: create a cube, rotate, scale and translate it. Then freeze tranforms on it. Now look at the manipulator handles for the rotates (in local mode) and the tranforms (in object mode). Not only have the values in the channel bar been reset to 0's and 1's, but the object no longer has any idea of it's own orientation relative to the world. So any values relative to anything else in your scene are gone, thus things like distanceBetween (and loads of other stuff) don't really work any more. There are a bunch of little tricks you can use (sometimes) to pull out some information about the object, but things like world space position and orientation are kind of messed up. You won't run into this with things like joints very much, as you're probably not freezing them, but depending on how you're doing things elsewhere, this could be something to be aware of.

Some notes about this:
a) This is yet ANOTHER reason why it's smarter to "group freeze" or "group orient" your controls or anything else that you care about the position/orientation. By grouping an object at the origin on creation and then moving the group, not the object, you avoid the need to freeze transforms on anything.
b) When you're modeling for rigs, you DO want the freeze the tranforms (usually) but it's probably better to wait until you're pretty well finished with the model, THEN clean it up (freeze, delete history, etc). Most of these objects will end up being controlled by other things (joints, etc) anyways, but it's nice to have older versions of the file that have the orientations, etc (even better if you use groups here too, but let's not get too fussy)
c) in the ordinary course of events it's, of course, totally fine to use the standard measure distance tool, with it's UI component and locators and all. When you actually want to see the values, it's actually easier to use this method because of the visual feedback it gives. I'm guessing that this freezing business is why these tools don't measure the objects directly, but instead use the locators.
d) if you have frozen objects (whose world space matrix has been messed up at some point) and you still want to use the cleaner method of the "distanceBetween" nodes, you can just create some null groups (one for each object) and point constrain them to the objects. Then you can either delete the constraints and parent the nulls under the objects, or leave the constraints and stash the nulls away somewhere in the outliner. Then you just hook up the nulls to the distanceBetween, just like you would any other objects. A bit cleaner visually than using locators, but you could use those too if you want.
Anyways, thanks to Maarten for pointing out the omission!