Texture node editor header is not in sync with edited texture when used with node materials #39868

New Issue

Willi · 2014-04-23T23:02:42+02:00

Willi commented

2014-04-23 23:02:42 +02:00

System Information
Win 7/64, AMD HD 6850

Blender Version
since 2.63

Short description of error
see title

Exact steps for others to reproduce the error
Open TxtNodeEditor.blend (including UI).
Description of the scene: The default cube/mesh has two materials:

Material.001 is a normal material (no nodes)
Material.002 is a node material. It contains a material node referencing Material.003.

Steps:

In the material properties panel, select Material.001
Switch to the texture properties panel: It has two textures assigned.

Select Texture.001 and Texture.002 alternatively: The Texture nodes editor correctly switches between the two node textures. This is labeld in the bottom left of the window. In addition, in the header, the combobox shows the currently selected texture. If you select the 3rd texture slot which is still empty, the header correctly shows no current texture.

So far, so good. Now, what does not work in opposite:

In the material properties panel, select Material.002
In the material nodes editor, select the material node

In the properties window, switch to the texture panel: It has two textures assigned. As you see at the top of the window: "Cube -> Material.002 -> Material.003", so we should be working with the texture slots of Material.003 now. Problem: This does not work identically to working with the texture slots of Material.001 as we did above regarding the header of the texture nodes window: It does not display and manage the texture of the currently selected texture slot of Material.003. Instead it is (probably) managing the textures of the superordinated Material.002. In any case the header is not in sync with the content of the correctly displayed nodes in the window.

