Geometry Nodes: Unusable texture inputs? #95461

New Issue

Will · 2022-02-03T03:42:00+01:00

Will commented

2022-02-03 03:42:00 +01:00

System Information
Operating system: Biological Bobsleigh Birds (Linux)

Blender Version
Broken: 3.0, 3.20 alpha

Short description of error

As the Attribute Sample Texture Node is being removed, it doesn't appear that there is any way to use the Texture socket types that can be exposed from the modifier panel anymore:

Texture socket type added w/ Attribute Sample Texture:

https://developer.blender.org/D11222

Exposed as nodegroup input in modifier panel:

https://developer.blender.org/rB3025c348253a66f9c316259aa03f8884bf56d779

Two possible solutions:

Add Texture Sample Field node.
Make texture input output RGB.

Exact steps for others to reproduce the error

Add a "Texture" input to a Geometry Nodes group.
Try to use it in the nodegroup.

**System Information** Operating system: Biological Bobsleigh Birds (Linux) **Blender Version** Broken: 3.0, 3.20 alpha **Short description of error** As the [Attribute Sample Texture Node](https://docs.blender.org/manual/en/latest/modeling/geometry_nodes/attribute/attribute_sample_texture.html) is being removed, it doesn't appear that there is any way to use the Texture socket types that can be exposed from the modifier panel anymore: ![image.png](https://archive.blender.org/developer/F12842998/image.png) Texture socket type added w/ Attribute Sample Texture: https://developer.blender.org/D11222 Exposed as nodegroup input in modifier panel: https://developer.blender.org/rB3025c348253a66f9c316259aa03f8884bf56d779 Two possible solutions: * Add Texture Sample Field node. * Make texture input output RGB. **Exact steps for others to reproduce the error** * Add a "Texture" input to a Geometry Nodes group. * Try to use it in the nodegroup.

Will commented

2022-02-03 03:42:00 +01:00

Added subscriber: @WCN

Richard Antalik commented

2022-02-03 05:04:25 +01:00

Added subscriber: @iss

Richard Antalik commented

2022-02-03 05:04:25 +01:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Richard Antalik commented

2022-02-03 05:04:25 +01:00

This sounds like design issue rather than bug to me. If I understand this, you say, that Attribute Sample Texture was only node that could work with textures, but now there is none (non-legacy)?

Ludvik Koutny commented

2022-02-03 16:39:14 +01:00

Added subscriber: @Rawalanche

Ludvik Koutny commented

2022-02-03 16:39:14 +01:00

The node you are talking about has been replaced with Image Texture node:

Which is not planned to be deprecated. Use that one, and use your texture input attribute as its input.

The node you are talking about has been replaced with Image Texture node: ![image.png](https://archive.blender.org/developer/F12843917/image.png) Which is not planned to be deprecated. Use that one, and use your texture input attribute as its input.

Hans Goudey commented

2022-02-03 17:45:20 +01:00

Added subscriber: @HooglyBoogly

Hans Goudey commented

2022-02-03 17:45:20 +01:00

I think we'll end up removing the texture socket completely when we remove the legacy nodes "before 4.0".

The "problem" here is that it still shows up in a few places-- the group inputs and outputs list, and the switch node.

We could hide it from this list fairly easily, but I'm not sure it's worth it:

diff --git a/source/blender/editors/space_node/node_edit.cc b/source/blender/editors/space_node/node_edit.cc
index 6275e7e4656..965fbf6b36a 100644
--- a/source/blender/editors/space_node/node_edit.cc
+++ b/source/blender/editors/space_node/node_edit.cc
@@ -2464,6 +2464,10 @@ static bool socket_change_poll_type(void *userdata, bNodeSocketType *socket_type
     return false;
   }
 
+  if (socket_type->type == SOCK_TEXTURE) {
+    return false;
+  }
+
   /* Only use basic socket types for this enum. */
   if (socket_type->subtype != PROP_NONE) {
     return false;

I think we'll end up removing the texture socket completely when we remove the legacy nodes "before 4.0". The "problem" here is that it still shows up in a few places-- the group inputs and outputs list, and the switch node. We could hide it from this list fairly easily, but I'm not sure it's worth it: ``` diff --git a/source/blender/editors/space_node/node_edit.cc b/source/blender/editors/space_node/node_edit.cc index 6275e7e4656..965fbf6b36a 100644 --- a/source/blender/editors/space_node/node_edit.cc +++ b/source/blender/editors/space_node/node_edit.cc @@ -2464,6 +2464,10 @@ static bool socket_change_poll_type(void *userdata, bNodeSocketType *socket_type return false; } + if (socket_type->type == SOCK_TEXTURE) { + return false; + } + /* Only use basic socket types for this enum. */ if (socket_type->subtype != PROP_NONE) { return false; ```

Hans Goudey commented

2022-02-03 17:45:38 +01:00

Changed status from 'Needs User Info' to: 'Confirmed'

Will commented

2022-02-03 19:26:38 +01:00

In #95461#1301171, @HooglyBoogly wrote:
I think we'll end up removing the texture socket completely when we remove the legacy nodes "before 4.0".

Personally I would be disappointed at losing the ability to reuse the same nodegroup with different procedural/volumetric textures chosen in the modifier pane.

> In #95461#1301171, @HooglyBoogly wrote: > I think we'll end up removing the texture socket completely when we remove the legacy nodes "before 4.0". Personally I would be disappointed at losing the ability to reuse the same nodegroup with different procedural/volumetric textures chosen in the modifier pane.

quvr commented

2022-02-04 09:33:53 +01:00

Added subscriber: @Quver

quvr commented

2022-02-04 09:33:53 +01:00

In #95461#1301171, @HooglyBoogly wrote:
I think we'll end up removing the texture socket completely when we remove the legacy nodes "before 4.0".

Please don't! This is a very usable feature for reusable nodegroups and removing it completely is a step back to me.
Shaders currently lack this. Instead expand this functionality to shader nodes.

See
https://devtalk.blender.org/t/input-socket-for-image-texture-shader-node/19601

It’s a pity the texture Image node (all texture nodes actually) actually conflates two things: Generating/loading texture data (colors) and doing the mapping. It would be nice if there would be simple ‘texture’ node which provides the color data (and has no inputs) , and a texturing node which takes a ‘texture’ input and a ‘mapping’ vector input and outputs the same as the current (Image) Texture nodes.

> In #95461#1301171, @HooglyBoogly wrote: > I think we'll end up removing the texture socket completely when we remove the legacy nodes "before 4.0". Please don't! This is a very usable feature for reusable nodegroups and removing it completely is a step back to me. Shaders currently lack this. Instead expand this functionality to shader nodes. See https://devtalk.blender.org/t/input-socket-for-image-texture-shader-node/19601 > It’s a pity the texture Image node (all texture nodes actually) actually conflates two things: Generating/loading texture data (colors) and doing the mapping. It would be nice if there would be simple ‘texture’ node which provides the color data (and has no inputs) , and a texturing node which takes a ‘texture’ input and a ‘mapping’ vector input and outputs the same as the current (Image) Texture nodes.

Ludvik Koutny commented

2022-02-04 09:52:39 +01:00

In #95461#1301447, @Quver wrote:

In #95461#1301171, @HooglyBoogly wrote:
I think we'll end up removing the texture socket completely when we remove the legacy nodes "before 4.0".

Please don't! This is a very usable feature for reusable nodegroups and removing it completely is a step back to me.
Shaders currently lack this. Instead expand this functionality to shader nodes.

See
https://devtalk.blender.org/t/input-socket-for-image-texture-shader-node/19601

It’s a pity the texture Image node (all texture nodes actually) actually conflates two things: Generating/loading texture data (colors) and doing the mapping. It would be nice if there would be simple ‘texture’ node which provides the color data (and has no inputs) , and a texturing node which takes a ‘texture’ input and a ‘mapping’ vector input and outputs the same as the current (Image) Texture nodes.

The current "Image Texture" node is primarily what does texture sampling and mapping. It doesn't really conflate it, because the texture data block is actually exposed as a node socket input. The only issue here is that right now, this data block can only be exposed at the Geometry Nodes Group Input UI. It can not be crated within the tree in the same way you can create a float, vector and so on.

So all that would be needed would be some sort of "Texture" input node with just image texture datablock selector, which would accompany this set of input nodes:

This would make things such as triplanar displacement mapping a bit easier to do, without user having to swap image datablock manually in 3 separate "texture sampler" nodes.

The video in the thread you linked to talks exactly about that. So I would not conflate ability to use image texture as a data type in GN with the ability to use legacy procedural textures.

To wrap it up:

We need "Image Texture Input" node, both in GN and in Shader Editor
Image Texture (sampler) node in the shader editor needs Image datablock socket, in the same way GN already has it.

> In #95461#1301447, @Quver wrote: >> In #95461#1301171, @HooglyBoogly wrote: >> I think we'll end up removing the texture socket completely when we remove the legacy nodes "before 4.0". > > Please don't! This is a very usable feature for reusable nodegroups and removing it completely is a step back to me. > Shaders currently lack this. Instead expand this functionality to shader nodes. > > See > https://devtalk.blender.org/t/input-socket-for-image-texture-shader-node/19601 > > >> It’s a pity the texture Image node (all texture nodes actually) actually conflates two things: Generating/loading texture data (colors) and doing the mapping. It would be nice if there would be simple ‘texture’ node which provides the color data (and has no inputs) , and a texturing node which takes a ‘texture’ input and a ‘mapping’ vector input and outputs the same as the current (Image) Texture nodes. The current "Image Texture" node is primarily what does texture sampling and mapping. It doesn't really conflate it, because the texture data block is actually exposed as a node socket input. The only issue here is that right now, this data block can only be exposed at the Geometry Nodes Group Input UI. It can not be crated within the tree in the same way you can create a float, vector and so on. So all that would be needed would be some sort of "Texture" input node with just image texture datablock selector, which would accompany this set of input nodes: ![image.png](https://archive.blender.org/developer/F12845339/image.png) This would make things such as triplanar displacement mapping a bit easier to do, without user having to swap image datablock manually in 3 separate "texture sampler" nodes. The video in the thread you linked to talks exactly about that. So I would not conflate ability to use image texture as a data type in GN with the ability to use legacy procedural textures. To wrap it up: 1. We need "Image Texture Input" node, both in GN and in Shader Editor 2. Image Texture (sampler) node in the shader editor needs Image datablock socket, in the same way GN already has it.

Ludvik Koutny commented

2022-02-04 10:10:30 +01:00

In #95461#1301196, @WCN wrote:

In #95461#1301171, @HooglyBoogly wrote:
I think we'll end up removing the texture socket completely when we remove the legacy nodes "before 4.0".

Personally I would be disappointed at losing the ability to reuse the same nodegroup with different procedural/volumetric textures chosen in the modifier pane.

The issue is that those procedural textures are legacy remnants of Blender Internal renderer. That doesn't mean you should not have the option to swap the procedural textures at your will. There are two more GN based concepts:

You could wrap your entire GN network into a node group and expose the input for the custom procedural texture, and then easily quickly swap through any of those available in GN (which almost mirror those old BI ones):
Once GN gets proper enum handling, you could create Enum with all the GN Texture types and swap through them right in the modifier panel.

While the option 1. can feel less usable because it requires you to open a GN editor first before you can start switching and tweaking the textures, you must not forget the extreme amount of possibilities this opens. For example with the legacy textures, just mere mixing of them becomes a hell, requiring you to use multiple GN modifiers with the same GN node network, with one texture each. That's bad for both usability and performance. Let alone something like distorting the mapping of one procedural texture with another. That's pretty much impossible.

On the other hand, with GN it becomes trivial:
https://www.youtube.com/watch?v=4X4V-UUnYkM
So you trade a small reduction in ease of use by having to open node editor first to start switching texture types for giant increase in flexibility, by ability to mix, distort, blend, color correct, remap, etc... multiple procedural textures in a ways that were absolutely impossible with the legacy texture datablocks. I mean even XYZ offsetting of the texture mapping coordinates is not possible with the legacy textures, so you get whatever random seed you are stuck with, with very little option to art direct the initial state of the texture mapping.

> In #95461#1301196, @WCN wrote: >> In #95461#1301171, @HooglyBoogly wrote: >> I think we'll end up removing the texture socket completely when we remove the legacy nodes "before 4.0". > > Personally I would be disappointed at losing the ability to reuse the same nodegroup with different procedural/volumetric textures chosen in the modifier pane. The issue is that those procedural textures are legacy remnants of Blender Internal renderer. That doesn't mean you should not have the option to swap the procedural textures at your will. There are two more GN based concepts: 1. You could wrap your entire GN network into a node group and expose the input for the custom procedural texture, and then easily quickly swap through any of those available in GN (which almost mirror those old BI ones): ![image.png](https://archive.blender.org/developer/F12845345/image.png) 2. Once GN gets proper enum handling, you could create Enum with all the GN Texture types and swap through them right in the modifier panel. While the option 1. can feel less usable because it requires you to open a GN editor first before you can start switching and tweaking the textures, you must not forget the extreme amount of possibilities this opens. For example with the legacy textures, just mere mixing of them becomes a hell, requiring you to use multiple GN modifiers with the same GN node network, with one texture each. That's bad for both usability and performance. Let alone something like distorting the mapping of one procedural texture with another. That's pretty much impossible. On the other hand, with GN it becomes trivial: https://www.youtube.com/watch?v=4X4V-UUnYkM So you trade a small reduction in ease of use by having to open node editor first to start switching texture types for giant increase in flexibility, by ability to mix, distort, blend, color correct, remap, etc... multiple procedural textures in a ways that were absolutely impossible with the legacy texture datablocks. I mean even XYZ offsetting of the texture mapping coordinates is not possible with the legacy textures, so you get whatever random seed you are stuck with, with very little option to art direct the initial state of the texture mapping.

quvr commented

2022-02-04 11:07:46 +01:00

Oh, turns out there are separate "texture" sockets and the "image" sockets. I'm sorry, I thought there is only one "purple" socket type that is used for any textures (both BI and image textures). I was worried about the "Image" socket being removed.

Jacques Lucke commented

2022-02-04 13:21:01 +01:00

Added subscriber: @JacquesLucke

Jacques Lucke commented

2022-02-04 13:21:01 +01:00

Changed status from 'Confirmed' to: 'Archived'

Jacques Lucke closed this issue

2022-02-04 13:21:01 +01:00

Jacques Lucke commented

2022-02-04 13:21:01 +01:00

It's not a bug. The texture data block socket is deprecated currently. We do plan to have a new system to support sharing textures between different systems, the design for that is still being worked on.