Maya: fix image plane loader

[antirotor]

Fix

This is fixing some error when trying to load exr sequence as image plane in Maya.

Testing:

1. OpenPype -> Load and select exr sequence
2. RMB and load as image plane
3. Create new camera
4. It should load without errors

Not sure why these error popped up, but I've tested it in Maya 2020 and 2022. This fixes them by sort of ignoring.

[ynbot]

Task linked: OP-3102 Maya image plane load error

[BigRoy]

Not sure why these error popped up, but I've tested it in Maya 2020 and 2022. This fixes them by sort of ignoring.

I think this might be due to some Maya version having a bug where the Frame extension expression just didn't get created correctly - I believe it was on some Maya 2020 and 2022 versions but not all of them.

The fix seems a bit too unspecific. These seems more explicit:

expressions = image_plane_shape.listConnections(type="expression")
if expressions:
    pm.delete(expressions)

if not image_plane_shape.frameExtension.isFreeToChange():
    raise RuntimeError("Can't set frame extension for {}".format(image_plane_shape))
    
image_plane_shape.frameExtension.set(start_frame)

Also, I'd even recommend making sure we get the right expression:

expressions = image_plane_shape.frameExtension.inputs(type="expression")
if expressions:
    pm.delete(expressions)

if not image_plane_shape.frameExtension.isFreeToChange():
    raise RuntimeError("Can't set frame extension for {}".format(image_plane_shape))
    
image_plane_shape.frameExtension.set(start_frame)

Thoughts?

If the user is expecting a frame hold I'd like it to be explicit if it can't perform what the loader was expected to do, like setting the start frame.

[BigRoy]

When is this ever locked on load?

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

I'm testing it on M2023

The image plane is created, exr seq loaded, but there is some weird offset applied

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

other options are not working either.

I think it should be removed. User can tweak this on imageplane itself I can see no point/benefit of exposing these two options in UI

with static image plane option on, there is some Maya2023 error happening:

Traceback (most recent call last):
  File "C:\Program Files\Autodesk\Maya2023\Python\lib\site-packages\pymel\core\nodetypes.py", line 573, in __getattr__
    return getattr(super(general.PyNode, self), attr)
AttributeError: 'super' object has no attribute 'getRotation'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Program Files\Autodesk\Maya2023\Python\lib\site-packages\pymel\core\nodetypes.py", line 712, in _attr
    plug = self.__apimfn__().findPlug(attr, False)
RuntimeError: (kInvalidParameter): Object is incompatible with this method

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Program Files\Autodesk\Maya2023\Python\lib\site-packages\pymel\core\nodetypes.py", line 732, in _attr
    raise RuntimeError
RuntimeError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Program Files\Autodesk\Maya2023\Python\lib\site-packages\pymel\core\nodetypes.py", line 576, in __getattr__
    return DependNode.attr(self, attr)
  File "C:\Program Files\Autodesk\Maya2023\Python\lib\site-packages\pymel\core\nodetypes.py", line 664, in attr
    return self._attr(attr, False)
  File "C:\Program Files\Autodesk\Maya2023\Python\lib\site-packages\pymel\core\nodetypes.py", line 742, in _attr
    raise general.MayaAttributeError('%s.%s' % (self, attr))
