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
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.
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;
I want to get some basics up and running, and troubleshooting a small shader is simpler than a large one.
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.
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)
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.
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.
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).
thanks, indeed it would be nice to have almost every shader node definition , and just connect them in editor instead creating new ones. IMO There should be many of it within JME core just for people use.
I don’t mind writing more of these, if people have ideas for them, and then perhaps make a PR for core eventually. Or if it could somehow be incorporated into the SDK instead.
