Unify Image Texture node in geometry and shader nodes #93905

New Issue

Brecht Van Lommel · 2021-12-09T16:06:12+01:00

Brecht Van Lommel commented

2021-12-09 16:06:12 +01:00

Geometry nodes added a new Image Texture node where the image datablock is a socket.

We should unify these two nodes. There are some design decision to make regarding how to deal with image users and the frame offset socket, see discussion in {D12827.}.

Geometry nodes added a new Image Texture node where the image datablock is a socket. We should unify these two nodes. There are some design decision to make regarding how to deal with image users and the frame offset socket, see discussion in {[D12827](https://archive.blender.org/developer/D12827).}.

Hans Goudey commented

2022-04-22 17:55:01 +02:00

Exposing the image as a socket adds a little more complexity in that I think the image used cannot vary per-evaluation like other options on the node like the position input. I assume that's an incorrect assumption.

To distinguish the "constant" inputs and the varying inputs, maybe it makes sense to add a concept like fields to the shader node graph.
Most sockets would become fields, but others like the image input and other inputs that are currently node properties could become non-field sockets.

This could reuse the existing field status inferencing used for geometry nodes.

Exposing the image as a socket adds a little more complexity in that I think the image used cannot vary per-evaluation like other options on the node like the position input. I assume that's an incorrect assumption. To distinguish the "constant" inputs and the varying inputs, maybe it makes sense to add a concept like fields to the shader node graph. Most sockets would become fields, but others like the image input and other inputs that are currently node properties could become non-field sockets. This could reuse the existing field status inferencing used for geometry nodes.

Brecht Van Lommel commented

2022-04-22 18:23:06 +02:00

Can you explain what the field status inferencing would do for shader nodes? I'm not sure what you mean by that exactly.

If we require there to be a fixed single image datablock per image texture node, without any links, then we can compute that as part of expanding all the group nodes into a single graph. We actually handle string sockets for Principled Volume already.

There's nothing explicitly enforcing these to be non-fields, but since there exist no nodes that can edit strings this is not a problem. I guess the inferencing becomes important once we add nodes that can e.g. switch an image or string based on an integer.

Can you explain what the field status inferencing would do for shader nodes? I'm not sure what you mean by that exactly. If we require there to be a fixed single image datablock per image texture node, without any links, then we can compute that as part of expanding all the group nodes into a single graph. We actually handle string sockets for Principled Volume already. There's nothing explicitly enforcing these to be non-fields, but since there exist no nodes that can edit strings this is not a problem. I guess the inferencing becomes important once we add nodes that can e.g. switch an image or string based on an integer.

Hans Goudey commented

2022-04-22 18:34:21 +02:00

The fields status would make that distinction explicit on the user level, making it much easier to tell which sockets can be adjusted per shader evaluation and which sockets are computed ahead of time for the whole material.

Here's a slightly contrived example:
This setup is invalid:

But this setup is totally fine:

Other inputs that this could apply to:

Attribute > Name
Sky Texture > All node properties
AOV Output > Name
Point Density > Object

Maybe some of those are pushing some fundamental limits, but the simple ones like the image socket and attribute name make a lot of sense I think.

The fields status would make that distinction explicit on the user level, making it much easier to tell which sockets can be adjusted per shader evaluation and which sockets are computed ahead of time for the whole material. Here's a slightly contrived example: This setup is invalid: ![image.png](https://archive.blender.org/developer/F13016328/image.png) But this setup is totally fine: ![image.png](https://archive.blender.org/developer/F13016337/image.png) Other inputs that this could apply to: - Attribute > Name - Sky Texture > All node properties - AOV Output > Name - Point Density > Object Maybe some of those are pushing some fundamental limits, but the simple ones like the image socket and attribute name make a lot of sense I think.

Brecht Van Lommel added this to the Render & Cycles project 2023-02-07 19:08:06 +01:00

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Unify Image Texture node in geometry and shader nodes #93905