Image Texture unpredictable behavior in Workbench renderer when duplicating node #74713

New Issue

Casey Connor · 2020-03-13T06:44:34+01:00

Casey Connor commented

2020-03-13 06:44:34 +01:00

System Information
Operating system: Linux-4.18.0-25-generic-x86_64-with-debian-buster-sid 64 Bits
Graphics card: GeForce GTX 1060 6GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 390.116

Blender Version
Broken: version: 2.83 (sub 6), branch: master, commit date: 2020-03-03 18:38, hash: 31aefdeec5

Short description of error
Duplicating an Image Texture node causes the displayed image texture to go all white in Workbench renderer

Exact steps for others to reproduce the error

see attached .blend demo

fresh blender start, delete cube
switch to workbench renderer
enable Import Images as Plane, import test image (attached)
go in to shader editor
select image texture, duplicate it
remove image selection from the image texture node, observe that texture in viewport goes all white
behavior is unpredictable when selecting different nodes

Demo video:
image_texture_issue.mp4

Source image:

.blend file:
image_texture_issue.blend

**System Information** Operating system: Linux-4.18.0-25-generic-x86_64-with-debian-buster-sid 64 Bits Graphics card: GeForce GTX 1060 6GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 390.116 **Blender Version** Broken: version: 2.83 (sub 6), branch: master, commit date: 2020-03-03 18:38, hash: `31aefdeec5` **Short description of error** Duplicating an Image Texture node causes the displayed image texture to go all white in Workbench renderer **Exact steps for others to reproduce the error** see attached .blend demo * fresh blender start, delete cube * switch to workbench renderer * enable Import Images as Plane, import test image (attached) * go in to shader editor * select image texture, duplicate it * remove image selection from the image texture node, observe that texture in viewport goes all white * behavior is unpredictable when selecting different nodes Demo video: [image_texture_issue.mp4](https://archive.blender.org/developer/F8403168/image_texture_issue.mp4) Source image: ![images_as_plane_bug.png](https://archive.blender.org/developer/F8403169/images_as_plane_bug.png) .blend file: [image_texture_issue.blend](https://archive.blender.org/developer/F8403171/image_texture_issue.blend)

Casey Connor commented

2020-03-13 06:44:34 +01:00

Added subscriber: @clepsydrae

blender-admin commented

2020-03-13 06:44:34 +01:00

#75427 was marked as duplicate of this issue

Germano Cavalcante commented

2020-03-13 15:27:23 +01:00

Added subscribers: @Jeroen-Bakker, @mano-wii

Germano Cavalcante commented

2020-03-13 15:27:23 +01:00

I can confirm.
I'm not sure which criteria Workbenck uses to choose the texture node. (I imagined it would be the last selected texture).

Manual informs that it chooses the active texture:
https://docs.blender.org/manual/en/latest/render/workbench/color.html#color

If this is the case, it seems that defining the active texture is somewhat unpredictable.

@Jeroen-Bakker, bug, known issue or works as designed?

I can confirm. I'm not sure which criteria Workbenck uses to choose the texture node. (I imagined it would be the last selected texture). Manual informs that it chooses the active texture: https://docs.blender.org/manual/en/latest/render/workbench/color.html#color If this is the case, it seems that defining the active texture is somewhat unpredictable. @Jeroen-Bakker, bug, known issue or works as designed?

Germano Cavalcante commented

2020-03-13 20:45:07 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Germano Cavalcante commented

2020-03-13 20:45:07 +01:00

I analyzed the code and this is really a bug involving depsgraph and "COW".

I analyzed the code and this is really a bug involving `depsgraph` and `"COW"`.

Germano Cavalcante commented

2020-04-08 14:52:39 +02:00

Added subscriber: @Omer-Almadani

Sergey Sharybin commented

2020-05-07 16:04:15 +02:00

Added subscriber: @Sergey

Sergey Sharybin commented

2020-05-07 16:04:15 +02:00

@mano-wii, What are the details, what is going wrong?

Germano Cavalcante commented

2020-05-07 16:41:23 +02:00

In #74713#926158, @Sergey wrote:
@mano-wii, What are the details, what is going wrong?

Following the video you should have two texture nodes.
Check the nodeSetActive function and see which node receives the NODE_ACTIVE_TEXTURE flag when selecting it.
It is always the last selected node texture.

Now notice the nodeGetActiveTexture function that is called by the Workbench.
The node name with the NODE_ACTIVE_TEXTURE flag is another.

I haven't investigated this problem for a while, but I suspect that when comparing the IDs you realize that the difference is that one is the COW and the other is the original.

> In #74713#926158, @Sergey wrote: > @mano-wii, What are the details, what is going wrong? Following the video you should have two texture nodes. Check the `nodeSetActive` function and see which node receives the `NODE_ACTIVE_TEXTURE` flag when selecting it. It is always the last selected node texture. Now notice the `nodeGetActiveTexture` function that is called by the Workbench. The node name with the `NODE_ACTIVE_TEXTURE` flag is another. I haven't investigated this problem for a while, but I suspect that when comparing the IDs you realize that the difference is that one is the COW and the other is the original.

Sergey Sharybin commented

2020-05-07 17:05:45 +02:00

There is no ID comparison or difference is happening in the dependency graph. The only issue I do see which is related to dependency graph is that removing texture from the node (clicking on the X) does not tag relations for update. I would not call it a dependency graph problem since the issue is not in the graph: someone need to call DEG_relations_tag_update() in the proper place. But this is separate issue (which must be fixed, but which is not the root cause of this bug).

Now, to isolate whether something is caused by missing relations update tag or ID update tag: save and reload. If bug does not happen after save and reload it might be a missing update tag (either in the dependency graph, or in other area which might be doing caching). Here it seems save and reload after removing the texture does not solve the problem. So you can be quite sure this bug is not related to dependency graph update/evaluaiton.

Now when you mention nodeSetActive(). This function does check for a proper texture ID, so clicking on a node which does not have texture it will not become active. But this function is not called when you remove the texture from node: nodeSetActive() is not called when you click on "X".

What happens is: duplicating node makes the new one active. Deleting texture from this node does not affect the node active state, so you are ending up with a situation when active node has no texture ID.

If the viewport is designed to use active texture in workbench mode, then this actually seems a proper behavior: the node is active and it does not have texture.

We can try changing active texture when you removed texture from node, but think this will cause more confusion than solve issues. Imagine situation:

You duplicate node, it is selected and active. And you expect it to become the one which defines viewport.
You click on "X".
The system tries to be smart and picks up another texture node for the viewport. Which one would that be -- you wouldn't know.
You set node to use new texture, but since it is inactive node nothing will happen.

The last point can be addressed by doing if ((node->flag & NODE_ACTIVE) && node->id != NULL) { in nodeGetActiveTexture, but it does not solve the confusion that after clicking on "X" some other random texture will be used in the viewport.

There is no ID comparison or difference is happening in the dependency graph. The only issue I do see which is related to dependency graph is that removing texture from the node (clicking on the X) does not tag relations for update. I would not call it a dependency graph problem since the issue is not in the graph: someone need to call `DEG_relations_tag_update()` in the proper place. But this is separate issue (which must be fixed, but which is not the root cause of this bug). Now, to isolate whether something is caused by missing relations update tag or ID update tag: save and reload. If bug does not happen after save and reload it might be a missing update tag (either in the dependency graph, or in other area which might be doing caching). Here it seems save and reload after removing the texture does not solve the problem. So you can be quite sure this bug is not related to dependency graph update/evaluaiton. Now when you mention `nodeSetActive()`. This function does check for a proper texture ID, so clicking on a node which does not have texture it will not become active. But this function is not called when you remove the texture from node: `nodeSetActive()` is not called when you click on "X". What happens is: duplicating node makes the new one active. Deleting texture from this node does not affect the node active state, so you are ending up with a situation when active node has no texture ID. If the viewport is designed to use active texture in workbench mode, then this actually seems a proper behavior: the node is active and it does not have texture. We can try changing active texture when you removed texture from node, but think this will cause more confusion than solve issues. Imagine situation: - You duplicate node, it is selected and active. And you expect it to become the one which defines viewport. - You click on "X". - The system tries to be smart and picks up another texture node for the viewport. Which one would that be -- you wouldn't know. - You set node to use new texture, but since it is inactive node nothing will happen. The last point can be addressed by doing `if ((node->flag & NODE_ACTIVE) && node->id != NULL) {` in `nodeGetActiveTexture`, but it does not solve the confusion that after clicking on "X" some other random texture will be used in the viewport.

Germano Cavalcante commented

2020-05-07 17:18:15 +02:00

The problem that I considered here was not to do with node without texture (by pressing the X).
You can add another texture to the other node if you prefer.
The problem I see is that the active texture is not the last one selected (as seen in 2.79)
image_texture_issue_2_79.blend

(When I mentioned comparing IDs I mean to manually compare the values of "same nodes" in the IDE)

The problem that I considered here was not to do with node without texture (by pressing the X). You can add another texture to the other node if you prefer. The problem I see is that the active texture is not the last one selected (as seen in 2.79) [image_texture_issue_2_79.blend](https://archive.blender.org/developer/F8518569/image_texture_issue_2_79.blend) (When I mentioned comparing IDs I mean to manually compare the values of "same nodes" in the IDE)

Sergey Sharybin commented

2020-05-07 17:34:20 +02:00

So it's nothing to do with duplication at all then, and the issue is in the selection operator, which does modifications without telling anyone about it.

P1375: Fix for #74713

diff --git a/source/blender/editors/space_node/node_select.c b/source/blender/editors/space_node/node_select.c
index 53938ff4d41..0471e489926 100644
--- a/source/blender/editors/space_node/node_select.c
+++ b/source/blender/editors/space_node/node_select.c
@@ -53,6 +53,8 @@
 
 #include "MEM_guardedalloc.h"
 
+#include "DEG_depsgraph.h"
+
 #include "node_intern.h" /* own include */
 
 /* -------------------------------------------------------------------- */
@@ -549,6 +551,7 @@ static int node_mouse_select(bContext *C,
     }
     ED_node_set_active_viewer_key(snode);
     ED_node_sort(snode->edittree);
+    DEG_id_tag_update(&snode->edittree->id, ID_RECALC_COPY_ON_WRITE);
 
     WM_event_add_notifier(C, NC_NODE | NA_SELECTED, NULL);
   }

So it's nothing to do with duplication at all then, and the issue is in the selection operator, which does modifications without telling anyone about it. [P1375: Fix for #74713](https://archive.blender.org/developer/P1375.txt) ``` diff --git a/source/blender/editors/space_node/node_select.c b/source/blender/editors/space_node/node_select.c index 53938ff4d41..0471e489926 100644 --- a/source/blender/editors/space_node/node_select.c +++ b/source/blender/editors/space_node/node_select.c @@ -53,6 +53,8 @@ #include "MEM_guardedalloc.h" +#include "DEG_depsgraph.h" + #include "node_intern.h" /* own include */ /* -------------------------------------------------------------------- */ @@ -549,6 +551,7 @@ static int node_mouse_select(bContext *C, } ED_node_set_active_viewer_key(snode); ED_node_sort(snode->edittree); + DEG_id_tag_update(&snode->edittree->id, ID_RECALC_COPY_ON_WRITE); WM_event_add_notifier(C, NC_NODE | NA_SELECTED, NULL); } ```

blender-admin commented

2020-05-11 15:29:41 +02:00

This issue was referenced by 27e3361eb5

This issue was referenced by 27e3361eb5399dc1a700d7f05d5b7b329bc4eafd

blender-admin commented

2020-05-11 15:29:41 +02:00

This issue was referenced by 4d677ec90d

This issue was referenced by 4d677ec90d7abc686a143e6ec1f9737ebb6d3397

Germano Cavalcante commented

2020-05-11 15:36:08 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Germano Cavalcante closed this issue

2020-05-11 15:36:08 +02:00

Germano Cavalcante self-assigned this 2020-05-11 15:36:08 +02:00

Thomas Dinges added this to the 2.83 LTS milestone 2023-02-08 16:38:06 +01:00

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

Image Texture unpredictable behavior in Workbench renderer when duplicating node #74713