if bloom used R11F_G11F_B10F it would have better color representation?

[VanderSP]

if bloom used R11F_G11F_B10F it would have better color representation? I´ve seen some libs migrating to it, but I dunno the internals

[vanruesc]

Interesting, thanks for pointing this out.

The internal buffers use 16bit floats when the main buffers are configured to use them like this:

const composer = new EffectComposer(renderer, {
	frameBufferType: HalfFloatType
});

R11F_G11F_B10F seems like a nice default now that WebGL 1 is no longer supported by three, but I haven't really used custom internal formats like these yet, so I don't know if there'd be any complications. I'll look into it when I get a chance.

[VanderSP]

Lol, i just tried to do

data.composer = new EffectComposer(UIRenderer, { frameBufferType: RGBFormat.R11F_G11F_B10F })

and looks like working... anyway im not sure what it changes :D

EDIT:

To be honest, now is much better... because if you use halffloat, u must ensure
data.composer.addPass(new EffectPass(camera, smaa, toneMapping))
this in one pass, and bloom in other, lastly...

But now if im not crazy, i can do in any order, and in one pass, and looks interestingly different

data.composer.addPass(new EffectPass(camera, data.bloom, toneMapping, smaa))

EDIT 2:

Okay, let me be more honest yet... because i dunno if you must change other parts...

what I noticed is that maybe theres a small banding, but is non offending... but at least now order independent seems more consistent

and now just one pass

data.composer.addPass(new EffectPass(camera, smaa, data.bloom, toneMapping))

any specific order recommendation?

Thanks.

[VanderSP]

Hmm, just remembered you said in other topic about doing smaa separatadely after... i will test

EDIT: Just to confirm, no matter the order... using directly the custom format produced banding...

[vanruesc]

new EffectComposer(UIRenderer, { frameBufferType: RGBFormat.R11F_G11F_B10F })

Doing this will result in undefined behaviour. The numeric value behind the R11F_G11F_B10F constant may or may not match any of the constants that three expects for the type value of a render target's texture. It's not safe to assume a 1:1 mapping between three's internal values and native WebGL values, especially since R11F_G11F_B10F is an internal format and not a texture type.

To be honest, now is much better... because if you use halffloat, ...

You still need to use tone mapping because bloom always increases pixel brightness and likely pushes them out of the LDR range.

any specific order recommendation?

The general recommendation for correct antialiasing is to apply it in a separate pass after tone mapping has been applied in a preceding pass.

[VanderSP]

so the best is three pass?

data.composer.addPass(new EffectPass(camera, data.bloom))
data.composer.addPass(new EffectPass(camera, toneMapping))
data.composer.addPass(new EffectPass(camera, smaa))

if not it would be tonemapping the original and not bloomed?

if i do

data.composer.addPass(new EffectPass(camera, data.bloom, toneMapping))
data.composer.addPass(new EffectPass(camera, smaa))

i dunno if i can say the diff, would be faster? but technically wrong?

[vanruesc]

composer.addPass(new EffectPass(camera, bloom, toneMapping))
composer.addPass(new EffectPass(camera, smaa))

This works.

Think of it this way: bloom accumulates neighboring pixels into the current pixel. It samples the input buffer to do so. The result is then directly processed by tone mapping in the same effect shader. SMAA also accumulates neighboring pixels and therefore needs to run in a separate pass to "see" all of the updated pixels. And it needs to be applied after tone mapping because it expects LDR input colors.

[VanderSP]

While this looks sensible:

composer.addPass(new EffectPass(camera, bloom, toneMapping))
composer.addPass(new EffectPass(camera, smaa))

this explodes bloom over metallic surface hdr, like hard clipping...

bloom must happen after tonemapping... something is wrong maybe?

i switched to

data.composer.addPass(new EffectPass(camera, toneMapping))
data.composer.addPass(new EffectPass(camera, data.bloom, smaa))

if u want I can take some pics

[vanruesc]

Bloom should only affect colors that exceed that [0, 1] range. In other words, everything brighter than white should bloom (using the default settings). If you apply tone mapping before bloom, colors will never exceed that range and there will be no bloom.

The issue you're describing might be related to #650.

If the bloom effect is too strong, your lighting setup might be wrong. You can either adjust the lights in your scene or try tuning the luminanceThreshold.

[VanderSP]

in the order that fixes the artifact, as i mentioned, the bloom is present and much more beautifull, spraying around the universe...

but in the order u mentioned, it clips to shift color nastyness

Believe it

EDIT: it´s not about aliasing or hard edges, im talkin about white region clipping color, not small points, but entire spots

[vanruesc]

That doesn't sound normal, but either way, it's off-topic.

If you're having problems with bloom, feel free to create a discussion.

[VanderSP]

Thanks for replying... well, maybe using gainmap instead normal hdr workflow would affect?