Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

read function should only get AYON parameters #173

Open
1 task done
MustafaJafar opened this issue Nov 15, 2024 · 1 comment
Open
1 task done

read function should only get AYON parameters #173

MustafaJafar opened this issue Nov 15, 2024 · 1 comment
Labels
type: bug Something isn't working

Comments

@MustafaJafar
Copy link
Contributor

Is there an existing issue for this?

  • I have searched the existing issues and added correct labels.

Description

Current Behavior

ayon_houdini.api.lib.read should get extra AYON parameters.

Houdini Nodes can include different type of parameters and some of them like ramp breaks the instances collection as copy.deepcopy fails.
Here's some bug report when it fails

cannot pickle 'SwigPyObject' object
Traceback (most recent call last):
  File "E:\Ynput\ayon-core\client\ayon_core\pipeline\create\context.py", line 1395, in reset_instances
    creator.collect_instances()
  File "E:\Ynput\ayon-houdini\client\ayon_houdini\api\plugin.py", line 193, in collect_instances
    node_data, self
                   
  File "E:\Ynput\ayon-core\client\ayon_core\pipeline\create\structures.py", line 800, in from_existing
    instance_data = copy.deepcopy(instance_data)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\PROGRA~1\SIDEEF~1\HOUDIN~1.370\python311\Lib\copy.py", line 146, in deepcopy
    y = copier(x, memo)
        ^^^^^^^^^^^^^^^
  File "C:\PROGRA~1\SIDEEF~1\HOUDIN~1.370\python311\Lib\copy.py", line 231, in _deepcopy_dict
    y[deepcopy(key, memo)] = deepcopy(value, memo)
                             ^^^^^^^^^^^^^^^^^^^^^
  File "C:\PROGRA~1\SIDEEF~1\HOUDIN~1.370\python311\Lib\copy.py", line 172, in deepcopy
    y = _reconstruct(x, memo, *rv)
        ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\PROGRA~1\SIDEEF~1\HOUDIN~1.370\python311\Lib\copy.py", line 271, in _reconstruct
    state = deepcopy(state, memo)
            ^^^^^^^^^^^^^^^^^^^^^
  File "C:\PROGRA~1\SIDEEF~1\HOUDIN~1.370\python311\Lib\copy.py", line 146, in deepcopy
    y = copier(x, memo)
        ^^^^^^^^^^^^^^^
  File "C:\PROGRA~1\SIDEEF~1\HOUDIN~1.370\python311\Lib\copy.py", line 231, in _deepcopy_dict
    y[deepcopy(key, memo)] = deepcopy(value, memo)
                             ^^^^^^^^^^^^^^^^^^^^^
  File "C:\PROGRA~1\SIDEEF~1\HOUDIN~1.370\python311\Lib\copy.py", line 161, in deepcopy
    rv = reductor(4)
         ^^^^^^^^^^^
TypeError: cannot pickle 'SwigPyObject' object

when checking the instance data, it shown something like

'color_ramp': <hou.Ramp is_color=True num_keys=2 data=((t=0, rgb=(0, 0, 0)), (t=1, rgb=(1, 1, 1)))>,

Expected Behavior

read function should only get AYON parameters

Steps To Reproduce:

  1. Create an HDA product
  2. Add a ramp parameter
  3. open the publisher tool or click refresh button,

Additional context:

Version

latest everything

What platform were you running when you found the bug?

Windows

You can also provide any additional information relevant to the issue.

Relevant log output:

@BigRoy
Copy link
Contributor

BigRoy commented Nov 16, 2024

Yes - for the containers we already did this, but we should also for creators. (It may also make them faster!)

So we would be getting way more explicit about the attributes we're expecting. However, currently those are quite a lot already - especially with backwards compatibility:

# creators
keys = [
    "folderPath", 
    "task", 
    "creator_identifier", 
    "id", 
    "AYON_productName", 
    "productName", 
    "creator_attributes", 
    "publish_attributes",
    "variant",
    "active",
    # legacy attributes
    "asset", 
    "subset"
]

for name in keys:
    parm = node.parm(name)
    if not parm:
        continue
    # ... etc.

And I might still be missing some?

I'm not entirely sure whether we need to read the legacy attributes or whether we're already reading those explicitly separately. But I suspect we may need to keep them in the read for creators logic for the time being? Note that we should avoid changing read function to hardcode those values - but instead implement the limited list to read in the Creators (or wherever we're querying that. The read method should stay in tact.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants