postprocessing
postprocessing copied to clipboard
if bloom used R11F_G11F_B10F it would have better color representation?
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
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.
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.
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...
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.
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?
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.
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
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 https://github.com/pmndrs/postprocessing/discussions/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.
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
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.
Thanks for replying... well, maybe using gainmap instead normal hdr workflow would affect?
So I think that when i found the wrong order working better, probably was because i was exaggerating because of the blending function transparency issue that you will implement on next 6.xx interaction... also could you put the optimized rgb format on it? or better wait to use it on v7 already implemented, (when selective arrives)
could you put the optimized rgb format on it?
R11F_G11F_B10F has been implemented in v7.0.0-beta.12 which was released yesterday. There are no plans to implement it in v6 because v6 is in maintenance mode.
Thanks for your crazy man work here...
I´ve seen you talking about SMAA T2X... this sounds top of tops AA, will be same performance range or a bit expensive? anyway v7 will be faster when using bloom + smaa? like less passes for bloom or buffers something like that?
will be same performance range or a bit expensive?
It will be slower than plain old SMAA, but I don't know how much. It should be worth it though in terms of frame-by-frame stability.
anyway v7 will be faster when using bloom + smaa?
It's more about architectural capabilities; implementing advanced effects with v6 is not possible unless you add tons of inefficient workarounds. The point of the v7 redesign is to make it possible to implement modern effects efficiently.