A little help about blender-custom-nodes HOT 13 OPEN

good news: i did a first 2.8x working version of the glsl node
here the diff file (i successfully compiled it with the last blender version in master branch)
glsl_node.diff.zip
there is still memory leak, if someone want to investigate...
starting to have fun with it:

The initial pattern (the one in backdrop) is a shadertoy shader
I'll made some other shaders to test the node and validate the concept.

from blender-custom-nodes.

just added an option to choose between internal text datablock (from the script editor) or external file.
It's been hard and I think it's probably dirty but I've learn a lot about the blender code :-)
If someone more experienced could give me a feedback I would appreciate it.

from blender-custom-nodes.

Corrupted diff.

from blender-custom-nodes.

Here is the updated diff so far for 2.8

GLSL_Compositor_P1.zip

from blender-custom-nodes.

I recompiled blender under linux with your diff and the actual master branch (with some small changes again since your version) but with the same result. It works as soon as we don't set a shader :-/

This glsl node could be very useful to make a basic substance designer workflow in blender as i mentioned here: https://blender.community/c/rightclickselect/DHdbbc/
I want to use it to write some texture node.

i'll continue to investigate but i don't have a clue.

from blender-custom-nodes.

@3dsman are there any plans to contribute the diff into upstream blender?

from blender-custom-nodes.

i only worked on the 2.8 port, the big work has been done by @bitsawer , i'm not very legitimate to do that.
I'm not totally sure of what i've done too, it's only my second blender code participation and there is still memory leak.
Adding a new node to blender official seems not so easy and i think this one need some more improvement to be really usable (the shadertoy code should be store in the blender file as text block for exemple)
I forked the official blender repo to simplify work on it and compilation (and there is a fix since the diff i pushed here)
https://github.com/3dsman/blender shadertoy_node branch

from blender-custom-nodes.

@feliwir we need it work in background too if we want to make a proposal to the blender official dev team.
maybe the new eevee renderer unlock the situation by enabling opengl in background mode (i understood that was the problem in 2.79) but i'm not sufficiently aware of the blender code to know.
My hope is that @bitsawer rework on it to have something that he could pull request.
I don't understand all this node code so i don't think to be able to improve it sufficiently.

from blender-custom-nodes.

@3dsman Thanks I will try to catch it ASAP.

good news: i did a first 2.8x working version of the glsl node
here the diff file (i successfully compiled it with the last blender version in master branch)
glsl_node.diff.zip
there is still memory leak, if someone want to investigate...
starting to have fun with it:

The initial pattern (the one in backdrop) is a shadertoy shader
I'll made some other shaders to test the node and validate the concept.

from blender-custom-nodes.

@cgvirus you should use my fork (just cherry pick), i fixed an issue of this patch (in the diff node takes only the first input texture :-/)
if you find the memory leak source you can fix or tell me ;-)

from blender-custom-nodes.

i just found an issue with buffer groups, one of my glsl node, inside a group return bad result when i activate buffer groups option.
This will need more investigations.

from blender-custom-nodes.

okay, for the memory leak it seems to be known as there is a comment "//Never freed" in wm_window_create_main_queue() (source/blender/windowmanager/intern/wm_window.c)

debug information seems to match with a thread memory leak:
Error: Not freed memory blocks: 3, total unfreed memory 0.125397 MB
ThreadQueue len: 152 0x7f1d3212d1b8
BLI_gsqueue_new len: 64 0x7f1d349cb2b8
BLI_gsqueue_push len: 65528 0x7f1ce4653538

But i don't know how threads work in blender and where we can free those objects
For the buffer group issue i still investigate

from blender-custom-nodes.

Just fixed the memory leaks
For the buffer group issue it seems that inputs are badly handled by glsl node within a group when buffer group option is activated (it get black input)
I don't know why for the moment

from blender-custom-nodes.