3.6 beta’s viewer works nicely, however, having the “Use Nodes” option on still makes changing frames much slower in solid mode. Even when the original image is plugged into viewer. This kind of beats the purpose of the viewer node at the moment since it requires you to turn off the nodes every time you want to do basically anything in the viewport in solid mode.
1 Like
Hi @OmarEmaraDev !
Thank you for your incredible work. I’m doing some color space transform related development and it’s really helpful having work like yours to refer to for guidance.
I was looking at the LGG shader in your rt compositor and also at the legacy implementation and noticed that there is a hard coded conversion from Linear to sRGB and back in both. I found a note in the source code from @ideasman42 about this also existing in other parts of the code (sequencer).
Can you refer me to a discussion about this or, if it’s really easy, explain why this extra transformation is done?
Thanks again
I am not sure to be honest, I was merely porting the code, so not sure why the transformation is done.
Hi everyone,
We are currently discussing some changes to the viewer mechanism for the compositor in general. There were two proposals that were brought up and it would be helpful if you can provide some feedback. This is presented and discussed in the following issue:
4 Likes
Absolutely perfect! This has always been a bit of a nuisance, the geometry nodes like behavior would be much more optimal
Few feedback notes I collected about the viewer
Some nuisances:
-
Currently the viewer has few features that I don’t think anyone uses? Maybe I’m wrong but there could be an overhaul. (toggle preview, use alpha, alpha, z?)
-
Every time I add ctrl + shift + click a node it will put a viewer on top of other nodes and won’t take take a good position, say I will preview another pass it will redirect to the old viewer when it’s on top of other nodes.
Really rough design suggestion, it’s can be also used for looking at render slots, because sometimes you want to split screen compare and seeing side by side or split view can be really helpful.
Last thing having a realtime compositor backdrop for viewer would be nice when trying to save screen estate
Thank you so much for making the compositor a blast to work with 
2 Likes
Why do you think no one uses (or wishes to use) alpha?
There’s a node “set/replace alpha”, which does literally the same thing.
I think it could be cool if the viewer node simply had, say, up to four inputs where you can do a line or cross for comparing up to four images in a single view.
In principle you could “just keep going” but at five and beyond it becomes increasingly useless. But 4-way comparisons in that manner can still be very useful.
If it just has a single input, it’s the regular viewer
1 Like
I like this idea. My main concern about what Brecht proposes in the discussion is that it can be very tedious to be manually looking for and connecting the different views to the split viewer node.
and this suggestion made above could have a similar problem, since you would be hunting around viewer nodes.
I think a mix between the @costavojik suggestion and what you’re proposing could potentially solve that. The viewer node would actually be a split viewer node by default, and the mode of presenting the images would be determined through the UI (maybe an option list in the popovers, or in the top bar, that lets you decide between “single”, “A/B” and so on). But with only one viewer node that connects automatically, so you don’t have to look for nodes scattered around the compositing tree.
Bonus: have an option to pin an input so you don’t replace n.1 unwantedly when connecting to the viewer for the 5th time. And/or use the number keys to connect to specific viewers.
2 Likes
Excellent work @OmarEmaraDev. I hope that in the future, it will also be possible to link the Composite to a specific camera and have multiple Composites for each camera. The current way of working with multiple cameras and having only one composite always seemed unintuitive to me: it requires readjusting the composite values every time the camera is changed. It seems much better to have one composite per camera and perhaps be able to reuse it for multiple cameras at once.
3 Likes
I would keep viewer nodes separate, and have the split functionality live entirely in the image viewer
Hey @OmarEmaraDev , thanks for your incredible work on one of the most exciting developments currently in Blender! I was wondering, since the real-time compositor is based on GPU shaders, are there any plans to implement some kind of GLSL or other custom shader evaluation node? Are there some unseen complexities that would prevent that from happening?
A few years back, @myselfhimself had a great implementation of this in a custom branch of Blender that worked quite well. I can only dare to imagine the flexibility and power this unlocks, the ability for the community to write custom shaders and use them directly in the compositor (even in the viewport!) would be mind-blowing. Here is what the aforementioned implementation looks like: Blender compositor with a Shadertoy compatible GLSL node - YouTube
Thanks again for all your work!
3 Likes
I am not sure about that design in particular. But we were looking into having composite nodes as reusable IDs that does not solely exist as art of the scene, so this could open up some possibilities like the ones you mentioned.
I don’t think this is a question of technical feasibility, since it doesn’t seem too complex to do. It is just not something that we are looking into at this stage, since things are not yet stable. But I would personally like to see us implement something like that, and I will look into it when the time comes. However, it probably won’t be a “GLSL node”, but rather a complete node implementation that can potentially use the python GPU module to do its computations.
11 Likes
Any plans to support the Kuwahara filter with the GPU compositor?
Yes, I will look into implementing that later this week.
4 Likes
Oh, and if that * cough * would also include the render resolution… * cough *
How do node previews in realtime compositor supposed to work?
Are the previews supposed to be updated realtime like viewport compositor? Or is it just for the experimental GPU support for non-viewport compositor (only update when the scene was full-rendered)? I’m just guessing this is for later.
It currently only works for the experimental render GPU compositor, but also for interactive edits, not just for final render.
I actually only just realized that it doesn’t work for the viewport compositor, not sure why. Also not sure if it should be made to work, since it can degrade viewport performance due to blocking CPU<->GPU memory copies.
Hi Omar, is the experimental render GPU compositor getting a rewrite of the bloom and glare nodes? What you did with the current viewport compositor is beautiful; extending that would be great!