Hi. I noticed when you're loading an alembic in Houdini, you can select to load only Deforming primitives or only Transforming primitives.

At the moment I write animation to USD as point caches (sopcreate > Import from SOPs > Primitive Definition > Other Primitives = Overlay), but this is really not optimal for non-deforming meshes, where you could get away with writing just an xform.
Unfortunately, leaving the geo as Packed Alembics and switching the dropdown to Overlay Transforms doesn't seem to work, and I couldn't find a way to transfer the intrinsic prim transforms to USD.

Anyone able to help with this one?
Thanks.

USD has a file format plugin for Alembic files, so you could try just loading the file directly in LOPs?

What LOP (node) should I use for that? SOPimport? Asking because SOPcreate is a wrapper around SOPimport, they have basically the same options.
The only thing I change in SOPs after loading the alembic is the path attribute with a wrangle, to match the path of the static asset the animation is meant to overwrite.

Use the file node inside lops.
You probably have to clear the filtype filter, it will only show usd files by default.

If you need to change location of the cache in the scene graph, use reference node instead.

Well, that wasn't what I was going for. That just brings in an alembic from disk. I don't want to keep using the abc, I want to "translate" its data into USD so that I can completely discard the abc file.
Again, a reference or a sublayer LOP are meant to bring in USD files. You cannot select which attributes you want to keep or discard, which ones should have time samples and which shouldn't, etc.

Let's say you have a human already written on disk as an USD. There is already a static mesh (the rest pose) with attributes like topology, P, N, uv -> st, material bindings, etc. inside the USD file.
Now, if you get an alembic with the very same human animated, all you need to write on disk from the abc file are P (the new point positions) and bounds. This will give you an "animation layer" that you can load over your "original asset" that only contains the necessary data to move your human from the rest pose.

While position caches are the solution for deforming geometry, for transforming geometry you could get away with just writing out transforms for each primitive, which is much faster and way more efficient.
So, yeah, that was my question. How can I take the data read from an abc file in SOPs and feed it to a SOPimport to just get xforms on non-deformable prims?

alexandru_p
So, yeah, that was my question. How can I take the data read from an abc file in SOPs and feed it to a SOPimport to just get xforms on non-deformable prims?

The sop import default value field can specify which attributes to only write default values for, there by not writing any time samples. You could list all of the sop attributes to write static meshes, leaving only xform as the animated attribute.

alexandru_p
Well, that wasn't what I was going for. That just brings in an alembic from disk. I don't want to keep using the abc, I want to "translate" its data into USD so that I can completely discard the abc file.

When you load an abc file into lops (via a sublayer or reference), it does convert to USD. In other words there's no native alembic support in lops, rather the abc conversion is handled behind the scenes by USD via a plugin. So once you've loaded your abc file into lops just save it out as a usd file. If you want to do that from the commandline you can run "usdcat -o myfile.usd myfile.abc". If the data in myfile.abc is spase the data in myfile.usd will also be sparse.

antc

alexandru_p
Well, that wasn't what I was going for. That just brings in an alembic from disk. I don't want to keep using the abc, I want to "translate" its data into USD so that I can completely discard the abc file.

When you load an abc file into lops (via a sublayer or reference), it does convert to USD. In other words there's no native alembic support in lops, rather the abc conversion is handled behind the scenes by USD via a plugin. So once you've loaded your abc file into lops just save it out as a usd file. If you want to do that from the commandline you can run "usdcat -o myfile.usd myfile.abc". If the data in myfile.abc is spase the data in myfile.usd will also be sparse.

the alembic plugin for usd is pretty broken though. I wouldn't use it if you have geometry with uvs or vertex colors.

jsmack
the alembic plugin for usd is pretty broken though. I wouldn't use it if you have geometry with uvs or vertex colors.

Ah good to know thanks jsmack.

antc
When you load an abc file into lops (via a sublayer or reference), it does convert to USD. In other words there's no native alembic support in lops, rather the abc conversion is handled behind the scenes by USD via a plugin. So once you've loaded your abc file into lops just save it out as a usd file. If you want to do that from the commandline you can run "usdcat -o myfile.usd myfile.abc". If the data in myfile.abc is spase the data in myfile.usd will also be sparse.

Yeah, but that is still limiting. As I said, depending on the origin of the incoming alembic, you might need to edit the path attribute to fit your needs (and when I say that I don't just mean just grafting it somewhere, I mean custom logic to alter the inside hierarchy).
I'll keep trying to fiddle around with the sopimport, like jsmack suggested. Last time I tried to do that, it would just do nothing (not move the geometry at all), but maybe I was missing something.

Just keeping the Alembics packed and selecting P, bounds and transforms in the sopimport does the trick. Thanks again for the suggestions, everyone!