Should the GetTimeSamples account for spline times as well?

Community USD
1

We make use of the function:

UsdAttribute::GetUnionedTimeSamples(const std::vector &attrs, std::vector *times);

This function seems to return the times array as empty if the attributes only have spline authored on the attribute.

One could argue, based on the name, that it should only contain actual only time sampled attributes, but the comment on the function has:

/// Populates the given vector, \p times with the union of all the
/// authored sample times on all of the given attributes, \p attrs.

Wouldn’t the spline times also not be considered authored times? Would this be a bug or intentional decision?

2

I don’t think it’s a bug but it is perhaps an area that needs clarification with perhaps a different method to check across both since I think there’s value in being able to query them separably

3

The issue that I see is that an attribute can have both, the time sampled data and the spline data and those don’t necessarily have to match on the time range.

So to get the entire time range, one would need to query the attribute for the sampled time range. Then get the knots map within the spline, get the time range interval, then sample for each time code within that interval based on the stage’s time step. Or to go through the knots map and get each key, which is the time value.

4

Yeah, I totally agree that there should be a method to query the entirety of the time samples across both time samples and splines. I just meant that I don’t think it’s necessarily a bug that the old API doesn’t account for splines, since it is explicitly for time samples. A new method would make sense.

Could you file an issue on the OpenUSD GitHub? I think its a reasonable request to have such an API addition

1 Like
5

TimeSamples and splines are different domains. It would be really confusing if spline knot coordinates (which only exist on a spline) got merged with time samples, which are actual value carrying pairs. You wouldn’t be able to tell where the time/value came from or where to author it if they were merged?

So the answer is spline times are not considered “time sample’s authored times”

6

And furthermore to what @nporcino said,

a) for any given attribute, only one of a spline or timeSamples will be relevant to its value resolution

b) How any client decides to sample the attribute will in general want to be quite different for a five-knot spline than it will be for a five-timeSample attribute. In the former case, our guidance (which will be coming hopefully in a user guide in the next release) is that (UsdGeom) MotionAPI.nonlinearSampleCount is what authors will use to provide guidance (when needed) on how densely to sample splines for smooth evaluation (for rendering, etc).

@barbalt , it sounded, at one point, like one of the things you’re interested in is the range of authored samples? If so, we need to note that for splines, there can be quite interesting (e.g. looping) behavior well outside the authored knot range, so again it’s tricky to try to reason too much about the time coordinates of knots. Which is why we advise only relying on start/endTimeCode for sampling range.

All that said:

  • We do recognize there’s a bunch of API built up around TimeSamples in Xformable and maybe some of the Skel stuff, and if we can build some consensus on how clients of those “unioned timeSamples” API’s might want to treat splines, we’re happy to engage on it. We realize the state of things is awkward right now, e.g. if you have a single Xform whose attributes are driven by a mix of splines and timeSamples.
  • Regarding looping and other “outside-authored-range” behaviors, OpenExec and other clients want a spline to be able to report the affected timeRanges of a given set of authoring changes to knots, which includes the effects of all of these behaviors, and we plan to provide that for the next release.
  • Hydra is not yet doing anything intelligent with sampling splines, and we’ll likely learn from undertaking that process.
7

Thank you @spiff and @nporcino for the answers.
I can understand now the difficulties in addressing this problem and it makes sense why the api doesn’t provide a way.

@spiff when you say:

a) for any given attribute, only one of a spline or timeSamples will be relevant to its value resolution

What would be expected if a certain attribute is authored from 0 to 5, then has a spline with keys from 6 to 10, for example. Does usd only consider the spline, in this case, or does it use both dependign on the time?

And yea, I wanted the range to try to be more precise on the range of keys that could have changed. For the current issue, I just used the attr.MightBeTimeVarying, which, according to the documentation accounts for changes in the spline. That unblocks for the current scenario, but might be not idea in the future

Thanks again the answers and explanations

8

If both the timeSamples and the spline are authored for the attribute, if the spline appears as a stronger opinion, i.e. on a spec that is “higher up” in LIVERPS for the prim, then the attribute will be animated solely by the spline.

Otherwise, even if the timeSamples and spline appear on the same spec, the attribute will be animated soley by the timeSamples from 0-5. Timesamples and splines are never mixed or sequenced in a layer – although we think this will be supported in Value Clips when they gain the ability to have splines.

When you do attr.Get(anyTimeOtherThanDefault), the strength ordering to find the single attribute value source on a spec is:

  • timeSamples, if present
  • spline, if present
  • default, if present

if none are present we continue looking through LIVERPS for other specs*

\* Caveat is I’ve ignored Value Clips… we’ll explain that in our forthcoming user guide, but it’s not necessary for the question you asked

1 Like