Question about Shader Editor

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

I agree with this.

I personally tried using shader nodes with Nehon’s SDK editor back when it worked and was a new tfeature to the SDK, but I quickly realized many of my ideas would require custom nodes that didn’t exist, so I still had to learn a lot of glsl code anyways. Then I realized it was easier for me to put an important glsl function in a simple .glslib file rather than turning it into a whole shader node.

However using shader nodes was an excellent way to learn how to write basic shaders if you inspect the code it generates for you. But past that, I personally found that, as a coder, its more convenient and more flexible to code your shaders (especially if you’re forking an existent shader) and import any necessary functions from a .glslib file

So I think Javasabr’s point of making a shader node editor in a way thats easier for artists actually makes more sense since non-coder artists are the ones who need a visual editor most, because IMO coders (who are skilled enough and have the time to spare) are better off learning to write shaders with code and ignoring shader nodes altogether. But they are definitely great for cases where someone cannot or does not want to invest the time to learn GLSL code.

3 Likes

They’re also fantastic for porting shaders across backends (eyeing up tricky OpenGL version advancements or a Vulkan backend here). If all materials are defined in shader nodes and all rendering backends provide the framework for compiling shader nodes to shaders, then your shaders are portable across all backends (both existing and future ones). If you hand-write GLSL code you potentially have to evolve your shader for every backend.

2 Likes

I didn’t see this problem as well :slight_smile:

1 Like

That’s a very simple preprocessor directive that is already merged in the master.

Just saying here that i am not against improved shader nodes or more advanced abstractions,as long as they don’t impact the possibility to write “normal” glsl shaders, since for most things, if you are already a shader developer, writing a monolithic shader from scratch is simpler and allows for better optimization.

Also, this seems a very complex structure, we must consider that having it in core means someone will have to maintain it when the core changes. It might be worth to consider if it can be built as an external library and make the required changes to the core (if needed) to make it possible

7 Likes

Regarding the AST, someone is going to have to remind me why we would need this in the core engine… because you may be thinking of something specific and it may not have even been part of the original proposal.

In general, ASTs can be used in two different directions: parsing the code or generating the code.

Raw GLSL code is essentially unparsable in an AST because of the #ifdefs and so on. You either have to presuppose some specific values or have a two-layer AST. So either you make something super super complicated or limit it to code without preprocessor directives (which to me is dead on arrival at that point).

For generation, an AST does not need to be in the engine and could be separate. The engine is going to want glsl code and that can be constructed however you like… externally.

So the people on this thread that think “Hey, this AST thing sounds really cool” are going to have to elaborate on what specifically they think it’s getting them that cannot be achieved in simpler ways.

5 Likes

I decided that, if I’m going to work on the Shader Editor, I needed to learn how the ShaderNodes worked (again).
Now, this is a stripped down version of PBRLighting and everything isn’t working yet. I’m not even sure it’s possible with the current Shader Editor. For example, it turns out black now, because there are no lights. Either I’m missed something, or there’s no dummy light in the editor (I don’t see any other shader nodes with light). Also LightProbes are a mystery, so far, but I haven’t dug that deep, yet.

I said it was stripped down. For two reasons;

  1. I want to get some basics up and running, and troubleshooting a small shader is simpler than a large one.
  2. It makes sense with the ShaderNode system. More functionality can be hooked up with separate nodes.

Currently skinning is removed as is the SpecGloss pipeline. And it only supports single pass lighting.
I’m also still sorting out the switches. So there’s some more work to be done before I’ll PR this. But progress is progress.

7 Likes

Thanks for investigation @rickard

i belive there was light option, but since it was not PBR updated, then i think Light Probe is missing for preview there.

Tho it looks really “big” for just displaying PBR, and when add custom things into it, it would look much bigger. Anyway if it would be possible with GUI edit for light probe/etc, it might work at least.

Tho if we gonna think about newcomers, it should be much more simple to configure. well, it might be some template, but i think we would still need some more abstraction layer.

Dont know how many of you used Blender Nodes, but there is one nice idea.

  • It is Group Node as i remember, where it is Node configured with other Nodes. So lets say all your screenshot here, would be just 1 Node that receive params and return color/position. - and it would be possible to just enter it and see all logic inside. (world params we could provide inside this Node(it would look almost same what you got on screenshot), so user not looking inside its logic, would just need provide user params(matparams/attributes)
    But this would require much edit of Editor.(or rather be able to have kind of Shader Node inside Node in Shader Node)
2 Likes

Hi @rickard , any news on the subject? :grinning:

In the meantime I have found some interesting sites to practice with, but then everything needs to be converted to jme style.

Hope you can find an integrated solution for our IDE. Keep us updated with your progress.

1 Like

Some progress, yes. I’ve been away for a week so not much has happened since the last update.

A couple of issues;

  • I can’t use the LightPosition and LightColor WorldParams. Maybe they’re not set in the editor.
  • I rely heavily on Defines for the textures (as does PBRLighting). The alternative would mean a lot of nodes. The problem is that the editor deletes any Defines when you change the layout. This makes it improbable that PbrNodes can be used to any great extent in the current version of the SDK.
  • The editor has become unresponsive to textual changes. I need to close and reopen the SDK. This was not an issue earlier in the development.

I still haven’t looked into LightProbes.

As @oxplay2 pointed out, “it looks really ‘big’”. That’s unfortunately a side effect of the current ShaderNode system. You need to build things from the ground up. I believe the discussion in the other ShaderNode thread was about being able to create pieces of shader nodes that could be put together in a hierarchical structure. That would make things simpler.

Still, I think there is potential in the editor. Even if “Group Nodes” would require quite a lot of work, if you could just zoom out more, you could structure your nodes in groups. Maybe add labels.
Then being able to tweak MatParams in the graphical ui would help a lot.
Generators, for procedural textures would make for a powerful ShaderEditor.

5 Likes

I had completely forgotten I was supposed to share these once they were “useful”. With the release of SDK 3.4 they should mostly be so, but there’s still one big feature for the Shader Node Editor coming in 3.5 (which should be imminent).

I haven’t worked on them for quite a while, but I believe the lighting issues were resolved in the end.

https://library.jmonkeyengine.org/#!entry=2653%2FPbrNodes

4 Likes

so you say we can already test changed in 3.4, while some feature will be in 3.5? What feature is it?

Not that i will write shaders now, but once i move from code to shaders, i will give it a try.

as i understand i will need just SDK 3.5 and this files:
https://library.jmonkeyengine.org/#!entry=2653%2FPbrNodes

I think the main thing in 3.5 is “previews” for colors and textures in the widgets, but there’s a bunch of tweaks too in there. Looking at the commit it seems also the ability to set values for all types of matparams in the gui didn’t make it into 3.4.
3.4 contains a bunch of fixes like correct sorting for the shader node definition, materials updating “live” (for animated shaders), the possibility to use “Define” (which was crucial for PbrNodes).

1 Like

But wait, there’s more!

Here are some shader node definitions I created while testing out the Shader Editor:

Sine Wave Generator, Mandelbrot Generator (very useful!), Schlick and DiscardAlpha nodes.

2 Likes