Hi! this is not the place to ask this kind of things, please stay on topic. This is for feedback and discussion for the Real-Time Compositor. for you can ask that on https://blender.stackexchange.com/
Once passes are supported, you may be able to use things like AOV, ID masks, or Cryptomatte to selectively modify each object.
Since passes are not supported yet, you will have to resort to using other methods like detecting different objects based on colour.
3 Likes
It looks like if the compositor nodes with is enabled but not enabled for the camera or the viewport, the calculations still happen which slow down the viewport. That is not how the traditional compositor worked, it only calculated after and image was rendered. The compositor (whether it is tiled or gpu etc) calculates every little thing if it is enabled but not for the viewport at all. it would be nice if the compositor is recalculated if there is a new render or if it enabled in the viewport.
I assume the interactive node editor compositor is the one doing the calculations, not the viewport one or the final render one. The calculations happens when exactly? When editing the node tree?
Somehow enabling the compositor and then disabling it in the 3d viewport seems to keep the compositor still active. This affect can only be seen relatively heavy scenes.
These are my steps
add the compositor processing in the 3d viewport
enable the compositor
add some processing like kuwahara, grading etc
do changes in the 3d viewport and observe the resulting processed image
disable the compositor in the 3d viewport
the compositor still calculates stuff which can be felt by how sluggish the scene gets
disable the the compositor for real
the scene gets back to the normal interactivity speed.
What even is the point of Movie Clip data block, I donât undersntand. Why canât Movie Clip Editor use Image data-block, which is same, and have one Image node in Compositor?
Is the Keying Screen node expected to be in the daily builds soon? It would be very useful to have that node GPU enabled.
@EliotMack I am currently refactoring the CPU implementation first to use a different interpolation method. When this lands, I will do the GPU implementation. Feel free to provide some feedback on:
Can you open a bug report? Because I still canât reproduce.
1 Like
I noticed if I use the viewport compositor I get smooth gui feedback , but if I change the compositor to gpu (instead of tiled or fullframe) I start to get a minor but noticeable gui lag (when adjusting). Could this be a bugfix issue or just the gpu doing extra work because of having to deal with the full res output. In this situation only the viewport is showing the composite and If i switch it back to tiled or full the performance lag is goes away. (didnât think this is the same issue that kurk was referring to)
@OmarEmaraDev the workaround is not working for me, Iâm using 3.6.2
Even when i use gpu as final render on blender alpha, itâs not easy to have a good glare, the new implementation is too sensible, a little bit a brightness provoke very bright clamped values, setting the âmixâ at -0.990 doesnât help
1 Like
I am not sure what might be causing this, but there are extra things that the GPU compositor does that the viewport compositor doesnât, like moving data between GPU and CPU, which can cause halts. Eventually, this should go away, probably before we move it out of experimental. So I would suggest we wait a bit for the GPU compositor to mature then look into those issue.
Is the clamping a consequence of the RGB Curves node or the Glare node itself?
The glare node, hereâs a test with the gpu glare, you can see the clamping, is this expected?
hereâs a test with cpu glare with different view transform
Standard
Agx
filmic
the clamping is more visible with Agx, I had to put the mix to -0.500 so itâs not visible anymore. ( remember the screenshots use the cpu glare )
Beside the clamping problem, changing the âMixâ setting between -0.900 and -0.990 itâs not good UX, any plan to make it behave better or more like the cpu version?
Can you share a minimal version of that file?
Yes, Iâve sent it in your personal message
So far, the experimental GPU render compositor has been executing using Half float precision. We are working on an option to change that to Full float precision , builds available here:
In the node tree options, when the compositor is set to GPU, an option to choose between Full and Half should appear. It would be nice if you can:
- Help us test to see if everything works as expected.
- Provide some numbers on the increase in execution time when moving from Half to Full. (Mention GPU model as well).
9 Likes
(Windows / RTX 2060 Super)
I donât really see a big difference in execution time, slightly slower when using full float precision (ex: 0.8 sec in half, 1.0 sec in full). Maybe because I only tested with a simple compositing setup (simply putting high values to some filter nodes like Kuwahara or Blur).
Probably having a benchmark file would help.
However I see a difference in rendered images with anisotropic Kuwahara when thereâs a sharp contrast in the input.
Half-float:
Full-float:
Setup:
1 Like
I noticed that compositing node changes do not cause EEVEE Next to re-render itself, unlike in the case of EEVEE. This is very nice! Is this thanks to the changes from the EEVEE Next side or compositor side? I see EEVEE still refreshes itself when values in compositing nodes change.
This is likely a change in EEVEE Next, as I donât recall anything related changing the compositor.
Are there plans to support the texture nodes? It looks like the âtextureâ node renders black, while the other two compositors can render textures from the texture nodes.