Maya: write color sets in create_model

[moonyuet]

Brief description

Adding the on/off option of write color sets attributes in create_rig.py

Adding swtiching on/off clickbox to override the boolean option of write_color_sets_arttirbute in create_model.py and create_rig.py

[ynbot]

Task linked: OP-3749 write color sets

[m-u-r-p-h-y]

I would add Face Sets options as well to make it complete

[moonyuet]

I would add Face Sets options as well to make it complete

added into the create_rig.py

[m-u-r-p-h-y]

added into the create_rig.py

can you also add the Face sets to the corresponding settings?

[BigRoy]

note that the settings for Rig Creator are not modifying rig publish, but output from rig animation, which is handled automatically without its own creator.

Where is the code/logic for that? I don't recall seeing any Rig loader logic that sets anything like that for the to be created animation instance? Looking at the code the animation instance values have nothing to do with the setting that were set on the rig instance when being published. (That data is not even in the database or on disk, right?)

Or what obvious thing am I missing?

[antirotor]

Or what obvious thing am I missing?

No, but it is somewhat convoluted - animation creator is called when rig is loaded into the scene:

https://github.com/pypeclub/OpenPype/blob/377df371db52412f9485272da413448ef647107c/openpype/hosts/maya/plugins/load/load_reference.py#L155-L167

but since this creator is never called by user (and shouldn't be even listed in Creator dialog - but we can't hide it now), it's logical to move settings for it somewhere. Not saying it is ideal, but the options are:

• have the settings in animation creator: that is logical from the point of code, but not very user intuitive
• have that option on rig loader - but again, it actually influence subsequent publishing of animation from the loaded rig
• have it on the rig creator as we have in this PR
• other option? :)

[BigRoy]

The point I was trying to make was that the values you set on the Rig instance here in CreateRig don't seem to influence the values on the Animation instance at all. Those values are not published along with the Rig in such a way that it seems that the Rig loader set anything related on the animation in any way.

As such the values on CreateRig and the rig instance itself have no use. They do nothing, they don't propagate to the animation instance when the rig is loaded. Or where is that logic?

---

have the settings in animation creator: that is logical from the point of code, but not very user intuitive have that option on rig loader - but again, it actually influence subsequent publishing of animation from the loaded rig have it on the rig creator as we have in this PR other option? :)

I'd say that IF the rig instance can set default values for the animation instance that could be quite useful. So that an advanced rigger could say "for this rig please publish animation with write color sets enabled by default" - I'd love to see that feature with "visibleOnly" to be settable per rig instance too. But the logic involved with trickling down decisions like that are much more complicated (the code isn't there yet as far as I know).

What happens if:

• Rig instance was already loaded and an animation family was created, now the Rig version gets updated which has different values for the "write color data" published along. What do we do with the existing animation instance in the scene? Do we preserve any local adjustments a user might have made or do we force revert it?
• If the Rigger allows to set a preferred value does it really make sense to allow the animator to still change the value? Like, how "strict" are these?

---

TL;DR

Having the settings on the animation/pointcache instance is worthwhile - but I'm not seeing how the logic added now for rig instances is doing anything useful.

[m-u-r-p-h-y]

we should unblock this one as some studios are waiting for create_model at least

@BigRoy is right that the added attribute on create_rig is not doing anything so @moonyuet can you remove it pls so we can merge this pls?

or is it done already?