Inharitance for ShaderNodeCustomGroup is broken #71858

New Issue

Maxim Vasiliev · 2019-11-24T15:41:46+01:00

Maxim Vasiliev commented

2019-11-24 15:41:46 +01:00

System Information
Operating system: Linux-5.0.0-36-generic-x86_64-with-debian-buster-sid 64 Bits
Graphics card: GeForce GT 730/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 418.56

Blender Version
Broken: version: 2.81 (sub 16), branch: master, commit date: 2019-11-20 14:27, hash: 26bd5ebd42
Worked: (optional)

Short description of error
When a custom node class is inherited from a base class, it breaks the base clas.

class MyNodeBase(bpy.types.ShaderNodeCustomGroup):
    ...    

class FooNode(MyNodeBase):
    bl_idname="my.foo"
    bl_label = "foo"

class BarNode(MyNodeBase):
    # this get broken if any derved class exists
    bl_idname="my.bar"
    bl_label = "bar"

class BazNode(BarNode):
    # this works but breakes BarNode
    bl_idname="my.baz"
    bl_label = "baz"

Attempt of creating BarNode results in:

WARN (bpy.rna): /home/sources/buildbot-x86_64-slave/linux_glibc217_x86_64_cmake/blender.git/source/blender/python/intern/bpy_rna.c:8164 bpy_class_call: unable to get Python class for RNA struct 'my.bar'
Traceback (most recent call last):
  File "/home/qmax/Heap/3d/test.blend/nodes.py", line 23, in execute
RuntimeError: Error: Cannot add node of type my.bar to node tree 'Shader Nodetree'

Exact steps for others to reproduce the error

open attached file and execute packed nodes.py
call operator 'add bar' in shader editor

test.blend

Workaround

Register classes in reverse order: derived first, then base.

classes = (BazNode, BarNode, FooNode)

for c in classes:
  bpy.utils.register_class(c)

**System Information** Operating system: Linux-5.0.0-36-generic-x86_64-with-debian-buster-sid 64 Bits Graphics card: GeForce GT 730/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 418.56 **Blender Version** Broken: version: 2.81 (sub 16), branch: master, commit date: 2019-11-20 14:27, hash: `26bd5ebd42` Worked: (optional) **Short description of error** When a custom node class is inherited from a base class, it breaks the base clas. ``` class MyNodeBase(bpy.types.ShaderNodeCustomGroup): ... class FooNode(MyNodeBase): bl_idname="my.foo" bl_label = "foo" class BarNode(MyNodeBase): # this get broken if any derved class exists bl_idname="my.bar" bl_label = "bar" class BazNode(BarNode): # this works but breakes BarNode bl_idname="my.baz" bl_label = "baz" ``` Attempt of creating `BarNode` results in: ``` WARN (bpy.rna): /home/sources/buildbot-x86_64-slave/linux_glibc217_x86_64_cmake/blender.git/source/blender/python/intern/bpy_rna.c:8164 bpy_class_call: unable to get Python class for RNA struct 'my.bar' Traceback (most recent call last): File "/home/qmax/Heap/3d/test.blend/nodes.py", line 23, in execute RuntimeError: Error: Cannot add node of type my.bar to node tree 'Shader Nodetree' ``` **Exact steps for others to reproduce the error** - open attached file and execute packed nodes.py - call operator 'add bar' in shader editor [test.blend](https://archive.blender.org/developer/F8161935/test.blend) **Workaround** Register classes in reverse order: derived first, then base. ``` classes = (BazNode, BarNode, FooNode) for c in classes: bpy.utils.register_class(c) ```

Maxim Vasiliev commented

2019-11-24 15:41:46 +01:00

Added subscriber: @qwiglydee

Maxim Vasiliev commented

2019-11-24 16:33:28 +01:00

The workaround is to register classes in reverse order: first 'baz', and then 'bar'.

This is crazy.

The workaround is to register classes in reverse order: first 'baz', and then 'bar'. This is crazy.

Philipp Oeser commented

2019-11-25 13:27:14 +01:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2019-11-25 13:27:14 +01:00

Confirmed on first sight, checking...

Philipp Oeser commented

2019-11-25 13:51:15 +01:00

Added subscribers: @JacquesLucke, @ideasman42

Philipp Oeser commented

2019-11-25 13:51:15 +01:00

Before digging deeper: @JacquesLucke : this not to be expected, right?
The ptr->type->py_type doesnt seem to be set...

Maybe this rings a bell immediately?

CC @ideasman42

Before digging deeper: @JacquesLucke : this not to be expected, right? The `ptr->type->py_type` doesnt seem to be set... Maybe this rings a bell immediately? CC @ideasman42

Jacques Lucke commented

2019-11-26 08:55:45 +01:00

Unfortunately, I'm not sure what's going one.
I have a habbit of subclassing all the classes I want to register directly from the bpy.types... base class, instead of having an intermediate super class. Maybe this is why I never had this problem (or the problem is why I have this habbit...).

Unfortunately, I'm not sure what's going one. I have a habbit of subclassing all the classes I want to register directly from the `bpy.types...` base class, instead of having an intermediate super class. Maybe this is why I never had this problem (or the problem is why I have this habbit...).

Philipp Oeser commented

2019-11-28 16:40:04 +01:00

Added subscriber: @mont29