Don't affect Render Result when switching image editors to an active image #99493

New Issue

Simon Thommes · 2022-07-06T17:39:23+02:00

Simon Thommes commented

2022-07-06 17:39:23 +02:00

The behavior to change image editors to the active image texture when selecting it in the node editor/as the canvas for texture painting currently affects all visible image editors.

In general, for the long term, I think it would be nice to have a more explicit relation between editors and their context for how these sync up.
But how this behavior is currently causing issues is that this also affects image editors showing the render result (or viewer node for example). Specifically also the image editor of the Blender Render window that is created temporarily with an F12 render.

Screen Recording 2022-07-06 at 16.27.09.mp4

There are different ways this could be fixed.
Temporary windows could be skipped, image editors showing the render result or viewer node could be skipped or this could utilize the pinning functionality in some way.
That's why I'm creating this as a design task after chatting with @JulianEisel and @JulienKaspar .

I'm not sure if this should be handled as a bug or so.

CC @ideasman42 , @lichtwerk

The behavior to change image editors to the active image texture when selecting it in the node editor/as the canvas for texture painting currently affects all visible image editors. In general, for the long term, I think it would be nice to have a more explicit relation between editors and their context for how these sync up. But how this behavior is currently causing issues is that this also affects image editors showing the render result (or viewer node for example). Specifically also the image editor of the `Blender Render` window that is created temporarily with an F12 render. [Screen Recording 2022-07-06 at 16.27.09.mp4](https://archive.blender.org/developer/F13262927/Screen_Recording_2022-07-06_at_16.27.09.mp4) There are different ways this could be fixed. Temporary windows could be skipped, image editors showing the render result or viewer node could be skipped or this could utilize the pinning functionality in some way. That's why I'm creating this as a design task after chatting with @JulianEisel and @JulienKaspar . I'm not sure if this should be handled as a bug or so. CC @ideasman42 , @lichtwerk

Simon Thommes commented

2022-07-06 17:39:23 +02:00

Added subscribers: @JulienKaspar, @JulianEisel, @lichtwerk, @ideasman42, @SimonThommes

Julien Kaspar commented

2022-07-08 11:54:56 +02:00

There are apparently also other open to do's related to these features: D12540

There are apparently also other open to do's related to these features: [D12540](https://archive.blender.org/developer/D12540)

Simon Thommes commented

2022-07-11 16:11:55 +02:00

@JulienKaspar I see that broadly this topic is a long term goal to be figured out entirely. But I was hoping that the specific issue that I meant to point out here which is that the render result in the default render window is switched automatically for a texture would be a relatively simple to address part of the issue that could be more short term.

Personally, working with shader nodes and render results all the time, this has been bugging me for some time. It also doesn't seem like a very controversial part of the issue to me and from the perspective of somebody that isn't familiar with the code it seems like something that would be relatively simple as well.

So I think it would be great if this could be tackled a rather short term to alleviate the issues of the current the situation.

@JulienKaspar I see that broadly this topic is a long term goal to be figured out entirely. But I was hoping that the specific issue that I meant to point out here which is that the render result in the default render window is switched automatically for a texture would be a relatively simple to address part of the issue that could be more short term. Personally, working with shader nodes and render results all the time, this has been bugging me for some time. It also doesn't seem like a very controversial part of the issue to me and from the perspective of somebody that isn't familiar with the code it seems like something that would be relatively simple as well. So I think it would be great if this could be tackled a rather short term to alleviate the issues of the current the situation.

Julien Kaspar commented

2022-07-11 17:10:33 +02:00

Makes sense. I'll tag some people in the chat to see if somebody can pick this one up.

Philipp Oeser commented

2022-07-12 19:22:43 +02:00

Agree this should be changed short-term for the Render Result.
Wont be able to address this myself atm (on parental leave for a month) though.

for the long term, I think it would be nice to have a more explicit relation between editors and their context for how these sync up

What could this mean? Dont do it for the active texture? use an operator instead (possibly mapped to {key Doubleclick}) ?

Agree this should be changed short-term for the Render Result. Wont be able to address this myself atm (on parental leave for a month) though. > for the long term, I think it would be nice to have a more explicit relation between editors and their context for how these sync up What could this mean? Dont do it for the active texture? use an operator instead (possibly mapped to {key Doubleclick}) ?

Simon Thommes commented

2022-07-13 12:40:33 +02:00

Wont be able to address this myself atm (on parental leave for a month) though.

No worries, good to know. Have a good time off with your kid :)

What could this mean? Dont do it for the active texture? use an operator instead (possibly mapped to ) ?

I haven't thought about it in full. I think that this also depends on how exactly the new texture painting workflow should look like with multiple PBR layers of one texture.
I guess the issue I am thinking of is already solved with pinning. Intuitively it just feels to me that instead of opting out of syncing with pinning the context, it would make more sense to opt in to syncing per editor.
This is also loosely connected to the discussion whether or not to allow editing node trees without a user/regardless of the context in the node editors.

> Wont be able to address this myself atm (on parental leave for a month) though. No worries, good to know. Have a good time off with your kid :) > What could this mean? Dont do it for the active texture? use an operator instead (possibly mapped to ) ? I haven't thought about it in full. I think that this also depends on how exactly the new texture painting workflow should look like with multiple PBR layers of one texture. I guess the issue I am thinking of is already solved with pinning. Intuitively it just feels to me that instead of opting out of syncing with pinning the context, it would make more sense to opt in to syncing per editor. This is also loosely connected to the discussion whether or not to allow editing node trees without a user/regardless of the context in the node editors.

Philipp Oeser self-assigned this 2022-08-22 09:11:16 +02:00

Philipp Oeser commented

2022-08-22 09:11:16 +02:00

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