So after playing around a bit more, I realised my problem was a little more specific. I'm struggling to publish a file sequence to usd, and then be able to read it back.
I'm currently reading in an alembic with the path:
$HIP/geo/abc/abc.$F4.abc
and exporting it as a usd. I've tried each of the styles, but none of them seem to keep the reference to the time dependency.
Is it possible to read in an alembic sequence like that and publish it to a single usd file? I've attached an example scene. I did manage to get this working with a vdb sequence which was strange.
I think you're going to have a hard time reading a sequence of alembics into usd.
You might be able to go through sops, where the alembic is unpacked before importing to LOPs before writing the animation as one usd file. Doing this would not keep any reference to the original alembic though.
Another option would be to sublayer the alembic to lops and write out a usd sequence with the usd rop set to flatten stage. Then use usd stitch clips to combine the usd file sequence into an animation.
I can't think of a way to retain the reference to the alembic sequence.
gnisbet Is it possible to read in an alembic sequence like that and publish it to a single usd file? I've attached an example scene. I did manage to get this working with a vdb sequence which was strange.
This is easy for a vdb sequence because vdbs don't get read in as usd. The vdb file path is just an animated attribute on a usd prim. no different than storing any other animated value. There isn't an equivalent for alembics since there is no 'alembic read prim' for usd.
As jsmack says, this isn't something that is natively supported by USD (unless you want to use value clips, which can be a bit finicky and complicated to get working). The simple option is to use a Geometry Sequence LOP which was created for exactly this sort of situation. It loads the geometry file (BGEO, Alembic, whatever) into SOPs, converts any packed primitives into the native SOP equivalent (polygons, curves), and imports that SOP geometry into LOPs. If your Alembic hierarchy is unchanging over time, you should be able to write the whole sequence of alembic data out to a single USD file by plugging the Geometry Sequence LOP right into a USD ROP.
If the Alembic hierarchy changes from frame to frame, writing out a single USD file will generate a scene graph that is the union of all the per-frame alembic hierarchies. This is just how USD works - the scene graph hierarchy cannot vary over time. But you could also use a USD ROP to write out a separate USD file per frame, in which case you will effectively be translating each Alembic file into a separate USD file.
Hey all, thanks for the help. We're currently stuck on 18.0, but looking forward to trying out those news nodes in 18.5.
So you can either write out the alembic sequence as a single usd file, or write out a sequence of usd files itself.
Would the more efficient workflow for heavy files (eg. an ocean) be to write out separate usd's to save it from pulling loads of data across the disks?
USD doesn't load data off disk until it needs it. A single file will be faster to compose than value clips, and easier to deal with from within USD. But obviously depending on the file size there may be other considerations (for example generating the file might be faster and easier if each frame is sent to a separate USD file, and updating individual frames may be faster and easier with individual files. Others with real production experience probably have more insightful things to say about the tradeoffs...
I can comment on one factor. In a very busy (highly loaded) studio environment, writing to multiple files gives you the option of writing those big files across multiple filers, which won't only benefit you but will benefit the entire facility. That said, doing this can be awkward both pipeline and IT infrastructure-wise.
jason_iversen writing to multiple files gives you the option of writing those big files across multiple filers, which won't only benefit you but will benefit the entire facility.
I guess that brings us back to the original question, how do you read them back as a sequence without stitching into single .usd? the main goal is to get interpolation for MB etc... I've seen hacks where each frame .usd is a micro sequence within shutter range, but that sounds like a workaround with potentially overlapping data
Yes, in the sense that there are restrictions on while parts can be animated... The metadata, relationships, etc of the value clips are ignored because they aren't allowed to change over time anyway. But the scene graph can contain anything. You just need to put all the on-time-varying stuff in a "template" file (which in the simplest case can just be the first file in the value clip sequence).
mtucker Yes, in the sense that there are restrictions on while parts can be animated... The metadata, relationships, etc of the value clips are ignored because they aren't allowed to change over time anyway. But the scene graph can contain anything. You just need to put all the on-time-varying stuff in a "template" file (which in the simplest case can just be the first file in the value clip sequence).
Can non-usd files be used in value clips, e.g. bgeo/abc?
jsmack Can non-usd files be used in value clips, e.g. bgeo/abc?
Yep. USD's file format plugin architecture means that USD can't even differentiate between USD and BGEO and Alembic files. They are all USD files, as far as composition is concerned.
