I know similar questions have come up to this before, but are there any plans around component-wise animation of dimensional attributes? For example, animating the first component of a vector?
I know that translate and scale got scalar xformOps to sort of bypass this, but it seems there are still cases for this, particularly in custom schema attributes (for example, animating a color attribute for a light). To really take advantage of spline animation, a developer would either have to break apart their custom attributes into scalars (which is a bit of an unbounded problem) or design their own solution for mapping a spline to an attributeās component.
Weāre currently looking at taking the second approach ourselves, though Iād really like to avoid/minimize it because we then would have to filter any use of spline animation through our own APIs rather than default USD Get calls.
I donāt think arrays are allowed to be splines, so Iām not sure the array edit proposal applies here.
From the array edit proposal: Since splines in USD are restricted to floating point scalars, which are always dense values, we do not need to consider splines here.
@lbiasco-sie I agree with you that itās unfortunate that spline support for dimensioned floating point type were dropped from the proposal.
As @nvmkuruc alluded to, the initial proposal did propose support for numeric tuples, which Prestoās spline has always supported. My understanding is that the ability got very little use over the years, for several reasons, probably the biggest of which is that the animation interfaces our animators use do not need them, and so adding support to our animation editing tools for them (which is a challenge), never seemed worthwhile. They also resulted in lots of special-cases inside the spline code that were a maintenance challenge, and so the early software designs that flowed out of the proposal involved splitting out a spline into multiple classes based on capabilitiesā¦ but then that started to look like a lot of client-facing complexity that didnāt seem warranted.
So, with the acknowledgment that we werenāt closing the door permanently, we decided to simplify the design and implementation to only support scalars (quaternions already do SLERPing when recorded to timeSamples, and it didnāt look like Mayaās quaternion implementation provided any useful/used interpolation methods beyond slerping, anyways).
We do animate colors for shading, but thatās performed by shader nodes that have bespoke interfaces for providing samples and interpolation methodsā¦ and sidebar that thereās been some discussion about trying to standardize on a ācolor rampā schema such that there could be interchangeable widgetry for ramps, though that looks challenging!
Without adding support to splines for tuples, our forward-looking answer might be to split into scalars and use connections and mappers to drive them into the color3f attribute, leveraging OpenExec. Thatās not a perfect solution, a) because itāll be awhile before dataflow and mappers are available in OpenExec, b) even when it is available, splitting into scalars makes working with color pickers challenging.
Itās good to hear use-cases for this, and please feel free to file an Issueā¦ funnily enough we were just talking about this yesterday in the context of XformCommonAPI.
This does kind of seem like it falls under the umbrella of sparse editing arrays and would be sparse editing tuples/vectors. If you could sparse edit an element of a tuple/vector, then you could assign a spline to it. From the OpenExec paper it looks like connections will be able to target specific elements of a tuple/vector for data flow.
Our custom schemas use vectors and to work around this problem, we are considering adding new scalar attributes to the data (not schema) if the attribute is animated. For example:
# Light schema.
class SMSSmLight "SMSSmLight"
{
color4f color = (1, 1, 1, 0)
float intensity = 1
}
# Light in data.
def SMSSmLight "SmLight"
{
# This isn't in the schema and is added if color has an animation spline.
float color:r.spline = {
0: 0; pre (0, 0); post held,
1: 1; post held,
2: 2; post held,
3: 3; post held,
}
float intensity.spline = {
0: 0; pre (0, 0); post held,
1: 1; post held,
2: 2; post held,
3: 3; post held,
}
}
In addition we would create a non-applied API to access the spline information. (hand-wavy) You would pass it the vector attribute and it would look for the element attributes under the namespace which comes from the name of the vector attribute. Does this approach seem reasonable?
That seems reasonable and would be incorporatable into an OpenExec world. Also, to be clear, if we were to add spline support for tuples, it would not allow for the different components to have different knotsā¦ youād get (e.g.) a float3-valued knot whose tangents were also float3ās.
Does that majority-satisfy what people are looking for? If you want independently timed/authored curves for each component, youād need to go the OpenExec route.
Thanks for calling out that clarification, as āanimating components with separate splinesā is exactly what weāre after here.
Weāre coming from a Maya ecosystem, so most attribute components can be driven by their own animation curves. However Iām not sure how extensively this animation is used in our tuple-like data besides transformations, so thatās probably worth digging into further.
Regardless, it sounds like we should continue to move forward with a custom API for authoring and handling these component attributes, similar to the PrimvarsAPI and its indices or idFrom secondary attributes, and keep our eyes on the horizon for integrating it with OpenExec for streamlined data access.
Thanks for the reminder, @lbiasco-sie .. I now remember years ago there was a request for USD connections to support component-wise connections, to facilitate Maya-style connectivity. Regardless of how Mayaās APIās expose it, evaluating those connections efficiently requires an evaluation/execution engine, so it feels pretty similar to the OpenExec routeā¦once mappers and expressions are available with OpenExec, it should be pretty easy to build UIās that look like component-wise connections and are actually authoring the connections, mapper and/or expression that encode them.