Compositor : improve Viewer node behavior #108656

New Issue

Open

opened 2023-06-06 13:41:21 +02:00 by Brecht Van Lommel · 15 comments

Brecht Van Lommel commented

2023-06-06 13:41:21 +02:00

Owner

Some issue with the current design:

The backdrop only shows the output of the viewer node. This means that for simple cases, users need to manage multiple nodes.
It's not obvious when seeing the results of the viewer node that this is not what final rendering will actually output, which leads to mistakes and having to re-render.
Viewer nodes work differently in geometry, shading and compositing nodes, mainly for historical rather than good design reasons.

To address these problems, I propose to make the Viewer node behave more like the one in geometry nodes.

If there are no Viewer nodes, then image editor, 3D viewport and node editor backdrop and will show the (active) Composite output.
Like geometry nodes, the Viewer node will have a button to enable and disable it. When enabling, editors by default will show the viewer output with some visual indicator that it is a viewer.
The editors should have an overlay option to disable showing the viewer node, so it's possible to configure an editor to always show the final output with others showing the viewer output.
The "Viewer Node" image datablock will be removed.

Some issue with the current design: * The backdrop only shows the output of the viewer node. This means that for simple cases, users need to manage multiple nodes. * It's not obvious when seeing the results of the viewer node that this is not what final rendering will actually output, which leads to mistakes and having to re-render. * Viewer nodes work differently in geometry, shading and compositing nodes, mainly for historical rather than good design reasons. To address these problems, I propose to make the Viewer node behave more like the one in geometry nodes. * If there are no Viewer nodes, then image editor, 3D viewport and node editor backdrop and will show the (active) Composite output. * Like geometry nodes, the Viewer node will have a button to enable and disable it. When enabling, editors by default will show the viewer output with some visual indicator that it is a viewer. * The editors should have an overlay option to disable showing the viewer node, so it's possible to configure an editor to always show the final output with others showing the viewer output. * The "Viewer Node" image datablock will be removed.

Brecht Van Lommel added the

labels 2023-06-06 13:41:22 +02:00

Brecht Van Lommel commented

2023-06-06 13:45:14 +02:00

Author

Owner

For context, we discussed this topic in the VFX meeting with @OmarEmaraDev, @Sergey, @zazizizou. If we are going to make the realtime compositor support final render compositing and viewer nodes, now might be a good time to modernize this a bit.

@JacquesLucke, @HooglyBoogly, @dfelinto, @Jeroen-Bakker might have opinions too.

For context, we discussed this topic in the VFX meeting with @OmarEmaraDev, @Sergey, @zazizizou. If we are going to make the realtime compositor support final render compositing and viewer nodes, now might be a good time to modernize this a bit. @JacquesLucke, @HooglyBoogly, @dfelinto, @Jeroen-Bakker might have opinions too.

Brecht Van Lommel added this to the Compositing project 2023-06-06 15:09:03 +02:00

Jeroen Bakker commented

2023-06-06 15:31:49 +02:00

Member

NOTE that I am not up to speed with how geometry nodes work with viewer nodes. But consistency matters here.

Just some clarification.

Tree without viewer node -> active composite
Tree without enabled viewer node -> active composite
There can only be one enabled viewer node per tree. When multiple viewer nodes exist (node groups, linked/not linked) there should be some kind of priority. It is unclear to me what approach would be best. I think that last enabled one will be a good starting point. Even when the edit stack changes we should not switch viewers.
From user perspective there are cases where you want to have multiple viewer nodes. When tweaking in detailed level where you need to see the output from multiple nodes. I can imagine in Blender terms having a pinned viewer node could be something to considered. This requires quite some screen area. Other consideration is how to quickly switch between multiple viewer nodes. For compositing this is useful when working with masks, but want to keep track of the composite at certain points in the tree.

