Referenced/default nodes idea

I have been thinking the last weeks about an idea for node trees (shader/geonodes/compositing/whatever) which occurred to me a while ago.

I shy away from calling this a proposal because it’s not thought through enough and I didn’t look into the code enough to know if it’s even feasible. But I just want to bounce this idea around.

First a description of the problem I’m trying to solve.

Lots of nodes have settings or data inside them which are not exposed as a socket. For example the texture image in a texture node is not settable via a socket. The same goes for the curve in a curve node or a colorramp. This is often a problem when you try to create general purpose materials or geonodes.

We could solve this by creating datablocks for image data or float curves and exposing them as sockets. But there’s also another way. I have before created a ‘proof of concept’ for the image texture node and the way I implemented that was that I just added an extra socket to the image texture node where you could connect another image texture node to. Then when evaluating the image texture node it would take the image data from the linked node, while using it’s local settings and texture input for the texture mapping.

This gave me the idea for a generalized system to do this which I think can be very useful:

Give every node a ‘defaults’ input socket and a ‘reference’ output socket.

In the below screenshot I created a mock up of how this would look ,by (ab)using reroute nodes, where I put the defaults socket at the top of the node, and the ‘reference’ at the bottom.

The idea is that a node would get all it’s values/inputs which don’t come from an input socket on the left from it’s reference node
(I clumsily tried to look the overridden values look grayed out).

Every node would get such a ‘defaults’ and ‘reference’ node. And every node would always first check if there is something connected to it’s defaults node and copy all it’s data/inputs from there before looking at the connected inputs on itself.

If this is feasible it would solve the problem of setting these kind of data for all nodes in one go. It also would give a nice way to export all inputs of a certain kind from within a nodegroup in one socket.

You could make certain nodes in a nodegroup overridable.

Just a wild idea…

It’s really poor idea, which would introduce overcomplicated concepts and also cause extremely messy, unappealing and confusing node networks.

The texture datablock needs to be optionally separated from texture sampler node, so that the texture sampler node has an image input socket. That’s it. No need to invent ugly workarounds. It’s something that should have been done a long time ago. It works this way in Unreal Engine for example. Same applies for a curve or a ramp. They could just be a general purpose datablocks.

In fact, GN image texture node already has an image datablock input, so it’s just a matter of making shader editor counterpart consistent with it:

Thank you sir for your always positively worded and encouraging feedback :laughing:

Maybe it’s a bad idea, that’s very well possible… Though I disagree on the messyness/comlicatedness (from a user standpoint. codewise it could get messy maybe).

While this is true, the same problem exists with lots of other nodes.

Colorramp, float curve come to mind as first example.

And on top of that, this would also allow you to override the interpolation mode and extrapolation mode of the image texture. Or any property of a node not explicitly exported as a socket, for that matter.

3 Likes

More flexibility doesn’t always mean better. When you create a node group to do a specific task, you rarely want to be as specific as interpolation mode, as that’s rather implementation detail if your node group rather than what you want to think about when using your high level tool.

I mentioned both color ramp and curve as well. They can be modularized as data blocks as well.

Honestly, I think you should first look around outside of the Blender echo chamber to see how other similar systems out there work, before coming up with solutions to problems people before you already solved.

I would not generally be as negative if this wasn’t as bad of an idea. This would introduce so many issues in many different areas such as usability, visual aesthetic, learning curve, room for user error and so on. You are not seeing a true scope of the damage such a feature would do.

I (of course, or I wouldn’t write it) disagree. But that’s ok. It’s very well possible you’re right and my programmer-mind doesn’t see the difficulties other people would have.

It would be nice if you could word your objections in a somewhat friendly manner, but each his talent I guess…

2 Likes

Besides the bad UI for your proposal, with nodes weirdly placed in the top or the bottom (something I hate happening in Resolve), thing is that problem is already solved.

Images are datablocks already that can be used in a myriad of places. Every time an image texture node loads an image datablock, it can already customise how it loads and processes it.

Moreover, in your mockups is like fairly impossible to differentiate what’s a datablock going around from the color info that travels along thru the yellow dots.

We already use images outside groups and plug them into those to do whatever we need. I can somehow understand the extra flexibility of your proposal, but it would still be fixed by simply changing the image datablock (that is, replacing the image file outside Blender) which is what we actually do.

I could buy being able to have float curve datablocks that can be reused at different nodes. But I can hardly see how many practical problems would it fix rather than saving time editing a couple color ramps here and there.

Default (when no mapping node is connected) mapping for textures is already partially accessible, though it’s somewhat hidden in sidebar:

