Real-time Compositor: Feedback and discussion

This topic is for collecting feedback and discussions regarding the Real-time Compositor project, which is introduced in the following blog post:

The current state of the project can be tracked in the following task:

A list of some of the UI/UX concerns associated with the real-time compositor is laid out in the following page:

Contributors to this topic are expected to provide feedback specifically regarding the aforementioned UI/UX concerns. For now, discussions should be limited in scope to the viewport compositor, while discussions regarding new features and long term goal should be avoided for the moment.


I really appreciate the reading of that document. The part you spoke about the future work " reuse of the compositor node tree " will make the editing faster.
Where can we download and try you patch .


You can download the branch from here Blender Builds -
Refer to the blog post for instructions on how to enable it.

1 Like

Hey @OmarEmaraDev thanks for your work, i tested the branch a bit and it works flawlessly, I have 2 concern, slow node like the glare node, sun beam etc will be fast in this new implementation ?

Also is it possible to have the timing overlay as in the geometry node graph ?


What I can say is that slow nodes will be significantly faster using the new implementation, whether they will be sufficiently fast for real-time compositing is a bit subjective and will likely be hardware dependent.
We will discover those things as we implement those nodes, and I will keep you updated. For more information, refer to the two sections “Slow Operations” and “Alternatives To Slow Operations” in the UX document above.

Timing information are probably technically possible, but we don’t have planes to support them for the moment.


Hi Omar!

I’m really impressed with the selection and performance of the nodes currently supported by the viewport compositor so far.

Of the nodes yet to be done, which ones are you working on next?


Looking forward to giving this a spin!

In the mean time, are there any overarching ideas to using various render layers in the same composite ?

Meaning a view layer (background) can be rendered and comped together with another view layer (foreground) with the same interactivity ?

1 Like

Can it be disabled if needed?
I guess it will be a thing for 3090 users, nothing else !

The reusable compositor node tree is a great addition.

On the Hue Saturation Value node, at present the Saturation is automatically clamped. There are cases (like implementing an additive keyer for fine greenscreen detail) where negative values generated earlier in the node tree need to be preserved through the HSV node.

Would it be possible to add a ‘clamp’ checkbox to this node, similar to those present in other nodes? This could be enabled by default to preserve the current behavior, while at the same time enabling more advanced use of the node math.

In the docs it’s stated you have to enable it. Will surely be disabled by default.

Such a great work and a real gamechanger.
After this is implemented are there far plans to add nodes such as noise, voronoi, wave textures etc? (from the shader editor)

"I recommend adding a way to store the result of a buffer offscreen, to be used next frame too*
(motion blur and a few other techniques use it)

ie ‘Output node - temporal buffer’"

1 Like

Is this where we can make bug report about this branch? Currently the RGB to BW node would cause a crash.

The checkbox on the task page is checked

so I believe it should be working, but it’s not:

ERROR (gpu.shader): GPU_material_compile ComputeShader:
  542 | color_to_luminance(tmp2, cons4, tmp5);
      | Error: C7011: implicit cast from "float" to "vec4"

Address : 0x00007FF7E043431B
Module  : blender.exe
Thread  : 00004568

I would prefer one shared node tree with options to split parts of it for viewport and for render. Similar to the shader nodes that have two different outputs that let you choose between Cycles and Eevee, but for Viewport and render.

However the two-output approach has some disadvantages. A “Is viewport” input node could be better.

I am most likely going to concentrate on filter nodes.

This is also planned as part of multi-pass rendering support.

Yes, it is disabled by default.

It should be possible, but for now, we will concentrate on compatibility with the existing compositor and will look into such improvements once we have made progress with the viewport compositor.

Yes, this is planned as an alternative to the current noise texture, since it will likely be removed.

To be used by what exactly? Render engines?

This is already fixed in the submitted patches along with numerous fixes, the branch is a bit out of date since we split it into multiple smaller patches for review.

We considered multiple approaches for this but still haven’t settled on an ideal approach, so your suggestion will definitely be taken into account. The reason why I don’t particular like such approaches is the fact that practically, artists will not need to deviate their viewport renders from their final renders aside from performance implications, which can be handled in other ways. This can be seen even for the EEVEE/Cycles split. If they do want different compositing for viewport and final render, we plan to allow the creation of multiple node tree that can switched as needed.


I was wondering where this stood with respect to the “classic” compositing workflow… that clears it up. Having the result directly in the viewport looks amazing ! Historically the compositor has had trouble merging sources with different aspect ratios -for instance a vertical source overlaid on top of a horizontal one would get stretched to fit the first input. How does that work in the viewport ? Is there a way to control aspect ratios/canvas size explicitly ?

In any case great work this looks so fun to use.

The new compositor was designed to support infinite canvas compositing from the start, and it defines rules for how such things work, and we will likely add new nodes that helps in that area. I intend to write some documentation about this at some point since we only have technical documentation that describe the concept.

But in general, the compositor will never stretch or scale any images to fit other images, each image will be sampled from the exact area it occupies in the virtual compositing space, and the operation would only be interested in the areas of the inputs that intersects its area of interest, which is typically determined from its main input.

But really, I will explain this in much more details a bit later. I will make sure to let you know when I do.


This is great. It was really a big limitation. I’ll keep an eye on this thread. Thanks !!

question, all the data used in the node editor needs to be stored somewhere, in the normal editor its the normal ram, in this viewport composite is it still saved in the ram or its stored in the vram?

It is stored in the VRAM.