Side note to consider/discuss is to move the split viewer functionality to the overlay as well. Setting up split viewer and making sure that it stays connected to the desired outputs can be tricky. Ctrl-shift click can replace the link that you didn't intent to replace.

> NOTE that I am not up to speed with how geometry nodes work with viewer nodes. But consistency matters here. Just some clarification. - Tree without viewer node -> active composite - Tree without enabled viewer node -> active composite - There can only be one enabled viewer node per tree. When multiple viewer nodes exist (node groups, linked/not linked) there should be some kind of priority. It is unclear to me what approach would be best. I think that last enabled one will be a good starting point. Even when the edit stack changes we should not switch viewers. - From user perspective there are cases where you want to have multiple viewer nodes. When tweaking in detailed level where you need to see the output from multiple nodes. I can imagine in Blender terms having a pinned viewer node could be something to considered. This requires quite some screen area. Other consideration is how to quickly switch between multiple viewer nodes. For compositing this is useful when working with masks, but want to keep track of the composite at certain points in the tree. Side note to consider/discuss is to move the split viewer functionality to the overlay as well. Setting up split viewer and making sure that it stays connected to the desired outputs can be tricky. Ctrl-shift click can replace the link that you didn't intent to replace.

Philipp Oeser commented

2023-06-06 15:44:44 +02:00

Member

Note that picking up #103636 again, the issue of "only one active" (or no active at all even though the node[s] are there) comes up there as well.

Note that picking up #103636 again, the issue of "only one active" (or no active at all even though the node[s] are there) comes up there as well.

Brecht Van Lommel commented

2023-06-06 16:27:26 +02:00

Author

Owner

Just some clarification.

Tree without viewer node -> active composite

Tree without enabled viewer node -> active composite

Yes.

There can only be one enabled viewer node per tree. When multiple viewer nodes exist (node groups, linked/not linked) there should be some kind of priority. It is unclear to me what approach would be best. I think that last enabled one will be a good starting point. Even when the edit stack changes we should not switch viewers.

We can just do the same as geometry nodes here. For the simple flat node graph case, only one viewer node can be active at a time. For node groups, there is existing logic to decide which one to use. That could be made consistent with geometry nodes if it's not.

From user perspective there are cases where you want to have multiple viewer nodes. When tweaking in detailed level where you need to see the output from multiple nodes. I can imagine in Blender terms having a pinned viewer node could be something to considered. This requires quite some screen area. Other consideration is how to quickly switch between multiple viewer nodes. For compositing this is useful when working with masks, but want to keep track of the composite at certain points in the tree.

I think this came up regarding geometry nodes as well, there could be some way to have multiple viewer nodes active, and then in each editor have some way to choose between them. It's a natural extension of a single boolean, to an enum choosing between the final results and a number of viewer nodes.

But I haven't seen users requests for this, and not something I personally would spend time on.

Side note to consider/discuss is to move the split viewer functionality to the overlay as well. Setting up split viewer and making sure that it stays connected to the desired outputs can be tricky. Ctrl-shift click can replace the link that you didn't intent to replace.

I'm not sure what moving it to the overlay would mean. Would that just be for the case where you want a split view between the viewer and composite outputs? Or would you have two viewer nodes active at the same time shown in split view? It's not immediately obvious to me that this would be less finicky.

@OmarEmaraDev suggested to go in the other direction, to replace the split viewer node with a node that you can plug into a viewer node. So that the viewer node system would not be aware of split viewers at all.