**System Information** Win 7/64, AMD HD 6850 **Blender Version** since 2.63 **Short description of error** see title **Exact steps for others to reproduce the error** Open [TxtNodeEditor.blend](https://archive.blender.org/developer/F85761/TxtNodeEditor.blend) (including UI). Description of the scene: The default cube/mesh has two materials: - Material.001 is a normal material (no nodes) - Material.002 is a node material. It contains a material node referencing Material.003. Steps: - In the material properties panel, select Material.001 - Switch to the texture properties panel: It has two textures assigned. # Select Texture.001 and Texture.002 alternatively: The Texture nodes editor correctly switches between the two node textures. This is labeld in the bottom left of the window. In addition, in the header, the combobox shows the currently selected texture. If you select the 3rd texture slot which is still empty, the header correctly shows no current texture. So far, so good. Now, what does not work in opposite: - In the material properties panel, select Material.002 - In the material nodes editor, select the material node # In the properties window, switch to the texture panel: It has two textures assigned. As you see at the top of the window: "Cube -> Material.002 -> Material.003", so we should be working with the texture slots of Material.003 now. Problem: This does *not* work identically to working with the texture slots of Material.001 as we did above regarding the header of the texture nodes window: It does not display and manage the texture of the currently selected texture slot of Material.003. Instead it is (probably) managing the textures of the superordinated Material.002. In any case the header is not in sync with the content of the correctly displayed nodes in the window.

Willi commented

2014-04-23 23:02:42 +02:00

Changed status to: 'Open'

Willi commented

2014-04-23 23:02:42 +02:00

Added subscriber: @willi-2

Willi commented

2014-04-23 23:07:12 +02:00

Pictures say more than words...:

The marked combo is what I'm talking about. I expect Texture.003 to be selected there like it is shown and labeled in the window, and selecting a different texture in that combo should assign it to the selected texture slot of Material.003

Pictures say more than words...: ![Bild_311.JPG](https://archive.blender.org/developer/F85763/Bild_311.JPG) The marked combo is what I'm talking about. I expect Texture.003 to be selected there like it is shown and labeled in the window, and selecting a different texture in that combo should assign it to the selected texture slot of Material.003

Bastien Montagne commented

2014-04-24 08:37:53 +02:00

Added subscriber: @mont29

Lukas Tönne commented

2014-04-26 11:43:05 +02:00

Added subscriber: @LukasTonne

Lukas Tönne commented

2014-04-26 11:43:05 +02:00

This is because of the convoluted nesting of materials and textures in nodes vs. plain stacks ...

What is displayed in the header is the texture's material's "active_texture" property. In the case of a "classic" stack-based material this is the texture slot (which works fine). But for node materials it instead uses the active node and then if that is a texture node displays that node's texture reference ... So without having a texture node selected in the material nodes it won't show a texture in the header either, and will never use the stack ...

I'm not yet sure how to properly disentangle this mess, it's a creepy web of legacy design issues.

This is because of the convoluted nesting of materials and textures in nodes vs. plain stacks ... What is displayed in the header is the texture's material's "active_texture" property. In the case of a "classic" stack-based material this is the texture slot (which works fine). But for node materials it instead uses the active node and then **if** that is a texture node displays that node's texture reference ... So without having a texture node selected in the material nodes it won't show a texture in the header either, and will never use the stack ... I'm not yet sure how to properly disentangle this mess, it's a creepy web of legacy design issues.

Lukas Tönne was assigned by Sergey Sharybin

2014-04-28 10:11:58 +02:00

Sergey Sharybin commented

2014-04-28 10:11:58 +02:00

Added subscriber: @Sergey

Sergey Sharybin commented

2014-04-28 10:11:58 +02:00

Consider this a TODO then?

Lukas Tönne commented

2014-04-29 16:46:46 +02:00

Have been looking into this and found a lot of bad stuff under the surface ...

The Material.active_texture property, which is displayed in the texture nodes header, has inconsistent behavior:

*# get checks if nodes are used, then looks up the active node and its texture pointer, otherwise returns the stack texture slot (correct)
*# set checks if nodes are used, but if it cannot find an active texture node it will fall back to setting the active texture stack slot! This is not transparent and confusing to users.
*# editable does the same as set: if nodes are used and no active texture node is found, it will return true anyway, assuming a texture slot will be set instead. This means that the tex node header button does not get grayed out, which would at least indicate there is something missing (no active tex node).

What's more: The function for looking up the active texture node (nodeGetActiveID) only returns a node if the texture is actually non-NULL (https://developer.blender.org/diffusion/B/browse/master/source/blender/blenkernel/intern/node.c$2352). What this means is that active_texture can never work properly for setting a texture node's texture pointer for the first time!

It all goes totally nuts if you consider nesting of materials inside material nodes, mixing stack- and node-based materials/textures etc. I don't even dare think about what impossible cases could come up here ...

Have been looking into this and found a lot of bad stuff under the surface ... # The Material.active_texture property, which is displayed in the texture nodes header, has inconsistent behavior: *# `get` checks if nodes are used, then looks up the active node and its texture pointer, otherwise returns the stack texture slot (correct) *# `set` checks if nodes are used, but if it cannot find an active texture node it will fall back to setting the active texture stack slot! This is not transparent and confusing to users. *# `editable` does the same as `set`: if nodes are used and no active texture node is found, it will return true anyway, assuming a texture slot will be set instead. This means that the tex node header button does not get grayed out, which would at least indicate there is something missing (no active tex node). What's more: The function for looking up the active texture node (`nodeGetActiveID`) only returns a node if the texture *is actually non-NULL* (https://developer.blender.org/diffusion/B/browse/master/source/blender/blenkernel/intern/node.c$2352). What this means is that active_texture can never work properly for setting a texture node's texture pointer for the first time! It all goes totally nuts if you consider nesting of materials inside material nodes, mixing stack- and node-based materials/textures etc. I don't even dare think about what impossible cases could come up here ...

Sergey Sharybin commented

2014-04-30 12:08:55 +02:00

@LukasTonne, do you need some help here?

Lukas Tönne commented

2014-05-01 16:07:58 +02:00

@Sergey i was going to unify the get/set/editable behavior, such that if use_nodes is true, it would never even look at the stack slots (so that a material is either nodes or stack, not some weird mixture). However this could easily break some cases, this stuff is used in so many places.

And then i found out about the nodeGetActiveID and realized this couldn't even work the way i expected it to ...

So atm i'm thinking "never ever touch this, it will break more than it could fix". If you have a clear idea of how this should work, be my guest and give it a shot.

@Sergey i was going to unify the get/set/editable behavior, such that if use_nodes is true, it would never even look at the stack slots (so that a material is either nodes or stack, not some weird mixture). However this could easily break some cases, this stuff is used in so many places. And then i found out about the `nodeGetActiveID` and realized this couldn't even work the way i expected it to ... So atm i'm thinking "never ever touch this, it will break more than it could fix". If you have a clear idea of how this should work, be my guest and give it a shot.

Lukas Tönne commented

2014-07-08 18:22:25 +02:00

Changed status from 'Open' to: 'Archived'

Lukas Tönne closed this issue

2014-07-08 18:22:25 +02:00

Lukas Tönne commented

2014-07-08 18:22:25 +02:00

Closing as archived, this area of the code is too encrusted with old hacks and fragile use cases to justify breaking it for a non-showstopper ...

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Texture node editor header is not in sync with edited texture when used with node materials #39868

The Material.active_texture property, which is displayed in the texture nodes header, has inconsistent behavior: