SOLVED






Let's say I've got an alembic exported from Maya with an integer array attribute.

When importing this alembic in Houdini, and checking the operator info panel, the array attribute isn't actually understood as an array, but instead as type Xint (where X is the number of indices in the array). In the geometry spreadsheet, each index of the array is in its own row:

testAttr | 5
testAttr | 2
testAttr | 11
…

What I would expect is a single array attribute, and for the operator info panel to show the attribute as type int. And to see something like this in the spreadsheet:

testAttr |


This is causing issues when trying to work with the array in a wrangle (VEX). VEX can't seem to understand this Xint attribute type. Trying to access it as you would with a normal array attribute:


Results in test2 being an empty array.

Trying this:


Always results in test2 being equal to 0.



Is this an alembic issue? Something to do with the way the attribute is created in Maya, or the Maya Alembic exporter itself? Or is it Houdini?

Is there some way to get Houdini to recognize these array attributes as real arrays?

My current workaround is to export from Maya with a string attribute, then in Houdini use an attrib wrangle to split the string and create a true array attribute, which I can then work with as usual further down my network. This seems like a pretty dirty hack and I am missing something or there is a better way.

Any ideas?

It looks like it's recognizing them as fixed length attributes, such as float16/9/4 for vectors and matrices, or int2 for index pairs. These are a bit of a pain to work with in vex, as arbitrary length ones, especially integers don't have bind type in vex. You can import them in vex, but not with a bound attribute. I think if you use getattribute() you can read them, then you could bind them out to a standard array type attribute.

That's a good idea, I should have thought of that.

It actually works just with the basic detail(), point(), prim(), and vertex() functions:


Glad it's such a simple solution. Thanks!

Ah, I hadn't considered those. They are probably wrappers for getattribute() anyways.