> Just some clarification. > - Tree without viewer node -> active composite > - Tree without enabled viewer node -> active composite Yes. > - There can only be one enabled viewer node per tree. When multiple viewer nodes exist (node groups, linked/not linked) there should be some kind of priority. It is unclear to me what approach would be best. I think that last enabled one will be a good starting point. Even when the edit stack changes we should not switch viewers. We can just do the same as geometry nodes here. For the simple flat node graph case, only one viewer node can be active at a time. For node groups, there is existing logic to decide which one to use. That could be made consistent with geometry nodes if it's not. > - From user perspective there are cases where you want to have multiple viewer nodes. When tweaking in detailed level where you need to see the output from multiple nodes. I can imagine in Blender terms having a pinned viewer node could be something to considered. This requires quite some screen area. Other consideration is how to quickly switch between multiple viewer nodes. For compositing this is useful when working with masks, but want to keep track of the composite at certain points in the tree. I think this came up regarding geometry nodes as well, there could be some way to have multiple viewer nodes active, and then in each editor have some way to choose between them. It's a natural extension of a single boolean, to an enum choosing between the final results and a number of viewer nodes. But I haven't seen users requests for this, and not something I personally would spend time on. > Side note to consider/discuss is to move the split viewer functionality to the overlay as well. Setting up split viewer and making sure that it stays connected to the desired outputs can be tricky. Ctrl-shift click can replace the link that you didn't intent to replace. I'm not sure what moving it to the overlay would mean. Would that just be for the case where you want a split view between the viewer and composite outputs? Or would you have two viewer nodes active at the same time shown in split view? It's not immediately obvious to me that this would be less finicky. @OmarEmaraDev suggested to go in the other direction, to replace the split viewer node with a node that you can plug into a viewer node. So that the viewer node system would not be aware of split viewers at all.

Omar Emara commented

2023-06-06 17:08:54 +02:00

Member

I think the proposed design that matches Geometry Nodes is reasonable. My main concern was the old design.

However, my proposal would be to match the viewer workflow of Shading nodes instead of Geometry Nodes, that is:

Only a single output node exists, the Compositor Output node.
The compositor backdrop would just show what ever is connected to the Compositor Output node.
Users can quickly view different nodes using Ctrl + Shift + Click, just like we view nodes in shading nodes.

I think this is better due to the following. Compositor viewer usability workflow is different from Geometry Nodes. GN viewers are more like debugging tools, to inspect intermediate data in the node tree, while compositor viewers are used as a helper in construct node trees from inputs to outputs, so it makes sense that what are viewing should be the output.

Furthermore, I do not think that the GN approach would solve the mentioned issue of rendering due to mistaking the viewer output as the final output, at least I don't see how that will be different from the old way in that regard.

The fact that switching the output is very fast plus the fact that the rules are simple (What you see being viewer is what you get when rendered) makes this much simpler and less error prone to me. Moreover, it avoid the confusion of having multiple active outputs and so on.

I feel like we should ultimately get some user input on this and see which method fits the typical compositing workflow best.

In that case, the implementation of the output will be something like:

if (context->should_write_output()) {
  write_output(output_texture);
}

if (context->should_view_output()) {
  draw_output(output_texture);
}

I think the proposed design that matches Geometry Nodes is reasonable. My main concern was the old design. However, my proposal would be to match the viewer workflow of Shading nodes instead of Geometry Nodes, that is: - Only a single output node exists, the Compositor Output node. - The compositor backdrop would just show what ever is connected to the Compositor Output node. - Users can quickly view different nodes using Ctrl + Shift + Click, just like we view nodes in shading nodes. I think this is better due to the following. Compositor viewer usability workflow is different from Geometry Nodes. GN viewers are more like debugging tools, to inspect intermediate data in the node tree, while compositor viewers are used as a helper in construct node trees from inputs to outputs, so it makes sense that what are viewing should be the output. Furthermore, I do not think that the GN approach would solve the mentioned issue of rendering due to mistaking the viewer output as the final output, at least I don't see how that will be different from the old way in that regard. The fact that switching the output is very fast plus the fact that the rules are simple (What you see being viewer is what you get when rendered) makes this much simpler and less error prone to me. Moreover, it avoid the confusion of having multiple active outputs and so on. *** I feel like we should ultimately get some user input on this and see which method fits the typical compositing workflow best. *** In that case, the implementation of the output will be something like: ``` if (context->should_write_output()) { write_output(output_texture); } if (context->should_view_output()) { draw_output(output_texture); } ```

