So many things about Houdini can trip you up, then eat your face off while you’re down. Today’s example is the VEX dot operator. I haven’t ridden the VEX horse into battle in a very, very long time, and like any horse, if you’re not paying attention, it’ll do what it wants, not what you want.
I’m a visual person. I see stuff and make choices based on that. So what I see in Houdini’s Geometry Spreadsheet are columns with headers like this:
P[x] P[y] P[z] direction direction  distance
P is a vector with 3 components. Any time you have a vector attribute in Houdini with 3 components, it shows up in the Geometry Spreadsheet like above.
Not so with ‘direction.’ Direction is a vector2 , but the Geometry Spreadsheet displays it the same way it displays a float array, or a vector4, or any other multi-component attribute. ‘Distance’ is a single floating point attribute, so there’s no subscript or component there. What got me is that the column header in the Geometry Spreadsheet has no correlation to VEX syntax.
If you’re using VEX expressions, say, in wrangle nodes or shaders, getting at those components requires the dot operator, just google VEX and Dot Operator, and you should be good, but here’s a code snippet explaining the gotcha I hit this morning.
@P.x = 1001; //this is fine, accessing an intrinsic vector component @direction.u = 1001; //Error, because 'direction' is not a vector2. firstname.lastname@example.org = 1001; //no effect, because 'direction' is a vector2. email@example.com = 1001; //Subscript error, because while vector2's are accessed via .u and .v, VEX is still treating this one as a vector. u@direction = 1001; //Error, because attributes in VEX don't follow standard C-like array access syntax. firstname.lastname@example.org = 1001; //works, because 'direction' is now handled properly as a vector2 email@example.com = 1001; //works, because vector2's work with either x/y or u/v as subscripts.