Seam in Bokeh Filter

Questions
1

I’m trying to get BokehPass (webgl_postprocessing_dof) to work, but I’m seeing seams appear throughout the mesh. You can see the seam in the demo. As long as there is enough aperture length, the blurriness reverts to being in focus, then repeats itself. As the camera gets closer to a sphere, it appears that the distance interval for the seam gets shorter and shorter. As the camera approaches the object, the seams turns into a series of small ripples. The expected behavior for a depth of field would be that it is in focus wherever the focus is and the foreground and background blur grow in magnitude infinitely.

I anticipate that BokehFilter2 / dof2 might be recommended. The trouble is that the example is much more complicated and I haven’t been able to get it to work. With the original BokehPass, all I had to do was define the parameters and pass it to the EffectComposer (although I was quite frustrated before I realized how low I had to set the aperture value.) Looking under the hood of EffectComposer, it seems it takes care of defining a ‘quad’, which I figure is some sort of screen which fits somewhere into the camera frustum, but the coordinates and configuration of it seem to be tied up with the idiosyncratic dimensions, layout, camera animations etc., Then I understand that you are supposed to “render the depth into color”, and then “render the depth into texture”, and I think I understand the idea, but a bit overwhelming, so I’ve stuck with the original BokehFilter, at least for now.

PS Is this thread out of date? Is it now possible to read the depth buffer? Would I need to make another effect composer? https://github.com/mrdoob/three.js/issues/1116

PPS Do I need to add a texture like all of the examples I have seen, or can I just blur the textureless mesh? (It is postprocessing after all)

Thanks!

2

You can see the seam in the demo. As long as there is enough aperture length, the blurriness reverts to being in focus, then repeats itself.

You mean here? I’m not seeing any seams. What settings show seams for you?

https://threejs.org/examples/webgl_postprocessing_dof.html

3

Maybe he is referring to some steep transitions of the blur effect. This does actually not look right…

image
image.jpg3170×2358 952 KB

Tested with Chrome 76.0.3809.100 on macOS 10.14.6.

1 Like
5

Yes, you have identified the artifacts I’m referring to. The transitions aren’t exactly ‘steep’ because I think they are actually maxing out and then going back to 0. Again, if you get really close to a sphere you can see that the cycle repeats itself in a small interval, and the interval size is based on this distance from the camera. (see attachment)

bokehbug
bokehbug.jpg2552×1457 415 KB

6

What’s also interesting is that I’ve identified which commits have caused the issue.

The last time dof1 worked as expected was r75
https://rawcdn.githack.com/mrdoob/three.js/r75/examples/webgl_postprocessing_dof.html

If you crank up the aperture and maxblur, you can see the focal point (not sure if this is the exactly correct term), move to various points of depth. Then there was a commit with the message “Removed deprecated code in other post-processing examples” where MeshDepthMaterial was removed. As far as I can tell, MeshDepthMaterial is still supported, but I could certainly be wrong.

After this commit, the effect applied uniformly to each sphere regardless of depth (note that as you move the focus control, the camera changes position. However, the changing camera position/changing depth is NOT effecting the blur effect, just the focus control is).

The uniform blur is maintained for the next ten or so releases, until r87.
https://rawcdn.githack.com/mrdoob/three.js/r87/examples/webgl_postprocessing_dof.html

This includes a commit with the message ‘Make DOF work again.’

This seems to basically get the DOF working again, albeit with the seam I mentioned. Two things make me a bit suspicious about this commit. First of all, there are quite a few additions to restore functionality which was removed by just a one or two line change. Secondly, the aperture value is multiplied by 0.00001, which seems quite out of proportion. I suspect that this might be related to the seam because it’s causing some value to ‘max out’ and then reset.

Currently it seems like the key MeshDepthMaterial is in BokehShader, but is NOT in the example ‘webgl_postprocessing_dof.html’. I’m not sure whether it should be in the html file, but last time it worked it was in the html file.

I’ll look at this some more and maybe even make a PR or something if I figure it out.

Thank you for your replies.

7

I don’t think my cleanup commit introduced any breakage since the instance of MeshDepthMaterial was not used in the example at all. Besides, the commit landed in R74 where everything still worked.

The commit of Ben fixed the broken code, although the mentioned seam was introduced. I bet this was overlooked in the PR. In any event, as pointed out by Ben on github, the implementation of this particular DOF shader was a hack from the beginning. It’s probably best to completely replace the code with something more properly. Or just use BokehShader2.

8

You’re definitely right about your commit not breaking anything because I think material_depth wasn’t being used anywhere at that point. Searching around, it looks like it was factored out two commits earlier with ‘Examples: Removed calls to deprecated initMaterial’. At this point, it’s a bit hard for me to tell what exactly caused the change or how.

You’re right about the commit being off by one. The releases which vary are:
r75 (last time it worked right)
r76 - r86 (no depth)
r86 - present (seam bug)

What I liked about dof is that it uses effect composer which doesn’t seem to be implemented on dof2.

Thanks.