Publishing an alembic file sequence to usd

   1114   13   1
User Avatar
Member
10 posts
Joined: Aug. 2011
Offline
Hey all,

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.

Cheers,
Gary
Edited by gnisbet - Feb. 17, 2021 10:58:54

Attachments:
lop_test_v01.hip (294.2 KB)

User Avatar
Member
4103 posts
Joined: Sept. 2011
Offline
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.
User Avatar
Member
4103 posts
Joined: Sept. 2011
Offline
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.
User Avatar
Staff
3837 posts
Joined: July 2005
Offline
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.
User Avatar
Member
10 posts
Joined: Aug. 2011
Offline
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?
User Avatar
Staff
3837 posts
Joined: July 2005
Offline
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...
User Avatar
Member
10470 posts
Joined: July 2005
Online
Hi,

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, pipeline technology supervisor @ weta digital
also, http://www.odforce.net [www.odforce.net]
User Avatar
Member
10 posts
Joined: Aug. 2011
Offline
Thanks for the heads up everyone. I've had it before where trying to move large files across disk can be a real headache.

So this seems like it's definitely worth investigating for sure. Thanks!
User Avatar
Member
5135 posts
Joined: July 2007
Online
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
Tomas Slancik
FX Supervisor
Method Studios, NY
User Avatar
Staff
3837 posts
Joined: July 2005
Offline
The only way in native USD to load a sequence of files to provide per-frame opinions is value clips.
Edited by mtucker - Feb. 23, 2021 01:20:21
User Avatar
Member
5135 posts
Joined: July 2007
Online
mtucker
The only way in native USD to load a sequence of files to provide per-frame opinions is value clips.
I was reading about those, but it will take some time to sink in
after I read this:
https://graphics.pixar.com/usd/docs/api/_usd__page__value_clips.html
"...All metadata, relationships, and default values present in a layer are ignored when the layer is consumed as a Value Clip..."
I got impression that there are certain restrictions on what can be stitched into value clip
Edited by tamte - Feb. 23, 2021 01:27:40
Tomas Slancik
FX Supervisor
Method Studios, NY
User Avatar
Staff
3837 posts
Joined: July 2005
Offline
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).
User Avatar
Member
4103 posts
Joined: Sept. 2011
Offline
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?
User Avatar
Staff
3837 posts
Joined: July 2005
Offline
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.
  • Quick Links