Yes, I thought about that too, and it would technically work, but I’m not a fan at all, just because in a complex tree (which would be the type of tree that would benefit the most of that mapping behaviour) I think it would be very messy very fast, because the viewer nodes would scatter around and if would be really hard to scan. If they were much more obvious, maybe? But I’m skeptical even if that were the case.
When working in the geometry node editor, when there’s a kind of complex tree and I have to go looking for the viewer node… Oh man. It is a pain, because they don’t stand out at all. I would not want having to look for more than one of those. They would have to be neon colored for me to be kind of ok with it.
To be fair though, the Ctrl+Shift+Click workflow implied that you shouldn’t be really bothered to where the viewer node is… But still I think they could potentially create a lot of visual clutter, and you do want to see at a glance what nude is connected to the active viewer, and the current UI design colors makes it hard.
In the future, we will have that option for all nodes. We will allow you to choose which input determines the size of the node, or it could be auto like we have now, or the render resolution. So this design will probably be implemented regardless of what we decide.
No news on that for the moment unfortunately, but we are close to reaching some of the other milestones, so hopefully we will pick that up next.
I am not sure how we compute the mist pass, but you can approximate it by normalizing the depth pass, remapping it, and taking its power to some value.
I’m just thinking it would be cool to have like a constant distance fog effect in the viewport (similar to video games), without having to set up volumetric lighting. I think it would make it more intuitive working with environment design, because you get a better sense of depth from the gradation of values going from dark in the foreground to lighter in the background.
But it’s currently not possible to do it with viewport compositor, I guess?
It is currently not possible to have the mist pass in the viewport compositor. However, you can approximate it using the depth pass as I mentioned above, which should work in the viewport compositor, but only with EEVEE.
Well, that is news to me …
Okay, maybe with Cycles as well, but ONLY when Overlays are enabled.
Though if you disable overlays, the last visible depth buffer will be returned and will not update as you rotate the camera.
I can’t share my scene but I will try to get you a scene to test.
Btw I am getting constant crashes with the file when I combine all the scenes in a sequencer scene. Does this look like a crash by the compositor? It always crashes when rendering the last frame (frame number 6). All the scenes have compositors enabled. I will see if I can prepare for a simpler scene for this too.
The Depth pass is not expected to be identical between Viewport and Final Render. It will be once we add passes support, but for now, it is a temporary approximation.
For future updates of the glare node, I remembered about this video.
I assume that the FFT Convolution Bloom approach talked about near the end is the one that the glare node uses, and the OP talks about how you can use a custom kernel shape for the bloom. Something to look into in the future?
Hi, is it possible in any way to have inputs from compositor to scale and translate like the camera view/render region?
Here I tracked footage and I’d like to zoom in and see if everything aligns, color correct, pick values, etc
Similar behavior that we have when using the background image in the camera
This is a known issue at the moment. In order to fix it, we need to introduce the concept of data and view windows, which is hopefully in our short-term development plan.