Retiming value clip instances

   1923   7   2
User Avatar
Member
16 posts
Joined: April 2015
Online
Hello, looking how I can instance animated geometry in LOPs. I think what I need for this is a value clip, so I'm using the new geoclipsequence LOP.
The only way I can seem to affect the time of the valueclip is by instancing references, then using retimeinstances LOP. Any other way seems to lose the 'value clip' pink text, and I could not get looping to work.
geoclipsequence must be cached (non timedependent) or the instances won't retime.

Not sure what the intended workflow is. Before LOPs, instancing animated caches with Packed disk sequence was very handy. It'd be great to have PDS sop import to LOPs to help show the 'correct' usd way.

Cheers,
Luis
Edited by luijee - Feb. 23, 2024 10:56:03

Attachments:
Screenshot 2024-02-23 154156.jpg (28.6 KB)
valueclip.hiplc (466.5 KB)

User Avatar
Staff
4525 posts
Joined: July 2005
Offline
Let me start with a general piece of advice: Unless you know for sure that you need value clips, always assume that you don't need value clips. Value clips provide basically one bit of functionality: the ability to split a single large USD file into a bunch of smaller USD files, but have them behave in USD as if they are one large USD file. If your problem is anything other than "my USD file on disk is too large", you probably don't want value clips. You're almost always better off with a single animated USD file.

I may be pushing back on this harder than is absolutely necessary, but I see a lot of people think they need value clips when they really don't, but they dive into the value clip rabbit hole anyway and learn that value clips don't make anything easier. They make everything harder. When you need them, you need them. But when you don't need them, don't use them.

In your case, you want to retime animations. There is nothing inherent about animations or wanting to retime them that points in any way towards needing value clips. So you probably don't want to use value clips. In your original USD Export, you could just specify the Output file as $HIP/geo/seq/sphere.usd and your animated sequence would go into one USD file and everything else would be much easier.

BUT I could be wrong about your situation, and you provided a great sample hip file, so let me try to answer your actual questions. First, from your hip file:
1. The timeshift_doesnt_work node works fine for me.
2. The SOP Import doesn't work because your "packed disk" primitives are actually "packed USD primitives" because you're loading them from a USD file. Packed USD prims are handled specially by the SOP Import LOP. If your SOP packed prims were just loading BGEO data, you could set the SOP Import to handle "Packed Primitives" as "Unpack", and you'd probably get more or less the result you expect.
3. retimeinstances_doesnt_work doesn't work, in part, because you are pointing it at the wrong primitive. You need to set the Instances parameter to /geoclipsequence_noTimeDep_usd and then you can see the SdfLayerOffset on the Reference set on that prim has an offset of -3.1. Now this still accomplishes nothing because that reference is to the _topology_ file of the value clip. By definition, the non-animated stuff. So adjusting the timing of the non-animated stuff does nothing. This reveals a major underlying issue: the Retime Instances LOP retimes things by adjusting the SdfLayerOffset on reference and payload arcs. It knows nothing about value clips, so it cannot explicitly retime a value clip. This also points to a solution - put the value clip (which retime instances cannot retime) behind a reference (which retime instances can retime).
4. This gets us to retimeinstances_seems_to_work, which does indeed work because the instancer1 LOP created those references to the value clip I mentioned in point 3. Retime instances can adjust the SdfLayerOffset on those references and everything works as expected.

As to why you need to turn on "Sample Frame Range" on the geo clip sequence for any of this to work - this is going to be true of any retime instances workflow. The retime instances actually works fine in "current frame" mode, the problem is that you can't _see_ that its working fine if there is only one frame of animation data available at a time. You need to have the full (or at least partial) animation available in a layer for you to see the effect of the SdfLayerOffset set by Retime Instances. If you use a USD ROP to write out a 24 frame USD file with the geo clip sequence set to "current frame" and sublayer in that resulting USD file, you'll see that it actually works just like setting the geo clip sequence to "sample all frames".

