Feedback on USD Exporter change for embedding default values

[wallworm]

We are discussing a change in the USD Exporter that will change the output of data in some circumstances. Currently, when the USD Exporter comes to a property (such as Transform) that will export to a value that equivalent to that value's USD default value, we are not authoring that value. For example, objects positioned at the world origin won't get transform data embedded into the USD. We already made a specific change for this last year related to explicitly exporting the "default" value for Kind when specified in the custom data. (Previously, explicitly setting a kind to "default" would not get written because "default" is the default kind in USD, but some customers needed this to be set.)

We are now seeing that there are reasons to write other data even if it matches the current default value of USD for that property. Problems that can occur:

• Currently you cannot explicitly export a property to something that is a USD default in the exporter.
• Currently you cannot author an opinion to USD with Merge to USD that would change a property to something matching the default values.

We would like to know the community's opinion on how to proceed. The most simple solution is to stop checking for the default value and always write the data, but this may change some logic in current pipelines. But we also don't necessarily always want to make more and more options that become hard for users to understand. Please let us know if you have an opinion or concern.

[dgovil]

My vote would be for an explicit option.

For example, take a stack of transforms. Would each one have all their position, scale etc authored? In most cases, artists treat them as organizational. The minimal exported USD matches their current mental model.

If they did want to now use that in composition, they couldn't layer/reference this in without resetting all the forms.

Writing out all the values that they haven't set would therefore be confusing to them.
Whereas an explicit option would mean they could opt in to this behaviour.

[wallworm]

Thanks for your input.

[Ziethriel]

As we are starting to use our USD content in more platforms with different expectations, things like setting the world axis, units and other properties would be nice, instead of having to manually edit the files.

[jufrantz]

Although slightly off-topic, it's worth mentioning that using UsdAttribute::Block can also be a good approach for Merge To USD. We use it for similar export process.

I see these advantages over authoring the fallback :

• It will handle custom attributes that may lack a known fallback value, for some reasons.
• It will also remove attribute timeSamples.
• It is making the intent clear in the layer.

For example, for the transforms case, blocking xformOpOrder and clearing all xformOp attribute values could do the job nicely.

Hope this helps.

[gelshoffNV]

For "Currently you cannot author an opinion to USD with Merge to USD that would change a property to something matching the default values." Is there no way it could lookup whether the base attribute is authored to know whether to write the default value or not?

[wallworm]

It's important to note that we are talking about the exporter in this thread and not native workflow on a stage inside of Maya. Because of that, there is no lookup to do to any base data as we are simply translating Maya data to USD.

During an export from Maya data to USD data, the USD exporter skips writing any property values that match identically to the value you would get by excluding writing that value. Case in point, if you export a mesh from Maya with its pivot at the world origin without any transforms applied and set the Subdivision Method to Catmull-Clark, you will get a resulting prim that has neither any XformOp nor Subdivision information written because Catmull-Clark is already the default value and a xformOp value with no transformation is also a default value.

Since the voting above has all been on the side of adding an option to simply write all the values, we will take this into consideration in a future update.

Thanks for you feedback.