I am using a Volume LOP with default parameters except for the File Path to load VDBs, and then a USD ROP to output a simple USD file. The ROP has all its parameters set to default except for the frame range and the output path.
When I click the Save To Disk button, it takes several seconds per frame and the whole things takes 20 minutes to export.

Why?

The viewport does not need to refresh, the data itself does not need to be loaded. What does Houdini need to load from the VDB files that takes so long? When I replace the Fields parameter value with the list of fields that are in the files, it takes just as long.

Thanks

F

I am not sure if I understand, but you have vdb and want it to save as usd, then it has to load each frame. I dont know why you said, that it does not have to load.

Have you tried setting it to Sample Frame Range mode, to see if that does any better? Are there upstream/downstream nodes that are time dependent, so they're causing a lot of unnecessary re-cooking?

Ah! Setting it to Sample Frame Range mode makes it go very fast. Thank you! That's the part I was missing.
There is no other nodes than those two.

flord
Ah! Setting it to Sample Frame Range mode makes it go very fast. Thank you! That's the part I was missing.
There is no other nodes than those two.

In the latest version of Houdini, I haven't been able to find this setting on the USD ROP node. Has it been renamed?

AnsonSavage

flord
Ah! Setting it to Sample Frame Range mode makes it go very fast. Thank you! That's the part I was missing.
There is no other nodes than those two.

In the latest version of Houdini, I haven't been able to find this setting on the USD ROP node. Has it been renamed?

It would be on the Volume LOP, or any node that you want to sample a frame range.

jsmack
It would be on the Volume LOP, or any node that you want to sample a frame range.

Fascinating, it reduced ROP output time from 9 minutes down to less than a second. Why does this work? I was reading through the documentation [www.sidefx.com], and I guess I don't understand enough about how time sampling in Solaris and USD work.

If instead of a .vdb sequence, I had a sequence of .bgeo.sc files for a fluid simulation, is there an equivalent LOP that could accomplish this?

Thanks!
Anson

Why does this work?

It's much faster to author all the time samples in one cook of a node than having to cook the entire graph at every frame, even when the graph is very small.

If instead of a .vdb sequence, I had a sequence of .bgeo.sc files for a fluid simulation, is there an equivalent LOP that could accomplish this?

The Asset Reference LOP (IIRC) can do that but the resulting USD files will only work in Houdini.

F

The Asset Reference LOP (IIRC) can do that

I just checked. I doesn't.

flord

The Asset Reference LOP (IIRC) can do that

I just checked. I doesn't.

Ah, thanks for checking.

You can always use a Cache LOP to do the equivalent of multi-sample cooking on a single LOP node. The Geometry Sequence LOP followed by a Cache LOP will load the whole bgeo sequence and basically flatten it into a single big USD file which will then be written out to disk by the USD ROP (possibly doubling up your disk space, be warned, but then you can load this USD file directly and things will be much faster). Or you can use the USD Stitch Clip ROP to generate a value clip from the BGEO sequence. Value clips are as close as USD comes to allowing the loading of per-frame files from disk.

The Volume LOP is actually a special case that benefits in a special way from multi-sample cooking. When the Volume LOP cooks, it actually opens the VDB file to find all the grids/fields in the file so that you can do pattern matching and specify "*" as the fields for which you want to create prims. If you cooks the Volume LOP on frame 1 it does this with file1.vdb. When you move to frame 2, it does this again with file2.vdb. Extracting this field info is not as fast as we might hope. But when you turn on multi-sample cooking, we only extract the field info once, from the first file, and then assume that all the other files have the same fields, so those VDB files are never opened, even when you scrub through your timeline.

Neat, okay. So, unlike wrapping a `.vdb` in a `.usd` using the Volume LOP as described in this thread (where the resulting `.usd` can be very small because it simply references the `.vdb`), if I need to wrap a geometry sequence (i.e., a `.bgeo.sc` sequence) all the data will need to be stored in a `.usd` file so it's not quite the time and speed benefits of using the Volume LOP. Is that a correct understanding?

Thanks!
Anson



(In my tests here, it either wrote all the animated data into the resulting `.usd` or it referenced another `.usd` (if I selected Load as Reference on the geometrysequence node) which did.)

Not quite what I meant... I was saying the Volume LOP is special compared to other "Edit Properties"-style LOPs (like the cube LOP) which offer multi-frame cooking. The Volume LOP benefits from the multi-frame cooking much more than the Cube LOP because each cook of the Volume LOP is significantly slower than most other LOPs that support multi-frame cooking (because it has to open and read a VDB file).

When it comes to a bgeo sequence, the problems are completely different. It isn't about cook time any more, really. You can use a Value Clip ROP to create a value clip which is kind of analogous to volumes where a small usda gets created which references the per-frame bgeo files. But value clips don't have a great workflow (yet - new things are coming in H20). Or you can use a Geometry Sequence LOP and re-cache the bgeo sequence to disk as a single USD file. That USD file will be very big because it will duplicate all the bgeo data. But it will be faster to load than the bgeo-based value clip because you won't have to pay the cost of translating each bgeo file into USD as you move from frame to frame. So here you're deciding between a cost in disk space against playback performance. But in both cases the time consumed will be similar - you just have to decide if you want to pay that cost once (convert the sequence to a single USD and use more disk space) or pay that cost every time you open the USD file (make a value clip which will use very little additional disk space).