Glare Bloom is hard capped between 6-9, while EEVEE-Legacy Bloom is soft capped between 0.0-10.0 (with a hard limit of 100.0).
Additionally the values do not match.
Legacy Bloom to Glare:
4=6
5=7
~6.2=8
8=9
The issue on this is that the viewport compositor is not feature complete. This node tree will not eval in the viewport.
Obviously, this is a dead issue - the code has been moved, and won’t be returning to 4.1. But this problem with bloom and viewport compositing was brought up months ago - and, what was predicted, is now here: it doesn’t work.
I feel like the clamp setup isn’t very obvious without being explicitly told how to do, like how i couldn’t figure out how to replicate it earlier, a simple solution would be adding the Clamp Node to the compositor (preferably with a variation that works with Color values, a Clamp Exposure node?).
Which node breaks your setup?
He is using passes, the viewport compositor doesn’t support multi-pass compositing yet.
This node setup seems unrelated to the discussion of how to recreate bloom in Blender 4.2, and it seems more like feedback about the veiwport compositor as a whole. Feedback about the viewport compositor is better suited on the viewport compositor thread: Real-time Compositor: Feedback and discussion
Unless you’re referring to the fact that in Blender 4.1 you would have this compositor node setup for final renders, and you would have bloom enabled in in render settings, meaning it’s visible in both viewport and final renders. But now that the bloom has been shifted to the compositor, you can’t use your complex final render node setups and your viewport bloom at the same time without a bunch of manual work switching between “viewport” and “final render” setups, or a add-on to automate that for you.
The most likely reason that node setup is failing is because at the moment the viewport compositor doesn’t support passes. Work is being done to add support here, but it’ll be in Blender 4.3 at the earliest.
After that, the most likely cause for that setup failing would be the use of multiple scenes, which I’m not sure if work is being done on.
what has been removed in the name of coherence and consistency has become a little nightmare.
New bloom is worse and strangely convoluted, it is dependant on viewport real time compositor while old bloom was just a checkbox, it was simple and worked beautifully. I know the node tree for new bloom is a temporary solution but, alas, it was so good and convenient.
I hope filters get some love for 4.3. I miss good lens flares (not ghost filter), a simple vignette tool, better color correction, etc. Honestly, the filters in the compositor feel ancient and now we get bloom forced into that ancient pipeline, dissapointing
That’s why I use Uber Compositor for the last 3 years (don’t have any affiliation to it, btw)… should come as default in Blender
Hi @OmarEmaraDev,
Firstly, thank you so much for your incredible Compositor developments.
Apologies if the following is a silly question…
Since Bloom Intensity
range is -1 to 0, would it help if the code automatically subtracted an input by 1, presenting a more artist friendly UI range of 0-1?
Kind regards.
I have made a addon for this issue, well mainly in general not to have slow startup of blender when you open a scene which was saved in render preview. This addon will switch any scene to solid mode when you open the scene
The range is more technical, it basically between -1.0 and 0.0 it mixes between no glare and full glare, and between 0.0 and 1.0 it mixes between full glare and only glare. So for example if you’re blending glare manually with a mix node somewhere else (for example if you’re using multiple glare types at the same type), you’d always want to set mix to 1.0.
It’s possible to add back the ability to turn off shadows per material?, Trying to turn off shadows one by one is very tedious.
It’s complicated for no reason,in the legacy it’s just as easy as selecting “None” on shadow mode option on the material settings
I’m not a EEVEE developer, but I assume this change wasn’t done for “no reason”. My guesses for why it was done would be:
- To align with Cycles that used the node based system.
- To allow more user freedom by making this part of a expandable shader node system.
Either way, these are just speculation, and since I’m not a EEVEE developer I can’t tell you if the shadow mode material option will return. So I’ll leave future comments on this topic to a developer.
I’d like to share some of results and experiments with Eevee (next), here are some comparisons between Eevee, Eevee legacy and Cycles. All setups have identical model, materials and lighting.
Starting with cycles
Eevee Next
and Eevee legacy
I do have the following compositor setup for all three comparisons
You can see that in cycles the shadows under the circuit board edges, whereas shadows are not visible in Eevee and Eevee legacy. The material for the circuit board (the dark grean areas on the right of the board) have a bit of transparancy and you can see cycles is handling that very well for the lighting setup, whereas in Eevee and Eevee legacy they do not show any transparency without having to play with the scene lighting. Overall I’m quite pleased with these results. Thanks to the developers for you hard work.
I spoke with @Jeroen-Bakker recently about point cloud rendering in EEVEE Next.
Currently, the code is shared with the viewport and renders the points as low resolution spheres.
What we spoke about briefly is whether it would be possible to use the same code that renders the light probes to render the points of a point cloud, similar to how Cycles handles rendering points. This would allow up close rendering of perfect spheres, without having the massive overhead of instancing geometry.
I just took some time to play with the volume, and immediately face some problem.
- Volume isn’t showing.
I even started with factory setting, put a principle Volume onto a Cube, it just doesn’t show.
It’s not compiling anything. I can freely panning in the 3D viewport. but it just doesn’t show anything. Changing Settings of shader or light also doesn’t do anything.
It’s solved once I switched to cycle and go back to eevee, I can see my volume in Eevee next now.
I wanted to report the bug, but now I find I can no longer reproduce the issue.
I have to say however it was really frustrating for me at the beginning, and if it happens to other people at the first time, I believe the solution of switching to cycle and then back to eevee may not be immediately obvious.
- Volume in Orthographic View is dark.
I reported here: #124147 - Eevee Volume in Orthographic View is Dark - blender - Blender Projects
This is more involved than this. I still need to make a design task for that and explain the issue with the different approach.
We have now extended the range to [1, 9] in Blender v4.2.
They are not expected to match. Basically, in the compositor, the biggest possible size is 9 and you go down from there by halving the effective bloom size, in EEVEE, the lowest possible size is 1 and you go up from there by doubling the effective bloom size. The maximum possible size for EEVEE is dependent on the image resolution, and is logarithmic in nature. I feel the the compositor’s approach is better in that particular case, because smaller sizes are less useful. But really, I think we should have a [0, 1] float for the size.
Eventually, I would like to do something like you mentioned. So basically:
- Remove the Mix parameter and replace it with a simple Strength input, whose range is from zero up.
- Provide 3 outputs from the node:
- Image. Which is the input plus the glare.
- Glare. The generated glare only. Should it be affected by the strength?
- Highlights. The highlights only.
I wrote a more detailed task about the possible improvements to the Glare node.