Hi,
it seems like ValueClips is the go-to for ‘keep-alive’ animation, as also described in the docs.
Say I have an asset with a 25 frames of animation that is supposed to cycle.
That asset is referenced lots of times in a big set. To throw in some variation, an artist authors different layer offsets on the references.
Now we are treating a gigantic 2000 frame shot.
Ideally I would look for a ‘cycleThatClipInfinitely’ metadata, but it seems like I need to author the ‘times’ metadata of the clip explicitly.
I see 2 possibilities:
Author the times already in the referenced asset itself.
This means that I need to know the maximum extend of stageTime+layerOffset that will be used for this asset in its production life-cycle. Or I try to stay safe and just author cycling times from -10000 to 10000… and hope for the best.
Author the times metadata in each shot on all the prims that carry references. This will allow to get exactly the right amount of entries over the length of the shot. But it requires quite some tooling and instead of saying “reference this looping asset with offset x”, I now need to have the tool do “reference the asset with offset x, check also from where to where it has it’s basic cycle defined and author the necessary metadata”, which seems not very intuitive.
We talked this over, and agree that providing a looping ability for Value Clips (especially the “simple” version that derives the interval-to-loop from either the times field or templateStartTime/templateEndTime) should be quite possible in our design for Value Clips, and also quite useful.
The one hitch we don’t have a super-satisfying answer for is what we would then do about the two UsdAttribute methods that deal in “all the timeSamples”, i.e. GetTimeSamples() and GetNumTimeSamples(), since by current definitions, they would, in such cases, return either zero or an infinite number of samples, which we obviously can’t do. We don’t use those queries in any of our code because they are already horrendously expensive and generally unnecessary (GetTimeSamplesInInterval() is almost always what you want), but it likely would involve breaking the uniform logic of these methods and interrogating only the authored clip samples for just those methods.
This could fit into a larger project we have coming up… would someone care to file an Issue for this, please?
I can’t find any Issue that was ever posted? Now that we have had to add support for infinitely looping splines, it almost seems like an inconsistency that value clips don’t support it (and you’ll soon be able to have infinite splines inside of value clips), though it will require some additional/different mechanism to support. @Nick , please go ahead and file an Issue if you’d like?