Just wanted to throw out a possibility to either be shot down, or encouraged:
An SdfLayerOffset object shows up anywhere one layer refers to another. It provides a nice interface point to translate a query for time samples tX in layer X to time sample tY in layer Y. In my mind, there is one function somewhere that does the calculation tX->tY based on the SdfLayerOffset that composes Y into X.
So my idea is that SdfLayerOffset be augmented with one or two new parameters that would let this tX->tY calculation also enable looping of the data in layer Y. I feel like this could be incredibly useful for many, many workflows.
Of course I may be dreaming that this is as simple as it sounds. I know SdfLayerOffset is fully “composable” (so any number of SdfLayerOffsets can be collapsed into a single SdfLayerOffset equivalent to applying each in turn). And I don’t know if this will still hold true with the introduction of looping capabilites, but maybe?
Anyway, is this something that has been considered in the past, and rejected for some good reason? Or does this seem like it might be worth pursuing?
Hey Mark, it sure seems like it’s “almost there”, doesn’t it? Enhancing SdfLayerOffset to facilitate looping has never been discussed, to the best of my knowledge.
My biggest issue with it is that as USD keeps moving further towards supporting primary animation authoring workflows, looping will be a primarily “source animation” concern, with the need to easily iterate. SdfLayerOffsets don’t foster that well, because they are (generally) not editable in the root layerStack… and as “primary composition data”, not often or easily exposed to users. Secondary concerns around the already complex PcpMapFunction infrastructure that implements layerOffsets, and on the impact to UsdAttribute::GetTimeSamples() if infinite looping were supported.
Today you can use Value Clips to do explicit looping. Value Clips have their own awkwardness (some of which we hope to address, like being able to put everything (and maybe even multiple clips) into a single layer), but they address a couple of the concerns above:
Value Clips can always be edited (though likely actually just respecified) in the local/root layerStack
clipSets metadata can be easily addressed in GUI’s
They’re always explicit (and allow for proper interpolation between last and looping samples with repeated times knots), and therefore never produce infinite timeSamples
But we think the main story for looping is TsSpline, which will support several flavors of looping, including looping with value offsets, I believe. I know that’s not a general solution along the value-type axis, and it would require a pretty specialized toolset to bake a “looping-spline-driven-rigged-character” to a set of clips that could be looped… but the upside is not supporting three completely different mechanisms for looping
It was while talking to a user about using value clips to author “explicit loops” that I was inspired to make this post. This is an approach to looping that is kind of hard to explain, and is not what most users expect. But better tooling may indeed be the right answer here.
“Splines” are a viable solution only if they can be applied to any data type… I’m not familiar enough with the proposal to know if it will be possible to use a TfSpline/UsdAnim to loop the animation of, for example, mesh topology attributes? Or the asset path pointing to my looping fire animation stored in VDB files?
Anyway, thanks for the info. Sounds like a “no” Which is fine, just means we need to keep working on our value clip authoring workflows in Houdini!