Brecht Van Lommel commented

2023-06-06 18:21:33 +02:00

Author

Owner

@OmarEmaraDev to me there two main reasons to have a viewer node instead of just a compositor output. And actually I would like to add a viewer node to shading nodes as well at some point.

With a viewer node you can set up one editor to always show the final render output from camera view, and another editor where you work and see viewer nodes, overlays, etc. This is mainly useful when working with multiple monitors and there is enough space. I think if we ask users they will say this is important to support.

Secondly, I like the idea of being able to safely inspect nodes (and any other data) without the risk of accidentally saving the .blend file in a state that might be wrong to send to a render farm. Having distinct nodes helps with that, since you don't have to remember to undo your changes. Of course the flipside is that you might forget that what you are viewing is not the final render. To help reduce the chance of this, the editors should show some indication that they are using a viewer node like info text in the 3D viewport, maybe colored if it needs to stand out more. It's not a perfect solution of course.

I agree compositing nodes are a bit different, in the sense that their output is not being further processed by anything else. With geometry nodes the geometry might feed into something else, and for shading nodes they might feed into a realtime compositing setup that makes no sense with viewer node output. But still I think there are other advantages.

We could indeed get some user feedback, maybe in the realtime compositor devtalk topic?

@OmarEmaraDev to me there two main reasons to have a viewer node instead of just a compositor output. And actually I would like to add a viewer node to shading nodes as well at some point. With a viewer node you can set up one editor to always show the final render output from camera view, and another editor where you work and see viewer nodes, overlays, etc. This is mainly useful when working with multiple monitors and there is enough space. I think if we ask users they will say this is important to support. Secondly, I like the idea of being able to safely inspect nodes (and any other data) without the risk of accidentally saving the .blend file in a state that might be wrong to send to a render farm. Having distinct nodes helps with that, since you don't have to remember to undo your changes. Of course the flipside is that you might forget that what you are viewing is not the final render. To help reduce the chance of this, the editors should show some indication that they are using a viewer node like info text in the 3D viewport, maybe colored if it needs to stand out more. It's not a perfect solution of course. I agree compositing nodes are a bit different, in the sense that their output is not being further processed by anything else. With geometry nodes the geometry might feed into something else, and for shading nodes they might feed into a realtime compositing setup that makes no sense with viewer node output. But still I think there are other advantages. We could indeed get some user feedback, maybe in the realtime compositor devtalk topic?

Jacob Merrill commented

2023-06-06 18:28:02 +02:00

I think that having multiple viewers side by side active would be nice for debugging writing 2d filters in composition nodes / FX / AOV etc.

how far away from non-blocking render are we?

I think that having multiple viewers side by side active would be nice for debugging writing 2d filters in composition nodes / FX / AOV etc. how far away from non-blocking render are we?

Omar Emara commented

2023-06-06 18:40:44 +02:00

Member

I see, so shading nodes should be also inline with GN in the future. The first reason you mentioned is convincing, and as I mentioned, your proposal seems reasonable, I was mostly concerned about the existing implementation. So we can go for your proposal as far as I am concerned, but I will make a post of devtalk regardless.

I see, so shading nodes should be also inline with GN in the future. The first reason you mentioned is convincing, and as I mentioned, your proposal seems reasonable, I was mostly concerned about the existing implementation. So we can go for your proposal as far as I am concerned, but I will make a post of devtalk regardless.

Omar Emara commented

2023-06-06 18:44:57 +02:00

Member

I still would like to replace the Split Viewer node with a normal processing node to simplify the viewing behavior regardless of the decision we make above.

I still would like to replace the Split Viewer node with a normal processing node to simplify the viewing behavior regardless of the decision we make above.

Brecht Van Lommel commented

2023-06-06 18:54:50 +02:00

Author

Owner

