A little help

[cgvirus]

Hello, Greetings. Hope everything is well.

I am trying to build your wonderful GLSL node in Blender 2.8. So far I was able to create the node and shows the red warning. But then the texture won't show up. I had to change the COM_GlslOperation.cpp a little bit as B28 gpu_texture.c has been updated.

Can you please see what may go wrong in COM_GlslOperation.cpp? I really want to push this to Blender and enhance it with your guidance and permission. Please let me know.

I have commented change where I had to change in COM_GlslOperation.cpp. So that you can easily ctrl+F to see the changes.

Here is the diff with Blender 2.8: Thank you very much for your hard work. I have learnt a lot from you.

GLSL_Compositor_diff.zip

[cgvirus]

Corrupted diff.

[cgvirus]

Here is the updated diff so far for 2.8

GLSL_Compositor_P1.zip

[3dsman]

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.

[3dsman]

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.

[feliwir]

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

[3dsman]

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

[3dsman]

@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.

[cgvirus]

@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.

[3dsman]

@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 ;-)

[3dsman]

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.

[3dsman]

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

[3dsman]

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

[3dsman]

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.