Hope that helps clarify some things,
Mark
User Avatar
Member
8833 posts
Joined: July 2007
Offline
mtucker
I may be pushing back on this harder than is absolutely necessary, but I see a lot of people think they need value clips when they really don't, but they dive into the value clip rabbit hole anyway and learn that value clips don't make anything easier. They make everything harder. When you need them, you need them. But when you don't need them, don't use them.

Houdini historically has been used for simulation where 99% of the caches are .bgeo* or .vdb sequence
Houdini also has very convenient way to load those as PAcked Disk Sequence, copy around and retime using index intrinsic, and it automatically can interpolate geos with the same topology (between indices) or not when the topology differs
and also provides extrapolation options out of range

Users just want the same ease of use and flexibility when using Solaris and USD
From what I understood Value Clips should provide the way to reference such .bgeo* sequences and provide interpolation and extrapolation options, not sure about the behavior with different topology
So naturally everyone will first reach for Value Clips and try to see if it's easy to offset them per instance, because having to export a cache again as a single .usd is a waste of time and space regardless of how big the cache is

I'd be great if Sidefx could provide a proper way to do very essential workflows witin Solaris to avoid users trying to come up with workarounds that are not considered optimal

Would it be possible to have SOP Import LOP recognize Packed Disk Sequence primitives and create a proper USD way of reference to those referenced files that is offsettable, interpolates for same topo and not for different and has out of frame extrapolation without extra intermediate caches or workarounds?
That way it would take away the guess work, because while I don't use USD yet so far 100% of the people I asked the same question if this is easy or even possible to do in USD or solaris said that they don't know
Edited by tamte - Feb. 23, 2024 13:36:31
Tomas Slancik
FX Supervisor
Method Studios, NY
User Avatar
Staff
4525 posts
Joined: July 2005
Offline
For sure, having the SOP Import LOP explicitly recognize packed disk primitives and convert them into references or value clips is definitely a good idea to provide an even more familiar SOP-centric workflow. I was about to say "you should submit an RFE for that", but a quick check reveals that you already have! So thank you for that.

If what you're describing is the desired workflow for this user, then the closest option is the one demonstrated in the posted hip file (option 4) of using a geo clip sequence in "sample all frames" mode to create the value clip, then using an instancer LOP and a retime instances LOP. It's obviously different from a pure SOP/packed disk workflow, but not too far off, I think.

But in the provided file, the original animated SOP data is being saved out as per-frame USD files, not BGEO files. And the original question was the very generic "how I can instance animated geometry in LOPs". So given that context I thought it was worth mentioning that an animated USD file would, IMO, be a better option that avoided value clips altogether.
User Avatar
Member
16 posts
Joined: April 2015
Online
Thanks very much for the indepth information
For more context on the use case, we would have a very long cache sequence ~3000 frames, we want to instance different cache frames onto points.

It is an alternative workflow for a simple crowd. We're trying this way as the SOPcrowdimport LOP was crashy and slow, and as we don't care about transitioning clips or the skeleton we thought this might be less intensive to render. It might be that crowds are the better solution here over value clips, but without any examples I can't be sure so I'm trying to follow the path of least resistance.

I'll see if the value clips method works well at scale and share any findings.
Cheers,
Luis
User Avatar
Member
16 posts
Joined: April 2015
Online
coming back to this I still found no way to achieve the looping
User Avatar
Staff
4525 posts
Joined: July 2005
Offline
For looping you can create a explicitly looping animation that is long enough to cover your whole animation frame range, or you have to use value clips. The geo clip sequence LOP has parameters for setting up simple looping behaviors.
User Avatar
Member
1 posts
Joined: Nov. 2020
Offline
Hi there. Thanks guys for all the informations on this thread.
I'm aslo trying to get a looping behavior on an animated tree and then offset it per instance in order to make some variations.
I manage to use the geo clip sequence in order to get value clip driven animation. But when I use the Start Frame - End frame and Loop Frames then write it to disk as a usda referencing the usd file sequence. I cannot seem to get a looping behavior when I read my usd back in a reference node. Am I missing something here?
  • Quick Links