Add a sampler data type to shader nodes
The shader nodes would be really be improved by adding a sampler data type to the set of data types it handles. For those unfamailiar with samplers, a sampler is just a reference to an image. They're used in languages like GLSL to allow you to attach an image to a shader.
Now, what's wrong with the existing Image Texture node? Well, it doesn't represent the image itself. Instead, it includes a vector as input and returns a color. This means that if you want to perform multiple UV lookups in the same image, you need to have multiple copies of the Image Texture node. It also means there is no way to pass it as a parameter - if I wanted to create a node group that lets me specify an image as an input and perform some sort of work with it, there is no way to do that. I can only work with the computed color coming out of the Texture node.
So for example, there is no way to create a node group that performs a reflection on an arbitrary texture since a) you can only work with the color output from the Image Texture node and there's no way to change the UV lookup coordinate at that point and b) there is no way to specify the image you want to operate on as an input to your node group.
There's also no way to do something like lookup multiple values from the same image without creating duplicates of the texture node.
Please extends the shading language by adding this important datatype to it.
2 Comments
Shader nodes have not been designed as a shading language and for compatibility reasons with exporters, game engines and other softwares is kept in a certain granularity. Your design might have not consider this.
Adding low-level concepts to a high level system will be very confusing in the longer run. I doubt that adding a concept like a sampler (which is much more than you're describing) would make the evaluation and clarity better.
But there are 2 projects in the making that would provide the same goals:
We are looking for bringing lower level access to shader languages using the script node. For cycles this is already possible using OSL scripts. For EEVEE we first want to settle on the shading language first that supports all platforms. After that there will be possibilities add the script node to EEVEE as well.
Also note that the texture layering project will provide access to the texture nodes in shader graphs which provides more flexibility. Hopefully this project will get priority in 2024.
Those sound like good developments for the future of custom shaders.
I suppose the point I was trying to make is that it would be useful to decouple the Texture* nodes as they exist now from their Vector inputs. That way you can use the same texture independently of a particular sampling point. Hopeful the texture nodes you're referring to will be able to do this.