-
Notifications
You must be signed in to change notification settings - Fork 69
Reading and Writing Attribute Data to and from USD
There are various "live" attributes represented in various Maya nodes in AL_USDMaya which can be driven by either USD or Maya data sources. Currently there are 3 sources:
- Maya
- USD Default Value
- USD Time Samples
We also have the option in some cases of writing the source data to a target. Currently:
- Maya data can be written to USD Default Value
- Maya data can be written to USD Time Samples
- Maya data is not written to USD (i.e there is no target)
Each AL_usdmaya_Transform node in Maya has 2 attributes which control attribute read/write behaviour:
- pushToPrim - whether values in maya should be pushed back into USD. If false/off, all values come from USD, if true, they come from Maya. Default values depend on arguments to the ProxyShapeImport or TranslatePrim
- readAnimatedValues - if false/off, we read from and write to the USD "defaultValue". If true/on, we read from and write to time-sampled USD values. Current Default is true/on
As far as reading values go, we have the following options:
- Read the Default USD values (pushToPrim=false, readAnimatedValues=false)
- Read the time sampled USD values (pushToPrim=false, readAnimatedValues=true)
The readAnimatedValues attribute on the AL_usdmaya_Transform nodes controls this behaviour. If a given transform attribute has an incoming connection, then no values will be read from USD, and the value provided by the connection will be the value for the transform attribute.
AFAIK, we don't need to make any changes to AL_USDMaya here? (unless there is something I may have missed? e.g. always write to UsdTimeCode::EarliestTime(), rather than UsdTimeCode::Default())
As far as writing goes, we support these 3 options (option 3 was broken until AL_USDMaya-0.32.19)
- Don't write any values to USD at all (pushToPrim=false)
- Always write transform values to USD as default values (pushToPrim=true, readAnimatedValues=false)
- Always write transform values to USD as a time sample at the current frame (pushToPrim=true, readAnimatedValues=true)
A proposed/possible refinement of 2 and 3 is:
- Write transform values to USD as time samples only when the attributes have input connections.
- Write transform values to USD as default values, only when the attributes have input connections? (do we need this? Again, do we want to choose between UsdTimeCode::EarliestTime() and UsdTimeCode::Default()?)
The internal attributes (e.g. Those on USDGlimpseMaya lights such as intensity where the maya nodes are effectively proxies of USD data) should probably behave in exactly the same way, however the way in which they work differs substantially from the transform attributes (where we have a bit more flexibility). The current behaviour for internal attributes is:
- If the maya attribute has an input connection, read/write the data from the time samples.
- If no input connection exists, read/write the data to the default values.
Currently this configuration is per-node for transforms, and determined in an adhoc way per attribute for internal attributes (AFAIK: If an input connection exists, data is read/written to samples, otherwise it is written to the defaults).
We might like this to be more of a global configuration if different departments want different default behaviours, consistent across different attribute types. We may want to remove the per-transform attributes for example, or keep them as overrides
When we click upon a shape in Hydra, we create a transform chain to mirror the transforms within USD. How should we determine the correct attribute read/write behaviour to set on the newly created prims? The options I can think of would be along the lines of:
- a global set of optionVars to control the behaviour?
- When creating the transform nodes, the settings for read/write could be read from attributes on the proxy shape?
When importing a proxy shape into a Maya scene, if any prims are encountered that need to be translated into Maya (e.g. Bond, Camera Rigs, Light Rigs, etc), how should we determine the correct settings for the read/write flags?
- a global set of optionVars to control the behaviour? (Seems horrible to me!)
- Some MetaData on the prims themselves? (Seems odd to have Maya GUI behaviour defined in USD?)
- Some MetaData on the attributes themselves? (Seems odd to have Maya GUI behaviour defined in USD?)
- Pass in additional arguments to the proxy shape import command?
- Read those settings from the ProxyShape?
- a global set of optionVars to control the behaviour? (Seems horrible to me!)
- Some MetaData on the prims themselves? (Seems odd to have Maya GUI behaviour defined in USD?)
- Some MetaData on the attributes themselves? (Seems odd to have Maya GUI behaviour defined in USD?)
- Pass in additional arguments to the translate prim command?
Currently used by:
- Animation - AFAIK mostly do not touch these attributes and explicitly set pushToPrim=false?
- Scenery for Environment Authoring - for now, probably want pushToPrim=true, readAnimatedValues=false
- Layout for Set Dressing/Modification - pushToPrim=true, readAnimatedValues=false
- Lighting - using internal attributes for lights, cameras. Using transforms for Light Rigs. They would I think like to be able to round trip behaviour in Maya
We recognise that the current behaviour is a bit inconsistent and non-intuitive, and has grown organically, so we'd like to seek suggestions for improving it, based on use cases and experience, specifically:
- Is there a good, intuitive paradigm for representing these multiple data sources and how to switch between them?
- Do we want to (as now) explicitly switch from one source/target to another, or use more implicit rules or heuristics for sensible default behaviour (e.g "if an attribute has a maya input connection, always use maya as the source")
- Rather than having per-attribute behaviour (for transforms) or hard-coded behaviour (For internal attributes) should we have global configurable behaviour which would be set up per department for example? Does this need to be overrideable at the node or attribute level?
- We probably want to make the behaviour, control, defaults identical between transforms and "internal" attributes
We could add the ability to write USD data back to maya if needed, e.g:
- USD Time Sample data gets written to a Maya Animation Curve (we don't have the ability to round trip animation created in maya at the moment, and this does not solve that problem. To do so in AL_USDMaya would require some kind of Maya FCurve schema which records interpolation, tangents etc). This might be useful to e.g Lighting (Current approach in animation/layout is to store a dual representation - i.e a "rig" and "motion" file pair in maya format containing the maya data, and a baked USD equivalent - the two are represented in USD with variats)
The PushToPrim functionality which allows changes to AL_USDMaya Custom Transforms to be pushed immediately back to USD was, prior to AL_USDMaya-0.33.2/0.32.37 On/True by default on each Transform. As of AL_USDMaya-0.33.2/0.32.37, this can be set globally with an optionVar "AL_usdmaya_pushToPrim" (defaults to False/Off), which controls the value set at creation time of each transform. Additionally, the TranslatePrim command, which accepts a "pushToPrim" flag (which defaulted to True/On), now reads the OptionVar value. The value of the OptionVar can be overriden by specifying an explicit value in TranslatePrim