The experimental render GPU compositor and the viewport compositor share the same compositor evaluator (Realtime Compositor), so they currently have identical implementation for the bloom and glare operations. We still haven’t done the Fog Glow operation, however. So they both still share that limitation.
4 Likes
So these are meant to work how?
Looking at the documentation and my nodes don’t look like this when i add them and I am not sure if this is working.
I must be doing something wrong. Is there a magic setup?
Documenation: ID Mask Node — Blender Manual
In Realtime Compositor: Implement ID Mask node Omar wrote:
@AdamEarle Note that this only implements the node itself, not the ID pass, so it is not very useful right now. The ID pass will hopefully be supported when we support multipass compositing.
Multi-pass compositing has not yet been implimented according the the tracking task.
To get your nodes to look like the ones in the documentation, it says under “Setup”:
To be accessible after rendering, the Render Engine must be Cycles, and Object Index or Material Index render pass has to be enabled.
1 Like
Are you sure that’s right? @OmarEmaraDev of the links in this page are broken as well https://projects.blender.org/blender/blender/issues/99210
I was under the impression that it was implemented. I also found it odd that as well because i knew it was a Cycles thing so I am curious to know if it is or isn’t. A lot of YouTubers are saying that it is.
Here found the answer https://projects.blender.org/blender/blender/pulls/106593
Might be best to let some of these YouTubers know that the node is useless
Does the viewport compositor support comping other scenes?
That’s an interesting question, especially as multi layer support isn’t included yet. I’d suspect not as the viewport compositing uses the currently displayed engine output. In Eevees case I suppose you’d need to have multiple instances of the engine active? TBH that might be the issue with multi layered support too.
1 Like
Can anyone confirm on their end that using the ViewPort Compositor makes VR Sessions crash immediately on start?
If you’re personally experiencing crashes when the viewport compositor and VR session is use, then you should make a bug report about it. But just for the record, I don’t experience any crashes. Information on my testing methodology below:
Blender version tested: 4.0.0 Alpha, branch: main, commit date: 2023-06-23 09:34, hash: fdc0402a5062 (it is a little over a week old)
Steps I took:
- Go to preferences and enable the
VR Scene Inspectionadd-on. - Change the viewport to the EEVEE render engine.
- Enable the viewport compositor to be “Always on”.
- Open the compositor nodes and add some nodes (In my case I added a glare node between the render layer and the final output)
- Start the VR session.
My results: The VR session started just fine, and the compositor was applying within the VR headset.
If you are experiencing crashes, then it could be because of a recent change in Blender that fix things that I have and you don’t, or a change that breaks things that you have and I don’t.
The OS and the relevant OpenXR runtime could play a factor in this. I am on Windows 11 and I’m using the Windows Mixed Reality OpenXR runtime
Another factor could be the GPU and GPU drivers. I’m using an RTX 4090 with driver version 531.79.
The ID pass is indeed not supported yet in the viewport. If it doesn’t work in the experiential GPU render compositor, then it is an issue that we need to handle, is that the case?
Currently, we are only interested in multipass compositing as a first step. Multi-scene compositing will be considered in another milestone.
2 Likes
hi, is there a plan to support compositing in srgb color space? Mainly for motion graphics and the use of srgb blending mode. Work in srgb color space is common in graphic design and people have developed work flow around it
Can’t you use the Convert Color Space node for that?
3 Likes
Or just switch the whole scene from Filmic to Standard
Great to see all the nodes being completed. Would it be possible to put the Inpaint node next on the porting schedule? It’s extremely useful for greenscreen & keying operations.
2 Likes
This node is particularly hard to implement because it uses a serial algorithm that is hard to parallelize on the GPU. So we will likely try to find an algorithm that produces similar results and is easy to parallelize first, so it might take sometime to get there.
4 Likes
Is there a projected timeline for layers or passes to be integrated? Which one is likely to be added back first? Are there special problems implementing them?
Passes will be added first, while layers are not currently being worked on. Refer to this post by Sergey as an answer:
2 Likes
Hey @OmarEmaraDev , I’ve been trying to use the glare node in 4.0 alpha but it’s too broken, it give weird strong results compared to the old cpu one and to the bloom from eevee, there’s a problem with it’s clipping, check the video.
Cycles 4.0 ( viewport comp ) Size is 6 but as you can see there’s too much glare
Cycles 3.6 ( render comp ) expected result
Eevee 4.0 with bloom ( viewport comp )
It looks like what you actually need to match EEVEE’s bloom is to reduce the mix factor as well.
As for the Render Compositor, this is unfortunately a known difference that we will eventually fix and unify.
3 Likes
Is there a chance to make it for 4.0? Right now it’s not possible to use bloom in viewport as it’s not accurate. There was a workaround that you’ve posted but it’s not working as it should.
No unfortunately, an accurate implementation requires convolutions, which are very expensive to do if not implemented right. So it is going to take some time.