Operator Polling Interferes with Automated Morph Loading

[Midnight Arrow]

This follows on from #2185.

In order to extract content_type, I manually load it from the DSON file based on the Object.DazUrl property. This works, but I am running into problems trying to automate morph loading. Currently, morph loading must be done through the operators listed here. However, operators have poll functions which interfere with the process. For instance, bpy.ops.daz.import_jcms() requires the current selection to be a mesh. This can be gotten around by fiddling with ViewLayer selections or using a context override, but if useMakePosable is flagged true, then it switches the selection under the hood to the rig and causes the poll to fail. Needless to say, this is inconvenient if we want to loop through all objects and automatically load morphs based on their content_type property, not to mention it’s impossible to know what the polling function is even looking for without trawling through the source code.

One solution would be the convert the operators into public API functions which take the object to operate on as an argument, and then the operators become wrappers which pass the viewport selection to these functions.

[Thomas Larsson]

I’m not sure why the jcm-like morphs could only be imported to meshes. In the last commit I changed it so the armature can be selected as well, and this doesn’t seem to cause any problems.

[Midnight Arrow]

Ideally there should be a way to load morphs without any selection at all, though. The content_type property allows us to define logical rules to handle morph loading. There should be no need to use the viewport/UI at all, unless manual finesse is required.

[Alessandro Padovani]

Duplicate of #2214.