In solaris, when referencing/payloading an alembic file, the default uv set 'uv' comes in fine and is translated to primvars:st and is of typeName texCoord2f. This can be picked up by Vray or Karma. However, any other uv sets (such as utilityAnim) come through as primvars:utilityAnim:indices and primvars:utilityAnim:vals, are type float2, and are not respected by Vray or Karma.

Is there a reason that these come through that way? And is there a way to get these primvars respected as uv sets? Or convert them from float2 to texCoord2f?

I can put the Alembic in sops, drop a wrangle and do this: and then SOP Import into LOPs, but that's ghetto, and not how we load assets into LOPs at our studio.

Is there a way to do this in LOPs? I can't get a SOP Modify to even import all the attrs - when I dive inside, I just get a handful of usd attrs with the usual name, path, P, N, uv, and rest:vals, usdconfigconstantattribs - no matter what info I put on the SOP Modify, the other attribs like utilityAnim do not appear.

Hamilton Meathouse
However, any other uv sets (such as utilityAnim) come through as primvars:utilityAnim:indices and primvars:utilityAnim:vals, are type float2, and are not respected by Vray or Karma.

I'm not sure about Vray, but Karma and Houdini GL should be able to bind to them by name with no problem even if they are float2
are you using MtlX Geometry Property Value to read them in?

Hamilton Meathouse
Is there a way to do this in LOPs?

you can try doing this in Wrangle LOP pointing to your mesh primitive

Thanks Tomas - this does work in a Wrangle LOP and changes it to texCoord2f. However Karma doesn't respect tha new uvset.

I think it's because the primvars:utilityAnim comes in as primvars:utilityAnim:indices or primvars:utilityAnim:vals

This works to change the typeName but doesn't affect the render:

For reference, I'm changing the uvset with a uvcoords vop in the material network (setting the 'uv attribute' parm to utilityAnim:vals)

Hamilton Meathouse
Thanks Tomas - this does work in a Wrangle LOP and changes it to texCoord2f. However Karma doesn't respect tha new uvset.

I think it's because the primvars:utilityAnim comes in as primvars:utilityAnim:indices or primvars:utilityAnim:vals

This works to change the typeName but doesn't affect the render:

usd_setmetadata(0, @primpath + ".primvars:utilityAnim:vals", "typeName", "texCoord2f[]");

Yeah, I noticed that the alembic plugin for USD is broken with indexed array attributes. They get named incorrectly on import as 'name:vals' and 'name:indices' arrays instead of just 'name', 'name:indices'. I've been able to work around it by lofting the values to a new attribute with the correct naming, but this is prohibitively expensive to be a proper solution.

Could you share your workflow for lofting those values Jsmack? I'll take expensive as a workaround for the moment.

Hamilton Meathouse
Could you share your workflow for lofting those values Jsmack? I'll take expensive as a workaround for the moment.

I'm not able to recreate the problem now.

LOL, wow there's a lot broken here. I guess answer is, don't use alembics with USD.

I'm not seeing the 'vals' for indexed arrays in 19.5, I was having that in 18.5 and earlier versions. However, the 'indices' are still somehow invisible to karma, and the primvar doesn't work at all. I don't think the type has anything to do with it. changing the type to texCoord had no effect.

Curious, I tried an 'arbitrary' attribute rather than a texture coordinate exported in the alembic. This was even worse. Instead of the primvar coming in as an indexed array of vectors, the arbitrary tuple came in as a flat array, so the length was unusable as it didn't map to either points or vertices, and was lacking an index list. I'm guessing float3 and vector attributes can't be used from alembics at all, except for a single point color attribute and a single uv attribute.

I don't remember it being this dysfunctional before.

Hmmm balls. I'll see what shakes out with an obj.

In the meantime - is there a way to get a SOP Modify to actually pull in all the attributes? As stated above, when I dive inside I just get a handful of usd attrs with the usual name, path, P, N, uv, and rest:vals, usdconfigconstantattribs. Obviously when looking at the same thing in sops I can see all the uv attributes.

Does anyone know if the USD alembic plugin in Houdini developed by SideFX or Pixar?

I'm hoping to see this fixed at the source (rather than relying on workarounds), but I'm not sure who to talk to to get the ball rolling on that.

Can anyone from SideFX confirm whether this is an issue with USD itself, or the Solaris implementation of Alembic USD?

Almost everyone at SideFX is on vacation right now, and tracking this won't be a five minute activity, so further investigation will have to wait until the new year. I see a hip file in this thread, but no .abc files... If you can provide an Alembic that demonstrates your issue that will be very helpful, as well as any other hip files that show the approaches you have tried. Thanks!

If this is urgent, please submit an issue to support.

We are uploading a repro to the DD sidefx ftp, should be with you soon.

Scene file annotated with all possible examples using basic alembic assets and alt versions with an internal alembic asset. Outlined examples which do and don't work using the default uv attr as well as custom uv attributes, depending on whether they are referenced or SOP Imported. Have also shown how LOP-referenced alembics do not allow access to custom uv attrs in SOP Modify LOPs as well.

Package name is alembic_debug.tar

Houdini FX Version 19.0.657
Operating System: CentOS Linux release 7.7.1908 (Core)

I just submitted a support ticket to SideFX for this issue (on behalf of Hamilton Meathouse), and referenced this thread. I don't have a ticket number yet.

Thanks,
Steve

Hi there, any news on this? It appears to be as broken now as it ever was.
Currently facing terabytes of converting stuff...

Serg
Hi there, any news on this? It appears to be as broken now as it ever was.
Currently facing terabytes of converting stuff...

Has this issue been raised with Pixar? I'm guessing it's on them to fix it.