since everything is supposed to run on fragment shaders anyways it would be nice if we can get a custom node where we can paste our own shaders.
Hi @OmarEmaraDev , I know the MIX (Exclusion) could be implemented in the Mix colors node, so I’m writing here to keep the thread going for the realtime compositor viewport.
Thanks for your awesome support!
First off I want to say you’re doing amazing work with this, it’s like magic!
I absolutely cannot wait for Cryptomatte (new) to be implemented within the real-time compositor, that would open up so many interesting and intuitive workflow possibilities, I’ve been checking back on this nearly every day!
5 Likes
I like the recent UI/UX improvements overall. One thing I miss is having a shortcut to quickly toggle the compositor. I personally assigned a shortcut (Alt + Shift + C, similar to the shortcut to toggle viewport overlay Alt + Shift + Z) before but now it can only bring up the choices.
Are feature request related to the compositor allowed in this thread ?
There’s a separate discussion thread for that, split off from this thread:
1 Like
@OmarEmaraDev So thankful you’re making all these nodes work in real-time. I’ve been watching every few days to see your progress! I am mega excited that you said you were going to give the fog glow glare another shot next week! I’ve been watching your progress every week just waiting for it! I saw it didn’t work out last time you tried to make the fog glow glare work because the result was too different from the CPU integration, but I’m hoping you can get it close enough that it at least makes you happy enough to send to master 
Definitely hoping it works out in your favor! You’ve been doing an amazing job making these effects work in real time and it is my most used compositing node so I am patiently awaiting your success on replicating or even just approximating the fog glare node!
6 Likes
Hi everyone,
I previously presented the difficulty of implementing the Glare node in the following post:
While I wanted to implement a new Glare node that is more realistic, more easily controllable, and more performant and GPU friendly as required by the real time compositor, it was clear that this would take time, and we wanted to get some form of Glare working soon for the initial release of the real time compositor in v3.5. So I opted to try to optimize and approximate the existing implementation of Glare for the GPU.
The process was somewhat successful and we implemented three of the four modes of glare with a not so terrible performance. While the results of our implementation don’t match those of the existing compositor in artificial test cases, they are mostly similar in production test cases. Below are demonstrations for the differences between the two:
Ghost Glare:
Artificial test case to show difference. Above is real time compositor, bellow is CPU compositor.
A production test case where the difference is less visible. Above is CPU compositor, below is real time compositor:
Streaks Glare:
Artificial test case to show difference. Above is real time compositor, bellow is CPU compositor.
A production test case where the difference is less visible. Above is CPU compositor, below is real time compositor:
Simple Star Glare:
Artificial test case to show difference. Above is real time compositor, bellow is CPU compositor.
A production test case where the difference is less visible. Above is CPU compositor, below is real time compositor:
Fog Glow Glare:
Unfortunately, we couldn’t approximate the Fog Glow option using a cheaper method. So the initial release will be without it. I know this is the one option you have been asking for, but as previously explained, we didn’t initially have high hopes for it due to how expensive it is to compute. So it requires a performant FFT implementation that we don’t have at the moment, but we are already thinking how we might approach it.
32 Likes
Thank you for your efforts and successful implementations so far, these look amazing and I can’t wait to try them out myself soon!
3 Likes
I already mentioned it some time back. I am a bit sad that so much development time is spent on reproducing the old Blender glares which both looked so bad and behaved so unpredictably almost no one used them, instead of taking opportunity to implement some modern GPU based glare, that looks better, runs much faster and behaves more predictably. There are many examples, be it realtime renderers in game engines, or even some offline renderers, such as Octane for example.
There are surely many new, modern implementations and papers for models that render much faster, are much more GPU friendly and much more photoreal, with more intuitive UI parametrization.
I’d suggest giving up on reproducing the CPU glare node on the GPU, and creating new glare node, then deprecating the old one. Because even if the old one is successfully ported to GPU, and will run fast, which would be a miracle, almost no one will still use it, because the bad look and unpredictability will remain.
This ancient glare implementation should have died with Blender internal. It doesn’t belong into 21 century from the workflow/usability standpoint, from the visual quality/photorealism standpoint, and from the performance standpoint.
So the benefit would be not only that the GPU compositor supports glares, but also that the CPU compositor, if not deprecated, would get the old unusable glare node replaced by a new, actually usable one.
27 Likes
Absolutely agree on this.
I understand, and I want that myself as I mentioned before. But this is also the reason why I implemented the old methods, as I will outline below.
You see, the process of developing a new Glare node would probably start by elaborate discussions on what Glare methods to implement, what the user experience will be, which methods are computationally feasible, and numerous other considerations. Those discussions and investigations would take a long time because users like yourself care deeply about the new Glare and would like to get the design perfect and solid. So it will not be as easy as choosing some state of the art Glare methods and implement them.
In the context of the current real time compositor project, where we are aiming for a v3.5 release in weeks, there just isn’t the space and time to do the aforementioned process properly. So it is clear to me that we need get the real time compositor in a good state first in order to spend as much time as we need on developing the compositing workflow of the future.
Furthermore, deprecating the old Glare is an unclear goal. It is unclear if it should be replaced, augmented, improved, or just left as is. And this is subject to further discussions as well. Whatever the decision, implementing the old glare seems inevitable and not doing it now would leave the real time compositor in an incomplete state.
While the real time compositor project on the surface seems like a project to get a fast GPU accelerated compositor, to me, perhaps more importantly, it is a project to get the compositor in a better shape maintainability-wise. All the old convoluted code is now—to the best of my abilities—revers engineered, organized, and documented to ease future development. So this is just a slow start for the journey of creating the compositor of the future, so ride along and bear with me.
44 Likes
Love the examples! Your real-time GPU based compositor implementation is really close to the original CPU implementations in even the artificial test-cases which is to be commended!!
Been coming back as much as I can to check on how you’re doing with this project!!! I know I’m slightly disappointed that there was no way to successfully port the CPU implementation of the fog glow option to the real-time compositor but maybe there’s a solution that you know of that can help artists get things glowing using the real-time compositor for the time being?
Looking into it, the only thing I can think of is Eevee’s bloom. It runs on the GPU and seems like it could port directly to the real-time compositor without any issues, but I wanted to get your thoughts on that. It seems that for a temporary solution to the lack of a fog glow option for the real-time compositor maybe you could look into adding a “Bloom” node that ports over the “bloom” option from Eevee to the real-time compositor node. Porting the Eevee bloom implementation into the real-time compositor will drastically reduce the immediacy of needing the fog glow option. It’s visually similar in terms of the effect it has on a render and it really is a meet-in-the-middle solution for people who want to be able to make things glow using the real-time compositor until you have time to work out the FFT implementation of the fog glow glare for the real-time compositor.
I understand the implementation of the fog glow will take longer because you will have to work out how to make the FFT implementation performant but this issue isn’t an issue for the Eevee bloom from my understanding because it’s already working in Blender and is already a GPU implementation.
For now while the community is waiting for the development of that at least having the Eevee “bloom” option as a node would allow people to make things glow and the implementation is already GPU bound and already works within the blender ecosystem so it seems like porting it to the real-time compositor is the best short-term option? The only comparable effect that Blender has to fog glow is the Eevee bloom system to the best of my knowledge. Is the integration of the Eevee Bloom as a compositor node more of a reasonable short term solution for people who want things to glow using the real-time compositor?
4 Likes
This is a good point. I am no sure if we should add a Bloom node right now, because we will have to commit to it for the future and I don’t want to rush things. However, since the Bloom effect is similar to Fog Glow, we could consider temporarily approximating Fog Glow using the Bloom filter by trying to match its size and options.
7 Likes
What the vast majority of the community would be happy with for the next 4 years or however long it takes to reproduce Fog Glow:
Edit > Preferences > Interface > Developer Extras : TURNED ON
Edit > Preferences > Experimental > Prototypes > TEMPORARY EEVEE Based Bloom Node for Real-time compositor (dead on arrival, will never be official) : TURNED ON … soooooo tuuurrrrned ONnnn
Just give us that. Takes twenty clicks to turn it on. We don’t care. Will disappear without warning 4 years from now and we’ll have to manually re-do our bloom with the Fog Glow node if we want to open old projects in new Blender version. WE - DON’T - CARE. We’ve got to download it as an add-on from GitHub. WE DON’T CARE. We want eevee bloom in real time compositor to hold us over until the real thing is finished.
11 Likes
Some inconsistencies and possible errors.
- With Box Mask and Ellipse Mask, manually putting a value to Mask gives different results between GPU and CPU compositors. In my opinion the result from realtime compositor looks “correct”.
- When using variable size in Blur node, Catmull-Rom and Mitch modes make sharp edges around mask area.
- Different results when size input is connected but variable size is not active.
- Variable size is not available in Fast Gaussian mode for some reason, but if it was checked in other modes it’s still in effect in Fast Gaussian mode.
5 Likes
images still dont scale/transform with the viewport preview and i dont see anywhere a priority or task to change that. Unusable in that state. Beside that it would be nice if images and movieclips could be animated in compositor like you can in aftereffects
1 Like
yes and other posteffect shaders too please(several types of distortions, halos, linearts, etc.) , a bloom node could also have a drop down list to select from several different bloom shaders, from old school to ue5 quality basically + maybe some good looking exotic bloom and hdr shaders.
most of the shaders are free on the net … but then comes the compatibility requirement with cpu mode, thats like that meme where the guy put a stick into his own bycicle wheel …
I would like to point out that if there is a proper making system in place, a good competitor wont need nodes like glare flare bloom and glow.
The compositod can build the above mentioned effects through nodes in there own.
One of the most important things to compositing is masking and dealing with channels.
This really is the heart and lung of compositing, or if you like the engine.
With out masking everything here is just a filter system, similar to GMic.
Just a heads up and friendly reminder on what professional competitors really need at the most basic of levels to achieve great results.
Straight up good solid effective standard masking systems.
4 Likes