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 .
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.
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.
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 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 ?
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.
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?
