One of the main problems with Glare node is that the settings are overcomplicated, yet no matter how much you tweak them, you get inferior results to other glare solutions in renderers and compositors, which have often much less settings, but produce much more realistic glares in literally fraction of time, even when not GPU accelerated.
So honestly the last thing we want to do is to take this complexity and clumsiness and add even more modes to it.
It’d make much more sense to simply make new clean Glare node, and rename this to Legacy Glare or something
In fact, it already doesn’t have sense to have lens ghosting, dispersion glow and streak based glare combined in one node, give how distinct these effects are.
Anyway, I am curious if the ported existing glare will ever run at interactive framerates, yet alone realtime ones. It’s just so incredibly slow.
A native fast (and realistic) glare node would be nice … until then we could build custom glare nodes once node groups are supported. Chaining Gaussian Blurs with varying radii works just fine and is surprisingly fast.
I was testing the lens distortion node and I noticed that it produced some inconsistent results. If I’m looking through the camera and move it off center, the effect changes. Here’s a few examples:
That’s because the compositor is working on the entire viewport. If you match the 3D View to fit the bounds of the camera, then it will be exactly the same as the render. But I think I have to agree that users tend to expect to see the same result as the render when looking through the camera.
Agreed. I assume that the camera in the 3D viewport will serve as the de facto compositing window once this project gets enough nodes supported. If users still have to render to see what their scene will actually look like because their 3D viewport camera is slightly off centered, it kind of defeats the purpose of using it.
The plan is to limit the compositor to opaque camera passepartout to alleviate the difference between viewport and final compositing, so we are aware of this issue.
The compositor has three nodes that can be used as output nodes. The Composite, Viewer, and Split Viewer nodes. Which of those nodes should be considered the output of the real time compositor?
[…]
But such priority would make adding viewer nodes for inspecting intermediate results a bit inconvenient as we don’t have a separate result for both, does this use case make sense for the real time compositor?
I believe the most obvious way to deal with this would be an enum appearing, which would allow to choose between the options ‘Viewer Node’ and ‘Compositing Result’ in the Viewport Shading popover, as soon as the Viewport Compositor itself was enabled.
Maybe about like so:
This way, it would be consistent with the UI in the Image Editor (where you can choose between ‘Viewer Node’ and ‘Render Result’).
All the rest could then work the same in the viewport as it does in the image editor (‘Viewer Node’ shows whatever is piped into the active ‘Viewer’ or ‘Split Viewer’ node, if present, else nothing; ‘Compositing Result’ analogously shows the active ‘Composite’ node, if present).
Hello! Just wanted to ask if the View Layer passes will be implemented to use? At least on the last build I tested they were pitch black but without that “implemented feature” text, thanks.
I honestly do not understand the reason for both a Viewer Node and Composite Node (Render Result).
So many times I’ve gotten my comp nodes just right, checking them with ctrl+shift+click and then I totally forget that I need to manually plug the end into the Composite Node to actually get that result in the final render.
So then I force myself to stop using the viewer node for a while so I can avoid that annoyance, but I want to view the result full screen on the 2nd monitor so I open an image editor over there. Problem is I can’t find anything in that 80 item long list of textures that says “Composite Node”. I see one that says “Viewer Node” so I give up looking and add back in a Viewer Node so I can see what I wanted to see. It’s so annoying.
In the Material system with Node Wrangler the “Viewer Node” actually plugs directly into the Material Output node. That makes a lot more sense to me.
Yes, I can see your point and it has at least some justification. In broad strokes it boils down to which option one considers more messy, I guess:
having no viewer node at all and inststead a quick, convenient way of wiring up the ‘Composite’-Output node to any intermediate result (think Node Wrangler workflow). The messy side of this is the connection from intermediary node to ‘Composite’-Output node and the danger of eventually rendering out the wrong stuff (forgot to rewire the ‘Composite’-Output node correctly before F12).
having viewer nodes and needing to manage at any given time which one is the active viewer node and weather that aligns with the ‘Composite’-Output node. This can get further complicated if you throw ‘File Output’ nodes into the mix.
With that said, I mainly see one clear reason why viewer-nodes shouldn’t be completely disregarded as the Viewport Compositor’s output-source:
The ‘Split Viewer’ node. That one can be useful to judge results of subtle comp-operations side-by-side with another version. I can see that being useful in the Viewport Compositor too.
This sounds like a broader discussion about nodetree UI and is probably offtopic?
On a more practical level though: Why not just type ‘vie’ or ‘viewer’ (for the ‘Viewer Node’-entry) or ‘ren’ or ‘render’ (for the ‘Render Result’-entry) into the searchbar on the popover of that enum?
It took me like a solid year to notice “Render Result”.
Why would Viewer Node === Viewer Node but Composite Node !== Composite Node?
I was going to argue against this but that would require arguing against viewer nodes and arguing for Render Result to be renamed to Composite Node or the other way around. Don’t have the energy for that so I’m fine with this suggestion.
But for the sake of the half-a-billion people who’ve not yet touched Blender Compositing please name them "Active Viewer Node" (because I’ve downloaded 10 year old files from BlendSwap.com with like 50 different viewer nodes in them) and "Render Result (Composite Node)".
I’d also like for them to be in a dropdown menu so I can quickly ctrl+mousewheel to change them and get a nice instant before/after comparison going it. I’d much prefer that over the split viewer node.
By the way, in the original compositor the Split Viewer Node is so damned slow that it’s ALWAYS been less annoying for me to take 2 screenshots, paste them into my Sketchbook post on BlenderArtists.org and use the gallery feature of that to go back and forth and back and forth to make decisions. However there were several dozen times where I wanted to output of the Split Viewer Node to be my Render Result to avoid needing to open photoshop or struggle to figure out how to reproduce the Split Viewer Node with other nodes. Problem, the Split Viewer Node has NO OUTPUT!
I guess partly historic reasons and partly for the fact the ‘Render Result’-option also exists if compositing is disabled alltogether.
You can always fetch the image which results from the rendering-process (the renderbuffer in memory) by selecting that ‘Render Result’-entry inside an image-editor window.
In cases when compositing is disabled (probably the majority of renderings being done), it makes sense for this to be called ‘Render Result’, rather than ‘Compositing Result’.
Though I have suggested above to call it ‘Compositing Result’ in the Viewport (which makes sense, I suppose), my mockup was a bit too sloppy to reflect this semantic detail.
@thinsoldier@Kologe Thanks for your inputs!
Personally, I also don’t see the point of having both the Viewer and Split Viewer nodes. I would rather have a single output Composite node whose result can be viewed in the backdrop. The split viewer node can just be turned into a standard node with an actual output that can then be connected to the composite node. It should also be noted that the issue of rendering the wrong output by forgetting to link the correct output eventually is already an issue, since users typically expect the viewer result to be the final result. So I don’t think that it is comparatively a disadvantage for either workflows.
