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!
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!
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)