Page MenuHome

CustomType(bpy.types.NodeSocketColor) causes sever lags when Shader Editor open simultaneusly with View3D
Closed, ArchivedPublic


System Information
Operating system: windows 8 64 bit
Graphics card: render with CPU, notebook integrated

Blender Version
Broken: 2.8, cc5bdf029324, 17.03.2019
Worked: also doesn't work in 2.79{F6837574}

Short description of error
registering MySocketClass(bpy.types.NodeSocketColor) and instantiating this in the NodeShaderEditor leads to severe lags when the ShaderEditor is open simultanesouly with another ShaderEditor window, View3D, or Compositor. There are no lags when it's the only window open of the laggy type (View3D, ShaderEditor, Compositor)

Exact steps for others to reproduce the error

  1. run the script (the cube must be active for the script to run)
  2. if shader editor and View 3d are open together, you'll notice the lags.
  3. if you now close one of them, the lag goes away.

Also some infos on the lags and performance depending on which window is open simultaneously with the ShaderEditor:

  • Image Editor: no lags
  • UVEditor: no lags
  • ShaderEditor -> lags, first very slight but if more windows are opened, the lags become very severe
  • Compositor -> no lags at first, lags when more compositor windows are opened
  • Texture Node Editor -> very slight lags, even with many windows open
  • Movie Clip -> no effect
  • 3D View -> very strong lags

Please, also note, that the whole thing crashes my PC after some time. this crash isn't a freeze, however, it rather looks as if UI elements of Windows are not drawn correctly any longer. PC also does not respond to clicks but one can notice that the tasks still run correctly.



Event Timeline

Sergey (sergey1994_m) closed this task as Resolved.Mar 17 2019, 7:15 AM
Sergey (sergey1994_m) claimed this task.
This comment was removed by Sergey (sergey1994_m).
Sergey (sergey1994_m) reopened this task as Open.Mar 17 2019, 7:21 AM
Sergey (sergey1994_m) updated the task description. (Show Details)

solved 'no default value' error by overriding this property in my custom class but rerendering each frame didn't go away

I'll try to take a look into this, but as far as I know, custom sockets are still incompatible with the buildin engines (unless they just have a single uniform).
My sugestion is to avoid custom sockets completly until they are supported. Try to use only _NodeSocketColor, NodeSocketFloat and NodeSocketVector_ to preserve total compatibility with Eevee, Cycles, and Compositor.

To get rid of the'default_value' warning, you need to add a _default_value_ property to the socket class. Making a variable with that name is simply not enough.

Example in the Socket:

default_value: bpy.props.FloatVectorProperty(name="defaul_value", default =(0.0, 0.0, 0.0, 0.0), min=0, max=1, subtype="COLOR_GAMMA", size=4)

Thank you, Miguel. Setting the property helped to get rid of the error, but, unfortunately, rerendering does not go away. when you are saying that custom sockets are incompatible with the building engines, what exactly do you mean? because the socket does output the color properly, it is just updating the cycles renderer each frame. By the way, you cannot see this rerendering in EEVEE but you still feel how it is lagging in FPS.
VERY IMPORTANT: if you close the shader editor, the bug completely disappears! I have just taken a very brief look into internal code but from my feeling (maybe I am wrong) it is the self.layout of the custom socket that is sending the draw updates that somehow conflicting with the 3d viewport. anyways, I find it very interesting that keeping only 3d viewport or shader editor open removes the bug: maybe this will be a good hint for you. Thanks again!

regarding the standard socket types: unfortunately, I cannot go with it, because I draw UI in my custom sockets that is essential to the node that I am trying to build.

I'm still saying that there's no bug. There's no support for custom sockets, so using them is the real bug here.
If you want we can create a thread in the devtalk, for discussing this with deeper thoughts.

Just one last thing before we create the thread: the node sockets are already doing what I want them to do. Take a look at the screenshot: the layer stack is internally mixing two layers, and, if I connect more, it works perfectly. I can paint in those layers in EEVEE as well. That's why I would like you to expalin a bit more, what you mean with 'not supported'. You mean to say that this works by coincidence? the only problems are the lagging and the insert_link that simply doesn't work. If I understand you correctly and this shouldn't work at all because of no support, then I would definitely like to create the thread

a quick edit to avoid misunderstanding: by saying 'custom sockets', I don't mean

socket.type = 'CUSTOM'
``` but

which is

MySocketInstance.type = 'RGBA'

for example. we do mean the same thing or don't we?

Sergey (sergey1994_m) renamed this task from 'no default value found' error spamming in CustomType(bpy.types.NodeSocketColor) to CustomType(bpy.types.NodeSocketColor) causes sever lags when Shader Editor open simultaneusly with View3D.Mon, Mar 25, 5:32 AM
Sergey (sergey1994_m) updated the task description. (Show Details)

@Brecht Van Lommel (brecht), @Sebastian Parborg (zeddb), @Miguel Porces (cmporces), I have updated the task after some observation, hope it will be useful... Also, if you don't have enough capacity now, could you please tell me, where in the code should I take a look for the possible bug? I think, it has something to deal with a procedure that draws the viewports? thank you

The reason that you still can register a NodeSocketColor as a type, is because it's 'internally registered' as a NodeSocket... but there are some structures/variables that are not defined in the api. The absence of those structures/values causes all sort of errors in every module that depends on them. That's why it's still an _unsupported_ feature.

@Miguel Porces (cmporces) ok, it's clear now, thank you for your feedback and explanation! Then probably I should close this report, and we can then open the new thread in the devtalk as you have previously suggested?

Brecht Van Lommel (brecht) claimed this task.

I'm not too familiar with this, but indeed probably best to consider this as a possible improvement rather than a bug.