Unfortunately there seem to be no incentive to add all the new good stuff happening to geo-nodes into mat-nodes. What you need to base calculations on are the dimensions. You could try to obtain them using geo-nodes (bounding box → vector math max-min → attribute, or something like that) and feed that into a material. By all means, drivers might work too to read the dimension parameters, but I would try to avoid drivers if at all possible. I’m at no position to test this myself right now though.
2 Likes
Yes that is great to be able to input calculations from Gn.
But CarlG does have a point.
Why cant we have a random value node in the shader editor as well?
I know we can make a geometry node that just outputs a random value as an attribute, but what is the point of the extra work?
For what situations do you need a RandomValueNode in the Materials?
Isn’t the WhiteNoise sufficient? (it’s a purely pseudo-random value generator) 
1 Like
To get random integers, booleans, select a range, controllable random vectors (with range inputs) without needing to use additional math nodes. 
While we are at it a switch node? (if possible with a selection for the number of of options to switch through-not just boolean)
I am sure that if I try I could come up with many examples of the new geometry nodes that would be great to have in the shader editor.
Oh… and the ability to copy past compatible node types from one editor to another, math nodes etc.
There are more nodes in the new geometry node system than in the age old shader editor 
I am with Carl that the shader nodes need more love.
2 Likes
Boolean operators, switch, scene time, a decent viewer (that ignores color management exposure and curves with setting for RAW or sRGB), compare node (differs from math/compare), support for integers, as in general providing better options for what get exposed to the user. I’m fine with White Noise as random value generator even if a Random Value node is more compact, except maybe Value output could generate a 4th parameter rather than a copy of the 1st (of 3).
Similarly, compositing nodes are lacking behind; no blackbody or wavelength (less useful, but still) nodes, old mix node. It’s color operators on YCbCr and YUV (and nonexisting LAB) could be useful elsewhere to create derivatives.
Just asking for nodes to be a bit more unified, and think a bit outside the box wrt usefulness.
Ok, THAT I didn’t even know about. I was convinced the only way was to obtain and store attributes in geo nodes and read them back in. Where can I find a list of attributes I can access this simple way? Are lamp data available for lamp based emission shaders too?
3 Likes
Yeah, me either, apart from fuel, temperature and col,
heres a list of some more… I cant find much in the manual, actually the manual links to this stack exchange thread!
1 Like
@CarlG, @DNorman You both have some good points there, and I also think that there’s plenty more that we could have in terms of nodes. Of course some things might be more difficult to implement than others, and some might produce undesired repercursions. But for simple things like a Switch node, a better RandomNode or BooleanOperations (for the shader editor), they can be implemented with ease (I’ve been using python nodes for such and other operations for years). There’re some other stuff that I also would like to have in the Shader Editor, like the hability to use matrices and so on (not really a problem, since I mostly use OSL for such structures).
There’s also the difficulty of creating new shader nodes (which are different from geo-nodes) and require a bit more work for them to work correctly between CPUs and GPUs.
The Compositor, for example, could really have better and more interesting nodes. But as the engine is being revamped, I can only hope that they leave room for such nodes.
In terms of Copy/Paste between different Editors (or different nodetree types)… I don’t know how that could work. Some systems have their own way of processing the nodetree, that isn’t always compatible with the other systems.
As said in the documentation, most Integer, Float, Booleans and Vectors (colors are vectors) properties can be accessed with the Attribute node (just as we use them in drivers). Some paths are used differently than the Python API, for example, accessing a value in an object’s modifier needs the modifier’s index and not the modifier’s name…
ex: modifiers[0].affect vs modifiers['Bevel'].affect
Other than that, the python console is a good help (it’s better than the Outliner since you get the real API name of the properties… not the GUI name).
In a similar way to the example above, you need to find the index of the Light in the ViewLayers’ Object collection, and use the ViewLayer in the AttributeNode…
Python console:
#find index of 'Light.007'
>>> bpy.context.scene.view_layers['ViewLayer'].objects.find('Light.007')
>>> 42
The Path in the AttributeNode objects[42].data.color will output the color of that light; objects[42].data.shadow_soft_size will output the radius when it’s a PointLamp; etc.
PS: Some of this is still something relatively new, and the depsgraph might miss updating dependencies when a property changes.
4 Likes
Yes I understand that it would not be so simple as copy paste for some nodes, maybe more like “export” “import” where you call a nodes equivalent.
I also understand that devs have a never ending work load but I do agree with CarlG in that unifying the compatible progress would be good.
What bugs me is the inconsistencies between the node editor types.
Why do we have utilities for GN, and convertors for shaders?
Why is vector math a utility in GN, but not a convertor for shaders?
I get that there are some fundamental differences that are tough to match up between the two node editors, but theres a whole lot of overlap that doesn’t need to be different.
I use the keyboard shortcuts a lot, and the shortcuts are completely different which makes it really hard to learn/remember
A math node in Shaders: Shift+a,n,a
A math node in GN: Shift+a,u,h
A value node in shaders: Shift+a,i,v
A value node in GN: Shift+a,i,a
I know the shortcuts are automatically generated, but the categories can be more consistent.
2 Likes
Unfortunatelly those inconsistencies are even worse when you look into the source code…
The rapid development of GeoNodes brought new developers to Blender, but without a proper knowledge of how the previous system worked, we now have different systems everywhere.
In terms of UI/UX (Python stuff), the GeometryNodesEditor uses a different system of menus than the other builtin systems. And changes to the original system breaks addons for custom NodeTrees… I personally gave up this battle, since in my case I have +300 nodes in the ShaderEditor alone, and I needed a menu system that would have nested categories. Of course that I need to track for new Nodes and reposition then in the categories that seem fit, whenever a new Blender comes out.
In terms of the C/C++ code, the same thing happened, and the geonodes are written in C++, while the old ones are still written in C. A total mess, in my opinion.
And Blender is not the only place such things happen. Whenever you have a rapid development over an old System that alone has plenty of dependencies on other stuff, things eventually get out of hand; and without a proper project managment, we end up with 10000 ways to do more or less the same.
ps.: This conversation is getting outside the scope of this thread, so if any moderator around, feel free to split the talk.
5 Likes
Is there a reason why general Node updates that are happening in Geonodes aren’t happening in Shader editor? Like new Image Texture Node and image info nodes, they’re only listed as Geonodes thing, why not in Shader Editor? is it that hard to add it there?
It is such a hassle to work with Shader Nodes, having a node group with image in it is a pain in the ass. And all the features we are waiting for are being added, but only for Geonodes. Why? Things like Random Value node, Viewer Node, boolean inputs for groups.
Shader Editor seems abandoned right now. Is it?
You can try White Noise.
No need for that. Just Ctrl+Shift+LMB on a node you want to preview.
No but it’s just that GN is developping very fast so there are a lot of improvements.
Shader nodes, geo nodes ans compositor nodes shares some code but each one of them have their own set of nodes.
changes in one aren’t always propagated to the other even when that can make sense.
Probably because even if they operate on the same type of data from an user POV, the context is very different.
A mix float node in shader editor ( Eevee ) is part of OpenGL code ( the shader) but in GN it’s some operation on mesh data… I suspect that each of these node get their own optimisation based on the data they work on. Having the same node for the 3 editor would probably mean something slow and clunky …
It’s just wild guess here !
2 Likes
There is absolutely a need for Viewer Node. That shortcut just connects the output to Shader Input, which means when you remove it you have to go back to what you had before and connect in again. That is a tiresome process in which you have to travel across the node editor back and forth for everything. Deleting the Viewer Node and getting back to what is connected to the Shader Input would speed up my workflow significantly. I feel like most of my time is spent on scrolling left and right to “View” this or that node. I can’t stress enough how much I hate that behavior.
White Noise doesn’t allow you quick range control like Random Value node does. Making it pretty much useless in most cases.
That was my understanding as well, and I’m glad Geonodes is developing at this speed, I use Geonodes too. But I spend most of my time (after 3D View) in Shader Editor and its just papercuts everywhere. And I read its fixed, get excited and turns out its only getting fixed in the Geonodes.
If Shader Editor is responsibility of the Paint & Sculpt module then it is pretty much abandoned yes, since there’s almost no one working on it. I was getting so excited for 3.5 to finally have booleans and new Image inputs for Image Texture nodes, but turns out I won’t be getting it, at least for another half a year, but seeing the speed Shader Editor is developing right now I don’t even expect it then.
There should be some additional work done on implementing those new features in Shader Editor in time, for consistency’s sake at least.
Yeah it’s weird that blender relies on node wrangler for that for such a long time, but that’s how life goes …
For sure many areas in blender need some love, just as shader editor, and shader in general there are tons of addition for either faster workflow, less hacks, or better results. Doing these improvements will always end up with some people complaining since budget invested in one area is an investment not done in another one.
And for booleans in shading, I think there is a little hack with python that allow to change the socket type if you really need it !
I share my materials often, so I don’t want to use hacks and cause potential problems. And I get your point about someone always complaining, but there needs to be some balance I guess. Shading & Painting is by far most underdeveloped part of the blender right now, and its also one of the most used ones for artists. Reading 2023 plans doesn’t get me excited either, there’s not even mention of improving anything there.
You don’t need to remove it. You can have multiple output nodes. Just select one and it will become active.
I know it’s still a workaround, and I agree that the shader nodes could use some more attention.
There is a topic here for issues about the various node editor inconsistencies:
1 Like
Last comment there is really damning. The situation seems even worse than I expected. It seems I’ll have to dive more into Substance Designer and external compositor software learn it better, because way its described, and given how little core developers care about Shader Editor it could take years before something is done. I’m so tired of this broken workflow
Patience is a virtue with open source software. Development happens in surges in different areas, and steady pressure from the users does have an impact (particularly if it is constructive feedback 
)
But having more tools in your toolbox is also good, so I encourage you to check out SD and other compositing software as well. But I wouldn’t be too quick to fully abandon blender, check back in every few months and you might be surprised.
1 Like
It is not all bad news, there are some initiatives to work on textures, we do have to be patient though.
(we are a bit off topic here)
2 Likes