Question about Shader Editor

I agree, features on core sdk is maintainable, far better than jmb but the problem is knowing how to deal with netbeans modules and build the sdk for testing (this is another dilemma).

Whatever the case, if the “path to enhancing shader nodes UI” is not documented then the next guy will come along and write his own, get it almost to the point of where the current ones are, then abandon it, etc…

Everyone always wants to dive into the “new hotness” without spending even a minute looking at what’s already there if it isn’t push-button ready. It’s unfortunate. (I fall into this trap all the time myself so I’m not being critical just pointing out an unfortunate truth.)

The SDK version needs a hero that will spend an hour or two trying to build the SDK and either document the process or document the issues.

…though honestly, I think the biggest issue with the SDK shader nodes is that it doesn’t have a PBR j3sn and some other quality of life j3sn defs… and that’s something that would benefit any shader nodes editor (or even those who just want to compose a shader in code).

The barrier of entry for that is significantly lower as you shouldn’t need to build the SDK just to implement those, I think.

3 Likes

I rather spend those hours on jfx and learn the design pattern of a simple desktop software, maybe that is my opinion, but you are right everything needs to be documented properly (i have intentions to build a simple wiki for jmb).

I took the leap and built the SDK from source to fix some issues. It’s not that difficult (but I remember thinking so a couple of years ago).

In any case, I’m working on some SDK issues now, but the Shader Editor is interesting and I can take a look at that next. Feel free to describe the issues so that I or someone else who feels inclined can start working on them with minimum effort.

4 Likes

And we are aware that SDK can be a bit hassle to build. You need to follow the instructions to the letter. We are also in the process of making this easier with a bit of modern magic. Hopefully it will be a success.

After that there is only the psychological fear of coding NB platform code and having it all in IDE that is not sexy at this given time. Minds are the most difficult thing to turn.

2 Likes

Hi everyone, I’m happy with the new initiatives that are coming out. I hope you will soon find a solution to easily maintain and evolve the SDK.

I did some other tests. The tool to create new Shader Nodes does not work.

Nothing happens when you click on the Next button.

No problem, I created an empty file and named it PBRLighting.j3sn.
Next step. I wrote a prototype template:

ShaderNodeDefinitions{
    ShaderNodeDefinition PBRLighting {      
        Type: Fragment
        Shader GLSL100: MatDefs/PBRLighting.frag
        Documentation{
            PBR Lighting Template
            @input position
            @input albedo
            @input normal
            @input emission
            @input metallic
            @input smoothness
            @input occlusion
            @input alpha
            @input alphaClipThreshold
            @output outColor
        }
        Input {
            vec3 position vec3(1.0)
            vec3 albedo vec3(1.0)
            vec3 normal vec3(1.0)
            vec3 emission vec3(0.0)
            float metallic 0
            float smoothness 0.5
            float occlusion 1
            float alpha 1
            float alphaClipThreshold 0
        }
        Output {
            vec4 outColor
        }
    }
}

Now we need to write the PBRLighting.frag file. I need your help writing the fragment shader function please. (This file colorMutl.frag can be useful as reference).

void main(){
    outColor = ....;
}

Good news: the newly created Shader Nodes are visible in the editor. There is no need to recompile the SDK. With your help, we can probably find a solution ready to use with the editor we already have.

6 Likes

I took a look at the Shader Node Editor last night and read some forum threads. I can’t believe it’s close to 10 years old!

In my view, the biggest “problem” is that what you’re editing is the material definition, not a material. So it’s another layer of abstraction compared to, for example, blender, and difficult to preview the results (since it doesn’t have default values (or am I wrong?))

Apart from that I found a couple of bugs, but nothing major.

What are the expectations on the editor? How can using it be simplified?

2 Likes

Material definitions can definitely have default values. I don’t know if shader nodes supports them or not.

1 Like

I wasn’t able to set any on the MatParam node (through the gui). In that case it would be a useful feature to add.

2 Likes

I think the shader nodes support default values. You can see it from ColorMult, where the default value of the input colors is white → vec4(1.0)

ShaderNodeDefinitions{
    ShaderNodeDefinition ColorMult {      
        Type: Fragment
        Shader GLSL100: Common/MatDefs/ShaderNodes/Basic/colorMult.frag
        Documentation{
            Multiplies two colors
            @input color1 the first color
            @input color2 the second color            
            @output outColor the resulting color
        }
        Input {
            vec4 color1 vec4(1.0)
            vec4 color2 vec4(1.0)
        }
        Output {
            vec4 outColor
        }
    }
}

But there isn’t a way to change those values inside the editor, right? You can add a MatParam as input, but can’t change its value.

Correct, in the editor (gui) it didn’t seem possible to set any value. Can only be done in the ‘Text’ tab.

I found this design document, maybe it can be useful:

2 Likes

I stopped supporting this jMB ShadeNode tool after rejecting my PR to jME with GLSL AST processor :slight_smile: without it, I didn’t see any good option to implement really flexible shader tool editor.

2 Likes

could you explain why without GLSL AST change you dont see any good option? i seen there was Java api branch, so why not just like this.

also link to pr would be nice.

I think it should be this one:

2 Likes

well, if im not wrong (looking at features) @RiccardoBlb wanted to add similar things(extend shader language kind of) into Shaders to be able make const loops/etc more easy way. But here i see its about namespaces additionally. But I dont understand point 1.

I stopped supporting this jMB ShadeNode tool after rejecting my PR to jME

@javasabr Who rejected the PR?

@sgold, here is the link to the discussion in case you want to take a look:

4 Likes

looking at discussion it was like about making Shader nodes more simple for Artist, while Paul and Nehon said that it will make Shaders less flexible/modular, because Shader nodes are not split into smaller Nodes. Well it is right.

but… Well, why not just have both? smaller + bigger nodes? i dont see a problem. (ofc except maintaining more)

but still, is it unable to just create custom Nodes currently that will be easier for artists you got?

myself i just need PBR Node like in blender(but can be different ofc). This is like missing build-in feature for me. IDK how to make PBR with current Shader Node elements.

I mean, if we would provide PBR/etc Nodes i dont see why for most shaders would need create ANY custom Shader Node. We could just add existing blocks without writing any shader code.

I understand that developer might want “edit” within PBR Node lets say, but in most time, you dont need - you just need modify params for it.

I written many custom shaders based on existing PBR, but i dont use Shader Nodes because i would need create many custom “nodes” there so its easier for me to just edit single-file shader. Thats the fact, idk how others think.

So maybe we should just have Second Layer of Abstraction for Shader Nodes to compromise both. (and editor for it ofc)

2 Likes