I don't have a strong opinion on the split viewer node. I guess it can be convenient to just have a single node, on the other hand if you already have a viewer node it can be easier to insert a new split node in between. Maybe some user feedback on that would be good.

I don't have a strong opinion on the split viewer node. I guess it can be convenient to just have a single node, on the other hand if you already have a viewer node it can be easier to insert a new split node in between. Maybe some user feedback on that would be good.

Omar Emara referenced this issue

2023-06-09 15:13:00 +02:00

Realtime Compositor: Support Viewer nodes #108804

Omar Emara referenced this issue from a commit

2023-06-09 15:53:16 +02:00

Realtime Compositor: Support Viewer nodes

Hans Goudey commented

2023-06-09 15:59:43 +02:00

Member

Separating the split viewer node is consistent with our plans for geometry nodes. We wanted to give people the option to build specialized Viewer node groups, which would have a viewer as an output instead of a group input. Viewer groups and assets could be added from the add menu and potentially the shortcut too. Removing the special Split Viewer node is a step towards that user customizable design.

Separating the split viewer node is consistent with our plans for geometry nodes. We wanted to give people the option to build specialized Viewer node groups, which would have a viewer as an output instead of a group input. Viewer groups and assets could be added from the add menu and potentially the shortcut too. Removing the special Split Viewer node is a step towards that user customizable design.

Iliya Katushenock commented

2023-06-09 16:23:30 +02:00

Member

Geometry nodes: Viewer Group