pymel.core.general.MayaAttributeError: Maya Attribute does not exist (or is not unique):: 'cameraShape1.getRotation'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "D:\REPO\OpenPype\openpype\tools\loader\widgets.py", line 1572, in _load_representations_by_loader
    load_with_repre_context(
  File "D:\REPO\OpenPype\openpype\pipeline\load\utils.py", line 284, in load_with_repre_context
    return loader.load(repre_context, name, namespace, options)
  File "D:\REPO\OpenPype\openpype\hosts\maya\plugins\load\load_image_plane.py", line 143, in load
    image_plane_transform.setRotation(camera.getRotation())
  File "C:\Program Files\Autodesk\Maya2023\Python\lib\site-packages\pymel\core\nodetypes.py", line 580, in __getattr__
    raise AttributeError("%r has no attribute or method named '%s'" % (self, attr))
AttributeError: nt.Camera('cameraShape1') has no attribute or method named 'getRotation'

[BigRoy]

I think it should be removed. User can tweak this on imageplane itself I can see no point/benefit of exposing these two options in UI

I somewhat agree - as long as "update" doesn't change it again it seems like something that the user can somewhat manage themselves. However, selecting that initial camera you'd want to add it to - you might still need that.

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

I somewhat agree - as long as "update" doesn't change it again it seems like something that the user can somewhat manage themselves. However, selecting that initial camera you'd want to add it to - you might still need that.

Sure. I meant only the two options below the camera selection

• Make Image Plane Static
• Show Image Plane in all Views

the first one is crashing (at least in Maya2023
the second one does nothing anyway

[BigRoy]

the second one does nothing anyway

How do you mean? It should do something. If it doesn't it's a bug. You can set up a Maya image plane to only show in one viewport to which it is connected or whether to show in all viewports so I'm suspecting that's what it was intended for.

[tokejepsen]

Sure. I meant only the two options below the camera selection

Think you'll need to battle it out with @ClementHector

64c4e5f

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

There is nothing to battle.

It is not doing what it suppose to do.

If Show Image Plane in All Views is OFF it should turn on "looking through camera"
If Show Image Plane in All Views is ON it should turn on "in all views"

It should be on by default btw.

but it is not changing anything . . .

And even if it worked I do not see any point in picking up 2 attributes (out of 30) and exposing them in the loader UI

There is yet another issue, when pressing Cancel it will crash.

Traceback (most recent call last):
  File "D:\REPO\OpenPype\openpype\tools\loader\widgets.py", line 1572, in _load_representations_by_loader
    load_with_repre_context(
  File "D:\REPO\OpenPype\openpype\pipeline\load\utils.py", line 284, in load_with_repre_context
    return loader.load(repre_context, name, namespace, options)
  File "D:\REPO\OpenPype\openpype\hosts\maya\plugins\load\load_image_plane.py", line 117, in load
    camera = camera_names[window.camera]
KeyError: None

[ClementHector]

I don't agree to delete them, of course the user can do it manually.
But loaders are also used in #2202
The build does not ask the user to make the selection, because it is a template option.
Or maybe you can remove them from the interface and leave them in the code?

[mkolar]

Or maybe you can remove them from the interface and leave them in the code?

I agree with @m-u-r-p-h-y with this one. Interface wise it is arbitrarily picking two attributes out of dozens and showing them in the loading process. The fact that these two are important for studio A, doesn't mean they are important for studio B. Hence it is more of a clutter than efficiency increase I feel.

Regarding leaving them in code, but removing in the interface. I'm ok doing that at this point considering they are already used in production and you are most probably using it in the templates. However, it is the same problem with arbitrarily picking attributes and promoting them to the templates. I'd say that it uncovers the fact that using locators as the placeholders in the templates might not be enough and we should consider allowing other nodes to be placeholders too. In this case it would be much better to have image plane node as the placeholder with a bunch of custom attributes. that would allow preserving all of it's settings on the image plane eventually created by the loader. But that's better discussed in the template ticket probably.

[tokejepsen]

@mkolar did you mean to close the issue?

[ClementHector]

@mkolar If this is annoying for you I will make another specific loader for our studio. This may be the best solution?

[mkolar]

Sorry guys. I misclicked and totally didn't realise I closed this. My bad and it wasn't the intention at all.

[mkolar]

@mkolar If this is annoying for you I will make another specific loader for our studio. This may be the best solution?

It's not annoying, but it is quite arbitrary and I'd say better solved by custom loader as you say.

[mkolar]

@antirotor could we have a look at finishing this up please?

[antirotor]

Closing this PR as it doesn't solve issues with it and it needs to be solved another way.