I don’t know how to change texture coordinates from uv to generated / normal / object / etc on unconnected texture node (it just remembers last connected type and uses that I guess?).

1 Like

It defaults to UV when disconnected.

Anyway, for switching between mapping modes, it’d make more sense to support enum switches, which you could expose to the top of your nodegroup.

It was only a mockup of course. Meant to explain what I meant. The sockets could be placed on other positions (left & right in the top bar?) . And the noodle given a different styling.

I think using the specific example of an image datablock was a mistake, because that one really deserves it’s own sockets as a datablock and node everybody is concentrating on that one :wink:

I often find myself using the same node in multiple places in the tree (with different inputs of course). In materials it’s quite common to have more or less the same setup multiple times (once for color, once for normals and once for roughness, for example). I find I often have the same situations in GN trees, where I need the ‘same’ node multiple times and they need to stay in sync.

In GN I often use float curves to drive the shape of things. It would be very nice if you could create a GN group which takes a float curve shape as input.

For example I have a GN group which can create various fruits. The only difference between: tomato,paprika,pumpkin,melon,cucumber,apple,pear,cherry orange are the materials and the shape of 4 float curves.

But because the float curves are embedded deep inside the tree you can’t just re-use the same group 9 times with different inputs, but you have to copy the tree for each new fruit.

This is only a single example. I’ve often found the need to use colorramps as inputs to a generic material as well.

Of course this could all be solved by adding datablocks and sockets for those things. But when I was experimenting with trying to do that in a patch (for a shader tree) I cheated by just referencing another colorramp/imagetexture node instead of creating a new datablock. This turned out very easy to implement in shader node trees (no idea if it’s easy to generalize).

And then I thought it would be nice to be able to just reference any node from with another.

But so far I think it is a quirk of my programmers brain think it would be a nice thing to have available, seeing the reactions here. :smiley:

1 Like

The way I understand it, it can be easily doable grouping the stuff you want to reuse a lot (even color ramps), it’s how I see it done in complex setups.

So if you need the same color ramp in different places, group it, expose the inputs and call it a day. And so forth.

See, the problem you have is very valid. Just the solution to it is not.

You already agree that image datablock should get its own socket. And you formulated that the main thing you are missing right now, when jumping between the nodes you want to keep in sync is curve or ramp editor.

Now, if you think about it - If we had curve and ramp as a datablock, what else would you need? I mean, don’t think about it in a way of “Someone may some day in future find to have X or Y handy”, but instead think about it in a way of “This is really necessary to have made into a socket, otherwise there’s a lot of work jumping between many nodes to keep them manually in sync”.

I’d be quite surprised if you found much more than ramp and a curve. And once you realize how few of those things actually need to be socketized, you will realize such a monstrous solution you’ve came up may not be the best to address this not such a monstrous problem.

You can’t use a colorramp as input to a group this way. My example above is not about using the same colorramp multiple times. It’s about using a group containing a colorramp multiple times with different colorramps.

Well, I started out trying to solve the first thing. And I agree completely with you that it would be a huge improvement if those two would be ‘socketized’. But the ‘general’ solution I describe above is not something someone would maybe find nice to have in the future, it’s something that I would have liked to have quite a few times already. curve/colorramp/imagedata not being socketized is maybe the real showstopper making certain classes of re-usable trees impossible. So they are indeed more important. But being able to specify ‘defaults’ for nodes (including the unsocketized parts) , while not strictly necessary to create node trees, can save a lot of tedious repetition and it does give the ability to expose anything as a pqarameter from a group.

And this is where I disagree. I don’t really see what’s so monstrous about 2 extra sockets. To me it seems like a nice generalized way to make anything exportable as parameter for a node group without needing to create sockets and specialized nodes for a myriad of special cases.

Here I disagree as well. I’d like to be able to export anything as a parameter from my generalized node groups.

But so far other people seem to agree with you :wink:

I fully agree with you. Anything not parameterizable is bad.
The interpolation mode is a good example. It is in no way too much of a detail and would be very nice to be socketized. Same for color ramp positions and colors curve point positions. In fact we should be able to feed bezier splines from the 3d scene into a curve node.

1 Like

Gotta say, gave this a second thought and I am growing on the idea of several things being socketized, like curves or ramps, not images honestly since they already are datablocks and you can input images from the outside of a group very easily.

But for other inputs and tools, yes, I can see the need.

That’s the thing though, there is no way to expose the inputs of a color ramp. And there is no way to expose a color ramp itself either, which would be the ideal solution.

In GN editor yes, but in the shader editor not yet, which is part of the problem. This needs to be made consistent.