Maya: Rendersettings unify logic towards single library

[BigRoy]

Brief description

This tries to reduce the scattered hardcoded values for renderer attribute names, types and tries to clean up the same things on the RenderSettings class. I've also refactored the usage of it across the code.

Description

• Delays getting image prefixes per renderer instead of loading project settings three times on import of lib_rendersettings
• Move over missing image prefixes values that existed on validator but not in lib_rendersettings
• Move over AOV char logic to lib_rendersettings
• Readability cosmetic tweaks on some lines which did more complex formatting than needed.
• Removed lib.RENDER_ATTRS in favor of the now added RenderSettings.get_padding_attr (other logic of lib.RENDER_ATTRS was unused)

Additional info

Relates to #3878, #3879 and #3821 since they touch a similar area of the codebase.
Also relates to #3873 which also touches an aspect of rendering in Maya.

Testing notes:

1. Test creation, validating and publishing of Render instances.
2. Ensure "Reset render settings" works as expected.

• Maya 2023 (Py3)
• Maya 2020 (Py2)
• Redshift Renderer
• V-Ray Renderer
• Arnold Renderer
• Renderman Renderer
• Maya Hardware 2.0
• Perform tests with multilayer on and off (make sure image prefix validations and repair work as intended and are clear to the artist)

[BigRoy]

@mkolar @antirotor what do we think of adding this BigRoy#7 to RenderSettings as well?

EDIT: Done with 90667f3

[antirotor]

@mkolar @antirotor what do we think of adding this BigRoy#7 to RenderSettings as well?

Yes please!

[tokejepsen]

If you have Merge AOV disabled and remove the token , the validate/repair never gets it back. This is for Maya and Arnold.

Tested in Maya 2020 successfully with #4795 merged.

[BigRoy]

If you have Merge AOV disabled and remove the token , the validate/repair never gets it back. This is for Maya and Arnold.

Could you elaborate the preferred behavior. The question is what "repair" should do or allow? If I understand correctly it should revert the merge AOV option back to what the settings dictate, correct? It's not up to the scene or artist to deviate from the merge AOV option, yes?

Currently the validation DOES allow to deviate merge AOVs settings + the image prefix as well. Which maybe makes it weird if it then forces the value on repair if it invalidates based on another setting?

The validator does require however the token to match with the merge AOV setting, so have ` if merge AOV is disabled, and not have if it's enabled.

Anyway, I've now made it so that it also repairs the merge AOV setting. @tokejepsen does that solve it for you?

[tokejepsen]

Could you elaborate the preferred behavior. The question is what "repair" should do or allow?

I think the repair should fix the file name prefix according to what state the Merge AOVs is in.

Merge AOVs enabled > no <RenderPass> token.
Merge AOVs disabled > need <RenderPass> token.

[tokejepsen]

Also Maya Hardware 2.0 works.

[BigRoy]

I think the repair should fix the file name prefix according to what state the Merge AOVs is in.

Merge AOVs enabled > no token.
Merge AOVs disabled > need token.

What should happen if the default prefix in settings does NOT have a token, should we append it to the end? Should we append _<RenderPass>?

[tokejepsen]

What should happen if the default prefix in settings does NOT have a token, should we append it to the end? Should we append _?

Hmm, had some thoughts about optional tokens but since this setting is project based, admin should be in control of this. Lets keep as it now. Nice one!

[tokejepsen]

Code looks good and partially tested for the renderers I can.

[BigRoy]

@LiborBatek could you test again whether in the meantime your issue mentioned here has been resolved?

There have been changes in code (4 months ago) by @moonyuet here which I'm not sure whether they do what it intends to do. Since it seems off that first it's trying to set redshiftOptions.primaryGIEngine and redshiftOptions.secondaryGIEngine based on some conditions but in the end it still ALWAYS sets it to the value int(rs_p_engine) and int(rs_s_engine). Seems like a bug @moonyuet ?

Anyway, the code seems related to the issue you described @LiborBatek so I suspect your particular issue has been resolved.

[moonyuet]

@LiborBatek could you test again whether in the meantime your issue mentioned here has been resolved?

There have been changes in code (4 months ago) by @moonyuet here which I'm not sure whether they do what it intends to do. Since it seems off that first it's trying to set redshiftOptions.primaryGIEngine and redshiftOptions.secondaryGIEngine based on some conditions but in the end it still ALWAYS sets it to the value int(rs_p_engine) and int(rs_s_engine). Seems like a bug @moonyuet ?

Anyway, the code seems related to the issue you described @LiborBatek so I suspect your particular issue has been resolved.

maybe needs a double check on the particular setting, but it got tested and resolved in the other ticket which is merged in December 2022, while @LiborBatek found this on November 2022.The related PR is #4087

[LiborBatek]

Did test in Vray and got error when triggered Repair on Render Settings (I have left intentionally empty File Name Prefix empty)

However when tried to Publish it afterwards straight away ....it worked then (so I guess the Repair worked tho)

[tokejepsen]

@BigRoy could you resolve the conflicts?

[LiborBatek]

@BigRoy maybe silly question, how this PR adhere to the new publisher in maya? all good?!

[BigRoy]

maybe silly question, how this PR adhere to the new publisher in maya? all good?!

I don't expect it to be functional momentarily - it's a very old PR that I'm not sure how to best merge logically nowadays. I think we might have it merged in our colorbleed branch and along the way have synced that branch with new publisher - etc. but likely that's seen decent refactoring to make it work.

However, some of the cleanup is still relevant - I'll close this PR and see if I can set up a new one with some of the cleanup in here that is still relevant.