12 January, 2012

Mysterious "geometry" attribute and Geometry Constraint

Geometry constraint is a bit special because it does not connect its output to transform attributes of a constrained node allowing us to key them. Out of curiosity I looked at the connections in hyper graph and I see that output of the constraint node is connected to "geometry" attribute of the constrained node (any transform node). One would think that this attribute would have something to do with geometric data for display or deformation. However, the doc says "Geometry attribute used for positional constraints". Strange!

Here is an example of this connection used by geometry constraint:
locator1_geoConstraint.constraintGeometry -> locator1.geometry

We know following things about this "geometry" attribute based on the documentation:
  • It's a generic type attribute (it takes nurbsCurve, nurbsSurface, mesh etc. as input)
  • It affects translation attribute of a transform node (we can use it to control position)

Based on above information let's do some experiments and see what happens.
  • Create a nurbs sphere
  • Create a locator
  • Connect nurbsSphereShape1.worldSpace[0] -> locator1.geometry
And locator1sticks to the sphere! What happened here? My guess is that this particular attribute calculates/updates translation value based on given geometric data. Now, if you move the locator1 you will see another surprise, locator1 is constrained to the sphere! And this is working without a constraint! You can move the sphere around or change its shape and the locator1 will still be following it. So this is almost like a geometry constraint but without creating the constraint node. The only thing that would not work here is if you group the locator and move the group, i.e. if you move the parent of the locator. This is what is handled by geometry constraint and that's where attribute locator1.parentInverseMatrix comes into the picture. This attribute is used by the constraint to compensate for any transformation coming from parent hierarchy of locator1.

So this makes me think that "geometry" attribute was added when geometry constraint was added. Who knows!


  1. Hello Maulik , just a short explanation:

    The geometry constraint actually does pretty much no math computation it output just a nurbs or poly surface.

    From the documentation :
    geometryConstraint inherits from the constraint parent class which itself inherits from transform parent class


    a locator is transform with locator shape associated with it therefore it is prefectly natural that a locator as a geometry attribute:

    from the node documentation:
    geometry (g)
    Geometry attribute used for positional constraints.

    Think of this constraint as switch beetween several input geometries. it the transfom that does all the works.

    you can directly plug a shape node into your locator geometry it will still works...


    connectAttr -f polySurfaceShape1.worldMesh[0] locator1.geometry;

    Hope it helps

  2. Actually it's not just the locator, but any transform node. And transform node itself does not contain any shape data hence the attribute "geometry" sounds a bit strange. Same with a locator, it's just a transform node, independent of its shape. In my example you can use any transform node.

    Geometry constraint actually does not compute much, but it still have to do some computation to output a geometry based on parentInverseMatrix of the constrained node to stick it on the input geometry.

    As far as I understand geometry constraint's purpose is to stick transforms to the given geometry, not switch.
    Could you tell me what do you mean by "think of this constraint as switch..."?

  3. From the documentation:
    The geometryConstraint node simply provides on its output (constraintGeometry), the input with the largest targetWeight value.

    hence the switch term : from many input this node select only one as the driver.

    the parentInverseMatrix is used to convert this transform position coordinates if it is a child in a hierarchy its an important attribute. but it is not the constraint that stick transform on a surface : a transform has already this mechanism implemented in itself ,like many others like limit etc

    1. Ah I see what you mean now. Didn't read the documentation before.

      And that's exactly the point that made me wonder. If I say geometry constraint, for me it's constraint's job to calculate and stick the object on geometry. I don't understand that this mechanism is part of a transform node.

      Thanks for commenting. You have some really good stuff on your blog :) I read many posts a couple of months ago!

  4. Thanks for your kind words, What I like in maya is that the api reflects directly what we use everyday as a normal user. My guess about maya transform node is that its more efficient to process a default geometry constraint in the parent class which is responsible for handling all space related transformation.

    the MPxTransform is a bit tough to play with but exposes and enables us to modify or extend the default transform behavior. One time I wanted to add collision detection to a custom transform node but fail quite heavily to write a robust implementation. It was a good experience though.

  5. wow this is another cool stuff,
    really helpful for riggers because most of us hates history of obj and if one follow your tech, he/she would get no history and as geometryConstraint makes an node for itself, one would find history of it