pmndrs
Compatibility with Three.js clipping planes
Description of the bug
Hi, we are the creators of the IFCLoader of Three.js. We are developing a framework to develop BIM applications in the browser.
We have just started to use this amazing library to be able to have a more realistic feel. It works perfectly: the only problem is that when we use clipping planes, the ambient occlusion of the model doesn't go away.
Is there a way to make the clipping planes work together with the AO post processing?
To Reproduce
Use clipping planes in an object that has ambient occlusion applied.
Expected behavior
The AO of the clipped parts shouldn't be rendered.
Screenshots
In the following image you can see a model cut horizontally, and how the ambient occlusion of the whole building is still there:
Library versions used
- Three: 0.132.2
- Post Processing: 6.23.1
Desktop
- OS: Windows 10
- Chrome
Hi,
it's possible that the NormalPass doesn't see your clipping planes. Are you using local clipping planes? If so, does AO look correct if you use global clipping planes instead?
We're using local clipping. Global clipping works actually, but we're trying to avoid it since it will limit what we can do. Is this something we can solve with local clipping?
Unfortunately, this seems to be yet another shortcoming of three's override material system. Patching it would require individual override material copies for every single object in the scene to maintain the clipping planes of the original materials which is not a feasible option.
The root problem is that SSAO needs scene normals and the only way to produce them right now is the NormalPass. I've tried reconstructing normals from depth before, but ran into issues with artifacts along geometry edges. Perhaps we should revisit this option because there are articles that describe better reconstruction algorithms: https://atyuwen.github.io/posts/normal-reconstruction/
In summary, local clipping planes are currently not supported due to limitations in three, but they will be supported in the near future, either via normal reconstruction or usage of Multiple Render Targets (MRT).
Jumping on the bandwagon here, would you happen @vanruesc to have that Normal Pass computed from Depth available somewhere? It would be helpful for scenes with no normals - for example where geometry primitives are written to depth via custom shaders, like pointclouds. If this could be added to the standard set of Pass of the postprocessing lib - with its set of limitations - that would be nice! Or one could write its own ShaderPass which would use depth as input and do the differentiation on the shader-side.
@jo-chemla That pass hasn't been implemented for postprocessing yet. There are also currently no plans on adding it since v7 supports rendering normals via MRT.
It would be helpful for scenes with no normals - for example where geometry primitives are written to depth via custom shaders, like pointclouds.
I think this is a more complex topic because it touches on transparency, the geometry used to render a single "point" and the usefulness of the rendered normals.
If the points are simple planes then rendering the normals in the vertex shader would be much easier than calculating finite depth differences. However, those flat normals wouldn't be very useful. Transparent objects are also drawn on top of other things which creates conflicting normals for the affected pixels. To avoid this, normals are usually only rendered for opaque meshes.
I'm closing this issue since clipping planes are now supported in v7 which will eventually replace v6.
Thanks for getting back! We do render opaque geometry and have a use for normals computed screen space - for example this video is rendered purely from a massive pointcloud where points are 1px texels (no per-vertex normals, so the texels are not oriented along the normal but simply face the camera) and it has lighting computed from screen-space normals.
I did implement this ScreenSpace Normals Effect following this simple example - can do a PR if you think this can be useful, although with some minor artifacts.
And good luck with v7, a lot of promising features seem upcoming!