So I have a feeling this might not be possibile, but are you able to timeshift an input volume (vdb sequence) and then publish that to usd?

At the moment it's still pointing to the frame range from before the timeshift instead.

If I have an original cache from 1001-1100. Then I offset it by +50, I no whave 1050-1100 at 1001-1050. However in the exported usd, it only shows the frames 1050-1100 instead.

Does anyone know any other ways to do this?

Edit: I found an alternative way to do something similar using Matt Estela's [www.tokeru.com] notes. However it's a bit clunky as it involves writing out a usd file per vdb and then referencing itself back in with a ValueClip in order to change the time the frame range is read back in.

I don't understand what it is that you're hoping for here that isn't happening... It sounds to me like you want to show 1051.vdb at frame 1001, which is happening. You want to show 1100.vdb at frame 1050, which is also happening. What is it that isn't working in the attached hip file?

Also, I'd recommend getting rid of the timeshit and just set the volume lop file path to "$HIP/geo/volume.`$F4+50`.vdb" for an equivalent result with fewer nodes (though perhaps there is some alternative reasonfor using a timeshift that isn't reflected in this file).

Using value clips to load per-frame VDB volumes is, IMO, a whole lot of comlpication for no gain. Maybe if you want to do looping an argument could be made for value slips. But even in that case I'd recommend writing out an explicit looping sequence. Value clips are great when your data is too large to fit in a single file. But USD volume prims are tiny (one filename string per frame). Any time-manipulation you can do with Value Clips you acn also do more explicitly and with fewer headaches without value clips.

Thanks for coming back to me Mark. I guess I didn't explain the last step.

If you write out a usd file from the timeshifted volume, then read it back in you will find that it doesn't take in to account the timeshift at all and just looks for the original frame range. In the attached file you'll see if you write out the timeshifted usd that even though it should be shifted, it will only show 1050-1100.

However I hadn't even thought about what you said, and that seems to write out perfectly fine so I'll try that out and hopefully should be a lot simpler than the valueclips I had been trying.

Cheers!

Ah yes, I see now. While you're in Houdini this looks like it works because there is only one time sample authored at a time. Bu the reason the Timeshift isn't doing what you expect is because the Primitives pattern is not telling the Timeshift node to update the time samples of the field prim, only of the volume prim. If you change the Primitives to "/volume/*", then the timeshift approach works. But I still think a little expression in the Volume LOP is simpler than using a timeshift (and equivalent).

Yep, I think I mention in my notes that after going deep into all this, Mark was right in that it was much easier to just use a simple expression on the volume lop. And I hate admitting that Mark was right.

Nobody likes it when I'm right, Matt. Nobody.