Image data socket type to improve node groups reusability
Is it possible to add an input socket for image data in order to make node groups more reusable?
Right now if you want to change an image that is contained in a node group you have to expand the content of the node group and then change it from there, paying attention not to change anything else possibly ruining a complex node setup.
I imagine it looking something like this:
I would imagine that something like this would greatly improve reusability and sharing of node groups.
Edit: it would also be nice to have something like this for float curves, RGB curves and color ramps
Edit 2: Here is an example of a situation where I think it would be useful:
The nodes I circled are a way of mapping the same texture in the XY, YZ and XZ planes so that I have a material that is independent of UV coordinates, I use this all the times. To achieve this, I am now forced to use two node groups and three image texture nodes. With what I am proposing, all of that would become a single node group (with a single image data input, a float scale input and a vector rotation input) that is always just two clicks away.
9 Comments
I always place images (and other resources) outside nodegroups so you can change its mapping. Adding it to a socket input would not work for me.
I do see some benefits for curves, but that would clutter the interface.
How would you solve this without cluttering/reserving a lot of space?
It's still a normal node group if you find it cluttered you can still edit it like before leaving the curve inside the group
Also I very often find myself having to use the same image with different mapping, when I have to change one I have to change all of them so this would solve the problem
developer.blender.org/T93905
I have not yet used geometry nodes very much, so I wasn't aware that the image datablock socket already existed, if they can also implement that for material nodes it would be awesome!
But this still doesn't make curves and color ramps have an input socket and while I don't use those as much it would be nice to also have those as an input in a node group.
I think separating image data from mapping/settings (interpolation, projection, extrapolation) actually makes a lot of sense here. In production workflows, those two concerns are often handled independently anyway.
For example, when working with real-world 3D scan data, we often reuse the same texture across multiple setups but need different mapping depending on the final output. Keeping image data as a flexible socket while leaving mapping external would avoid a lot of duplication without forcing extra UI complexity inside the node group.
Especially in pipelines where you process multiple assets with similar structures, having reusable node groups with swappable image inputs would save a lot of time. We’ve run into this quite a bit when preparing scanned models for full-color 3D printing—texture consistency vs. mapping flexibility becomes a constant balancing act.
If anyone is interested in how scanned textures translate into final physical models, this is a workflow example: 3dynamik.ch/ — it highlights how important clean texture handling is once you move beyond just rendering. — it highlights how important clean texture handling is once you move beyond just rendering.
While I do agree with this I'm not sure how easy or difficult it would be to implement this. The node group would have to show the other texture options (interpolation, projection and extrapolation) as well as adding a new socket type that as far as I can imagine would only be useful for creating node groups. Similar issues would arise for the other nodes mentioned.
I know this isn't ideal but I would continue using color input/output for textures and create a node group for the complex vector setup and post processing that way only 3 nodes would be used (image texture, vector node group, post process node group) assuming this is the main issue based on the images provided.
They have started the planing process to allow these menu-based settings to be sockets.
I think the image mapping options (interpolation, projection and extrapolation) and image data should be separated and for the time being I would be happy having only the image data as a socket. It's not often I change the other settings