Howdy all, I've got some geo with name attributes on various parts, exported to alembic. If I bring the geo into Solaris it doesn't see the names. I have to go to /obj, unpack, and bring back in. Is there a way to unpack alembic directly in Solaris? Thanks!

SOP Import doesn't have much support for packed Alembic prims - since USD has a .abc file format plugin, you can directly load alembic files through the File LOP etc

Thanks. Here's what I'm seeing:

1. Alembic unpacked in SOPs shows the groups

2. Same alembic loaded via file node in LOPs, no groups

3. Unpacked alembic brought in from SOPs has the groups


Is that the only way to get the groups into LOPs or is there way to do it without the trip to SOPs? Maybe I set the groups up wrong to begin with? Thanks again!

In this case it looks like you're relying on SOP Import's ability to partition the geometry into different USD prims based on the SOP `name` attribute.
So in the second image that's directly loading the alembic file, I'd expect there to be a primvar on the mesh with the various 'name' values, since the .abc file format plugin would just be loading the alembic file as-is. If you're creating the alembic file with the Alembic ROP, you could set the "Partition Mode" parameter to "Use Attribute Value" (and set Partition Attribute to "name") - this should partition the mesh based on the name attribute

Ah great. Yes, I was using an Alembic ROP. Partition Mode is greyed out, but I'm getting the result I want using "Build Hierarchy From Attribute."

Not sure how you are getting this problem. But perhaps try and load it with a reference node instead. When set to "reference specific primitive" you could ctrl-click the arrow and browse the containing primitives.

Another option is to import it in a SOP-create node using the same node as in sops.

AndreasWeidman
Not sure how you are getting this problem. But perhaps try and load it with a reference node instead. When set to "reference specific primitive" you could ctrl-click the arrow and browse the containing primitives.

Another option is to import it in a SOP-create node using the same node as in sops.

Thanks. Somehow it seems to come down to what produced the Alembic. Default settings from the Houdini Alembic ROP saves it packed (I guess?) and Solaris doesn't see the various primitives. But, an Alembic saved from ZBrush of a scene with multiple models works just fine either via file or reference node.

I'm sure I'm missing something, but the default Houdini behavior isn't quite working for me. The defaults in Maya and ZBrush do...

BrianHanke
I'm sure I'm missing something, but the default Houdini behavior isn't quite working for me. The defaults in Maya and ZBrush do...

Houdini and zbrush and maya are working identically. The difference is in houdini you had one object that you expected to work like it was many objects. Fortunately, Houdini lets you do that using the 'build hierarchy from path' option. It's not on by default because it can't assume that the partion attribute exists or it will fail if it doesn't.

BrianHanke
Default settings from the Houdini Alembic ROP saves it packed (I

Has nothing to do with it. 'Packed' doesn't exist as a concept outside of Houdini sops geometry.

I get it now, just need to click that checkbox. Question: by default it looks for "path," but there is no "path" in the geo spreadsheet. Still works and separates the geo though. Why?

BrianHanke
I get it now, just need to click that checkbox. Question: by default it looks for "path," but there is no "path" in the geo spreadsheet. Still works and separates the geo though. Why?

Check the primitive tab of the geometry spreadsheet. It will error out if there is no path attribute.

Hmm, not following. Attached is a box, torus, sphere from Maya, cached to Alembic, brought into Houdini. It sees the separate objects but I don't see path and it's not listed in the spreadsheet. If I export from the ROP using default settings I get one geo. If I click hierarchy and leave it at path (even though not listed) it works.

Oh, you didn't say you were writing out alembic packed primitives as alembic. I think they pass through properly to allow for round-tripping. In that case the path attribute is probably redundant since the packed primitives have an intrinsic alembic path property.

It's strange your alembic prims don't have a path attribute but instead have groups. I guess when the file sop is used instead of the canonical alembic sop, you don't get any of the frills.