[MAYA-126919] Request to use displayColor when disabling "Textured" in the viewport

[chrizzFTD]

Hi maya-usd team, happy new year!

I was unsure if this is a bug or a feature request, so I'm logging this as a "Feature request".

Context This relates to the request from https://github.com/Autodesk/maya-usd/issues/2206 to allow a USD Stage to "listen" to the Textured control from the viewport toolbar:

Current Behavior

With the update from https://github.com/Autodesk/maya-usd/pull/2599, textures get disabled (good) but meshes are drawn with black color instead of drawing according to their displayColor property.

This magazines.zip zip file contains the usdz stage from entity/books_magazines01/books_magazines01.usda from the ALab phase 2.

Go to Create / Universal Scene Description (USD) / Stage From File... and select the zip file. You can see how toggling the Textured button goes from textured geometry to black geometry:

When loading the complete ALab set, the same happens:

Expected Behavior

USDView and Houdini respect displayColor when disabling scene materials, which is why as a user, I would expect for Maya to do the same. In the ALab example, we can see that meshes which did not have a material previously applied, continue to draw with displayColor:

USDView exposes this with the Enable Scene Materials menu:

Houdini does it with the Display Materials on Objects toggle:

Could the Maya Textured toggle follow the same approach?

Thanks!

[santosd]

Hi @chrizzFTD, Thank you for reporting this. I think this would be a great addition. I will go ahead and log this internally as I believe it may require some Maya side changes.

[santosd]

This issue was internally logged as MAYA-126919.

[wallworm]

We are working to address this. Since we found that this may not accommodate those studios/users that don't want the display colors in this case, we intend to make a User Preference that will choose the behavior: Case #1, keep current behavior and Case #2 display the displayColor.

[Ziethriel]

We are working to address this. Since we found that this may not accommodate those studios/users that don't want the display colors in this case, we intend to make a User Preference that will choose the behavior: Case #1, keep current behavior and Case #2 display the displayColor.

Having the user preference will be nice, since we probably wouldn't want to have the vertex colors in untextured mode. However we would like to have the option to "Toggle Display Colors Attribute" like mentioned in my issue below:

https://github.com/Autodesk/maya-usd/issues/3299

Maybe the keep current behavior can add this change?

[alex-savenko-at-cinesite]

The suggested solutions (#1 and #2) can only be applied to diffuseColor input of USdPreviewShader. What happens if the preview shader has connections to opacity, specularColor or any other parameter of the preview shader? It would be great if those cases could be supported too. If you are planning to use a preference option already, can you please consider supporting option #3: "fallback option".

When hardware texturing is disabled, the preview shader should use fallback parameter of the connected UsdUVTexture or UsdPrimvarReader shaders instead of using the connected shaders themselves. In other words, the shader should behave in the same way as if the specified texture or the primvar was not found.

The benefits of the option #3:

• it does not rely on an extra attribute (displayColor). All fallback values are specified in the shader itself
• it supports all inputs of UsdPreviewShader, not just diffuseColor. This can be particularly important for metallic shaders that do not have a valid diffuse color.
• it should not affect speed of the preview or the amount of GPU memory. It might be even faster than "displayColor" preview if displayColor is specified as a vertex attribute

References:

• https://openusd.org/release/spec_usdpreviewsurface.html#:~:text=fallback%20%2D%20float4%20%2D%20(0.0,not%20be%20read.

• https://openusd.org/release/spec_usdpreviewsurface.html#:~:text=from%20the%20mesh-,fallback%20%2D%20TYPE,-fallback%20value%20to

[gdufiefsp]

Hey everyone,

First of all, thanks a lot for all the great work you're doing on this project — it's much appreciated!

I was wondering if you happen to have an ETA for this feature. We're also looking forward to it, and having a rough idea of the timeline would really help us plan our own development accordingly.

Thanks again!