Yep, its full HDR, format resolving function is inspired by app.graphicsDevice.getHdrFormat(…), with addition of pc.PIXELFORMAT_111110F as default. Framebuffer allocated by PostEffect constructor is still using built-in getHdrFormat(…) though, so those are either 16 or 32 bit under the hood.
Sure, would be happy to add it to official engine posteffects stack!
One important issue though is that its currently full HDR (using this.hdr = true in constructor which is used by PostEffect internally), so it will not work well with any LDR posteffects coming before it in posteffects queue (i.e. LDR depth of field or SSAO). More over, what it does internally - it turns off tonemapping at scene / material level (by making it flat pc.TONEMAP_NONE), and replaces it with tonemapping during final bloom combine stage (when HDR becomes LDR).
So yeah, we could push it in its current form for now, but eventually all other posteffects would need to be updated to HDR as well. May be at its current stage its worth having 2 posteffects folders - LDR and HDR. And slowly phasing out from in-material tonemapping to pure posteffect tonemapping, may be introducing posteffectqueue component coming with camera and including at least a simple tonemapping posteffect in it by default.
Good catch indeed, pc.TONEMAP_NONE doesn’t exist in docs and export, but it still gets suggested in PlayCanvas code editor (with value undefined) and shader chunk for it does exist (pc.shaderChunks.tonemappingNonePS). So this is a default pass through tonemapping function, which is important in our case since unlike pc.TONEMAP_LINEAR it doesn’t multiply color by exposure. Hence we reset global scene tonemapper to pass through, and then set specific tonemapper with exposure in bloom combine.
As for params - that’s just design decision, it doesn’t hold any special meaning. Just embracing old school paradigms from C age Passing param explicitly helps to trace where its used.
Re: black frame issue - what device is that? I’ve tested that script on multitude of browserstack devices and didn’t have such issues. Let’s see if I could reproduce that!
Yea, my C brain still thinks 'uSource' looks wrong, because ' is denoting a char type
Some methods like createDownsampleShader don’t use (params) at all, so the code could just be a bit shorter.
I’m on Linux Mint + Chrome browser… truth be told, I often read that Chrome on Linux “isn’t as good as it could be”, so if it works on other devices, I’m sure it’s another Chrome/Linux issue.
That’s true, but it’s mostly for symmetry - its supposed that shaders would be recompiled on certain params change, so may be in the future other shaders will also use params for parametric code. Starting uniform names with ‘u’ is pretty common in some GLSL communities
Yeah unfortunately can’t say anything about Linux. Did you try it in Firefox? But if it generally works ok and happens just occasionally - that gets it even more difficult to guess!
Right, just tested a while on Linux/Firefox and could see the flicker multiple times… it only happens when I move the camera around (both in only orbit rotation + only orbit translation).
Hi @Adriaaaaan , could you please make a screenshot of current script params? Looks like filter radius is too high. Or may be you’re using 32 bit HDR format which can be buggy on some devices (basically unfilterable)
Hi guys! That’s correct, it’s setting undocumented hdr property of PostEffect to true and looks like it’s affecting all cameras in the scene. I think PC team is currently working on superseding solution with render passes etc - but I haven’t tested those yet
@gumegasonic what happens if you apply this script to each camera in your scene individually?
I see, looks like your UI is configured to be rendered from a separate camera?
Could you please try to set Threshold A and B higher than 1 for all non-main cameras? Also for that test please double check that each Bloom script instance is referencing its own camera in script attribute
I see, looks like your UI is configured to be rendered from a separate camera?
Could you please try to set Threshold A and B higher than 1 for all non-main cameras? Also for that test please double check that each Bloom script instance is referencing its own camera in script attribute