Texture Sample Pointer
separate vector from image data reference for easier node group reuse! Instead of having to make a thousand copies of your node group with countless names for separate textures and texture sets, you can just have one with your desired controls. If you still like having those textures in a group, it's easy to make that into a group without having to fiddle with copy, rename, change textures... Some of these groups are pretty complex and use many textures that all have to be manually fiddled with and it bloats the node group lists. Tabbing into the groups is lame and slow.
It's easy to append a bunch of textures and hook them up to your node group. That's what this would do. Preferably, the mapping, projection, color space, etc could be over-ridden in the proposed node if set.
6 Comments
Ok, so there's a fair amount of speculation here in the comments... The reason this cannot work now is because there are no input socket types that can pass these parameters. We have color, float, integer, vector and shader sockets.
What this would require is add a socket able to pass data bock ID's and rna properties. So the "proposed node" is basically the current image node with a socket that replaces the file open spot and a new node that simply stores and passes those into the socket.
This is basically how Unreal Engine 4 does it in their material system and it's fantastic to reuse shaders and material functions with instance copies that simply pass a texture as a programmable parameter. Blender's node groups are basically identical to material functions already, but there is no convenient way to replace textures without diving into the node groups and making copies of it for every single texture or set of textures.
The whole point is to move the image texture selector outside of the node group so you can do more with less node group copies that do exactly the same thing. It also means if you want to use the same texture several times, it's just a socket at the top of the group. Pick once, store one data block for it, use it in the group however you like.
Multiple vector inputs? Sure. Set up the node group. A full PBR set? No problem, add those sockets. Want the roughness to scale differently? Set it up in the node group so you can scale each texture independently with float sockets to multiply nodes on the vectors. All this does is move the File Open control outside the group, like being able to add an arbitrary file dropdown for every texture used to the node group UI, but that actually would get confusing. A socket with a label and a connected node is more obvious and easier to understand for the average user without adding new UI elements that are drastically different from the node system.
Thumbs up!! I actually I did propose that as well blender.community/c/rightclickselect/bFcbbc/
As in @lluc84 proposal, more options extrapolated from the texture node would be better: you could re-utilize the same text-node for different purposes (box mapping and uv mapping for example)
I agree that texture node should be only pointer. But what about, if i want to mix two texturew with different mappings? Tiled bricks and procedural noise for example? How did you make it with new system?
* @ Vyacheslav *
From what I'm understanding, you would have two texture inputs and two texture references feeding them. You could then do the mapping in the node group (possibly from additional inputs, if that's what you want.)
* @vasiln * In this case you should make same 2 mappings. So this idea allows to make nodes with automapping with changed textures, but not decrease amount of nodes.
may be, there should be just «STR input» and image texture input for swithcing to another texture if need