HDRP 5.3.0 PPv3 Bloom blurs the whole frame

I hope you didn’t paste that “…” there, the idea was just that you add those top lines there in place of what’s by default and leave the rest as is (and remove existing HDRP line if that was there already).

Unity just pushed 5.3.1 to regular registry. It should now show up soon without manual manifest modifications on your package manager.

Before it shows up there, you can still use modified manifest but you don’t need the staging registry for it anymore.

1 Like

I’ve tried new bloom with 125000 lux light and a skybox with very high illuminance values. In this case bloom looks ok:

Bloom off:

4 Likes

That is interesting, as the actual sun is 128,000 Lux according to Wikipedia. So I guess they are aiming for close to Real world values.

1 Like

I’m trying this new HDRP post effects and it’s deffenitly better than standart. Color correction and other stuff now really good works with light. I make realistic game and very happy. But old post processing V2 not supported, and even not working anymore. This is sad.

I soooo happy that we can now manage tonemapper curve when aces mode in use, i hate how ACES kill all white stuff and that wierd yellow tint, but now i can simply tune it’s as i want!!

1 Like

I spent a decent chunk of time trying to understand why my pp(v2) wasnt working the other day :p. Wish this was more clear in the package manager or something.

2 Likes

yeah people have been discussing that and Unity says they will address this eventually.

https://forum.unity.com/threads/dependencies-not-visible.621868/#post-4181632

1 Like

@ceebeee_1 that’s kinda different issue. HDRP 5.2.3-preview didn’t install PPv2 package either even it still worked on it. The issue thelebaron had here was that there’s no warning that HDRP 5.3+ will not work with PPv2 anymore. If you just put it into project with PP volumes and such from old setup, it still runs but there’s no warning or explanation why it fails.

It’s worth noting that 2019.1 is still in beta and 5.3.1-preview is first “release” with PPv3. It’s totally possible that Unity will add warning about this on future PPv2 (should be trivial to add a warning if people run it on HDRP 5.3 or newer).

Anyone have tips on getting this to look correct? Setting the SampleScene directional light to 125000 lux seems to turn the sky grey(when adding an exposure(physical camera) component to the volume settings), and adding bloom just completely blows out the scene.
What is a skybox with high illuminance values, does that refer to the directional light? Is it something other than a procedural sky?

This is one of the issues (disabling the disc is kinda temp solution):

You also need to boost the procedural sky exposure value as well to get the sky visible again.

1 Like

I’ve just implemented my own procedural sky shader which calculates real world luminance values.
If I change the output to return smoothstep(1000, 10000, finalColor) and disable exposure/tonemapping, this is the output:
4199311--372229--{F5E52273-3174-4AB1-8E4D-18D4898BFE6E}.png.jpg
Direct sun illumination is >10000lux, Earth reflection is <1000 lux, an the rest of the sky is in between.

P.S.: there is still some blurring of the whole screen going on, I would prefer an option to disable bloom for a lower x percentage of output luminance values too.

1 Like

Hey all - here’s a question: what if I have a night-time scene with bright street lights having emissive on the bulbs. I want to apply bloom. The street lights have realistic values. However - even after adjusting exposure and having the scene look right, bloom does not show up unless cranked up almost all the way, at which point even the darkest elements in the scene are completely blurred. What’s up with this?

It seems that since bloom is a kind of hack anyway, that it would be great just to have the threshold slider back?

Not in V3, bloom is physically based there.

New bloom is fine with 0.2 intensity (almost invisible) then increase emission on material to get the old glow behaviour back. Seems fine here.

There is no interest in V2, obviously as it doesn’t work with 5.3x HDRP.

Just found out about this bloom issue while testing in 2019.2a6 and I was wondering if others noticed it too, so I found this thread.

These screenshots from FPS Sample and Fontainebleau demo represent exactly what you DON’T want your game to look like (bloomy, blurry, muddy, overburdened, etc… ):


…and since a lot of Unity’s official demos seem to have that problem, I’m kinda worried that the v3 bloom is actually intended to look like this instead of being a bug. Bloom from v2 was perfectly good. Would love to hear a dev comment on this.

Even with increased lux values, we still really need a threshold value to cut off unwanted bloominess in areas that are not super-emissive

The key to good PostFX is subtlety. Make clean, sharp and unbloated. Avoid unjustified blur, dirty lens and DOF effects at all costs!

2 Likes

AFAIK the bloom is intended to have low intensity values (like 0.2 or less) and now you boost the glow in the materials instead.

But yes, some tweak factor is needed even for true PBR renderers, even mirror’s edge needed to have an unrealistic lux value.

It takes a bit getting used to, having no “threshold” slider and more explicit control. But… by setting the scene’s exposure to a good level and then having some emissive lamp surfaces at intensity 6 in the HDR color picker and bloom level 0.1 to 0.2… it works great.

I personally dislike new bloom even at 0.2 as I can see the extra softening pass on whole screen with that (when toggling the effect on and off). 0.1 still feels safe (but it bugs me that I know it’s still effecting the whole frame even with small value like that).

I don’t really care if it’s physically correct to blur it like that, I don’t want it to do that. It makes no sense to have a great HD renderer and then just blur the results away.

1 Like

Agree that smearing out the whole screen isn’t a wanted feature.

Also, making a source bright enough to have a strong halo blows the object’s colour out to white or a saturated primary/secondary colour (depending on tonemapper.) Which might be realistic, but is very limiting. All I really want is an vivid orange object with a vivid orange halo, but that doesn’t seem achievable… :frowning: