We have run into what seems like should be a simple issue when using usdstitch to combine the animated output from several individual usd files, each exported from maya over a series of consecutive frame ranges. It appears to be related to the export process authoring the time-sampled attributes with the sparse attribute value writer to eliminate any redundant time-samples where the values do not change. The problem occurs when the last sample written into one of the frame range batches is NOT on the last frame in the batch (meaning that the attribute value remains constant for several frames at the end of that batch), BUT the first frame of the following batch has a different value. In this case, the value of the attribute in the usdstitch output is interpolated incorrectly from the last sample (NOT the last frame) in the previous batch to the new value in the following batch, which does not match the original animated values.
Is this the expected behaviour for usdstitch? There is nothing in the docs that suggest any limitation relating to using sparse time-sampled attribute values in the input files – and in fact, this is more a natural consequence of the standard attribute interpolation logic itself.
It is of course possible to imagine a number of potential workarounds to deal with this situation, but I’m not sure it makes sense for us to do so if it were able to be handled correctly by usdstitch out of the box. I’m curious to hear whether anyone else has encountered this problem and whether this is something we might expect to see a fix for at some point.
Hi @ocastle ,
Good catch, I think your expectation is correct, and it is the behavior you would get if you used usdstichclips to alternately generate a clipSet instead of usdstitch (unless you used the optional interpolateMissingClipValues feature). There are questions of where exactly the switch should happen (i.e. previous frame to next layer in sequence, or firstFrame - epsilon of next layer?), but we can follow whatever we’re doing when we flatten value clips onto a stage.
We also need to update usdstitch to support splines; not sure when exactly the fix you’re looking for would land yet, but we’re in agreement the behavior should change.
An expectations note: today usdstitch does not really adhere to a notion of one layer/clip ending and another beginning, i.e. where the boundaries are. It just keeps taking samples from earlier layers in the sequence until they run out, and then moves on to the next (I think).
To make this work reasonably, I think we’ll need to make it aware of boundaries, as value clips do. The obvious/easy choice is to make it only consume data from within each layer’s startTimeCode/endTimeCode range, as that’s the playback range you’d get in usdview when viewing each layer independently. If ranges overlap, earlier clip’s data “wins”, as is the program’s current behavior for overlaps.
If more flexibillity is needed, we’d be getting into the same specification-space as what goes into Value Clips’s clipSet metadata.
… and after examining current code usage, also need to state that:
usdstitch is built atop UsdUtilsStitchLayers, and would make use of its “advanced” stitchValueFn form to make these behavior changes.
However, Solaris, MayaUSD, and internal code both here and at WDAS instead make direct use of UsdUtilsStitchLayers…
So client code will need to be updated to call augmented API’s to get the new behavior, and to protect existing clients we may want to deploy the behavior even in usdstitch itself with a new command-line arg.
Thanks for considering this as something that could be fixed internally in USD – please let me know if there is there an issue for this we can track from our end, it would be good to understand where this fits in your development priorities and when we might reasonably expect an update to be released.