[Geometry nodes: Viewer Group](https://hackmd.io/@s0TMIS4lTAGwHVO20ECwpw/S1qvgx7m3)

juan gargallo commented

2024-04-10 13:36:40 +02:00

Other consideration is how to quickly switch between multiple viewer nodes. For compositing this is useful when working with masks, but want to keep track of the composite at certain points in the tree.

As a user, in other compositing apps a node can be quickly connected to the viewer by pressing the 0-9 keys. The way it's set up its convenient for various reasons:

it gives the user the opportunity to very very quickly toggle between any of the nodes that are connected to the viewer by just pressing the corresponding number when nothing's selected (If there is, that node gets connected instead and the corresponding number now points to it. That has its own drawbacks in the absence of a pinneable connection to the viewer).
It is so useful that it can frequently be used instead of a split view, which is very useful but slower to set up and a lot of times a simple toggle is enough.
The inputs connected to the viewer are automatically cached, so even if there's a heavy compositing going on, the first time it's slow to process, but then you can instantly toggle between any of them, without disconecting them and losing the cache. (if the user does some adjustment to a node, it obviously has to recache it, but for inspection purposes it is very quick to toggle when you are just looking)
In my own process as a user, I usually left the 1 to the final output, so I could always go back to it without navigating the compositing tree (that regularly comprised dozens to hundreds of nodes, so you had to make use of a miniviewer, or zoom out and pan, etc...)

To me, the main drawback to it was, as I said, that there was no way of pinning any of the inputs (say, the aforementioned 1 key for the final compositing), so sometimes you could accidentally reassing your inputs without wanting them to.

I explain this not to say "hey!! this app does this, please copy it!", but in regard to Brecht's comment that seems to question the real need for it. I think it is a high productivity boost (and a massive quality of life improvement) to be able to efficiently link multiple nodes of a comp to the viewer and have them stay there to inspect them at random points (maybe at mid tree, when at some point before you are dealing with Z defocus...you may need to be able to inspect the Z range, but also quickly see the intermediate result over the BG, and then the final output) That is really really handy, even if it has to reprocess the comp...to not having to navigate the tree all the time is a huge deal to me.

> Other consideration is how to quickly switch between multiple viewer nodes. For compositing this is useful when working with masks, but want to keep track of the composite at certain points in the tree. As a user, in other compositing apps a node can be quickly connected to the viewer by pressing the 0-9 keys. The way it's set up its convenient for various reasons: - it gives the user the opportunity to very very quickly toggle between any of the nodes that are connected to the viewer by just pressing the corresponding number when nothing's selected (If there is, that node gets connected instead and the corresponding number now points to it. That has its own drawbacks in the absence of a pinneable connection to the viewer). It is so useful that it can frequently be used instead of a split view, which is very useful but slower to set up and a lot of times a simple toggle is enough. - The inputs connected to the viewer are automatically cached, so even if there's a heavy compositing going on, the first time it's slow to process, but then you can instantly toggle between any of them, without disconecting them and losing the cache. (if the user does some adjustment to a node, it obviously has to recache it, but for inspection purposes it is very quick to toggle when you are just looking) - In my own process as a user, I usually left the 1 to the final output, so I could always go back to it without navigating the compositing tree (that regularly comprised dozens to hundreds of nodes, so you had to make use of a miniviewer, or zoom out and pan, etc...) To me, the main drawback to it was, as I said, that there was no way of pinning any of the inputs (say, the aforementioned 1 key for the final compositing), so sometimes you could accidentally reassing your inputs without wanting them to. I explain this not to say "hey!! this app does this, please copy it!", but in regard to Brecht's comment that seems to question the real need for it. I think it is a high productivity boost (and a massive quality of life improvement) to be able to efficiently link multiple nodes of a comp to the viewer and have them stay there to inspect them at random points (maybe at mid tree, when at some point before you are dealing with Z defocus...you may need to be able to inspect the Z range, but also quickly see the intermediate result over the BG, and then the final output) That is really really handy, even if it has to reprocess the comp...to not having to navigate the tree all the time is a huge deal to me.

Habib Gahbiche commented

2024-04-10 23:42:48 +02:00

Member

@txo I also think a lot of users are missing a quick way of viewing multiple nodes. I started working on this with a prototype (without caching) as an add-on but want to integrate it in blender if the feedback is good.

Here is the devtalk link: https://devtalk.blender.org/t/compositor-ui-improvements/34186?u=izo it would be nice if you could tell us what you think and continue the discussion there.

@txo I also think a lot of users are missing a quick way of viewing multiple nodes. I started working on this with a prototype (without caching) as an add-on but want to integrate it in blender if the feedback is good. Here is the devtalk link: https://devtalk.blender.org/t/compositor-ui-improvements/34186?u=izo it would be nice if you could tell us what you think and continue the discussion there.

juan gargallo commented

2024-04-11 09:47:24 +02:00

@txo I also think a lot of users are missing a quick way of viewing multiple nodes. I started working on this with a prototype (without caching) as an add-on but want to integrate it in blender if the feedback is good.

Here is the devtalk link: https://devtalk.blender.org/t/compositor-ui-improvements/34186?u=izo it would be nice if you could tell us what you think and continue the discussion there.

thanks @zazizizou, I already did!

> @txo I also think a lot of users are missing a quick way of viewing multiple nodes. I started working on this with a prototype (without caching) as an add-on but want to integrate it in blender if the feedback is good. > > Here is the devtalk link: https://devtalk.blender.org/t/compositor-ui-improvements/34186?u=izo it would be nice if you could tell us what you think and continue the discussion there. thanks @zazizizou, I already did!

Sign in to join this conversation.

No Label

Animation & Rigging

Asset Browser Project Overview

Automated Testing

Blender Asset Bundle

Dependency Graph

Development Management

EEVEE & Viewport

Images & Movies

Motion Tracking

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Render Pipeline

Sculpt, Paint & Texture

Video Sequencer

Virtual Reality

Blender 2.8 Project

Milestone 1: Basic, Local Asset Browser

Good First Issue

Animation & Rigging

Development Management

EEVEE & Viewport

Nodes & Physics

Pipeline, Assets & IO

Platforms, Builds & Tests

Render & Cycles

Sculpt, Paint & Texture

Needs Info from Developers

Needs Information from User

No Milestone

No project

No Assignees

9 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#108656

No description provided.