im currently struggling to display scene axes (ground grid, colored lines) occluded by the original scene. while gizmos work perfectly fine as overlays using the utility layer renderers, im struggling to render scene axes and grids occluded by the original scene. furthermore adding the axes and grid to the original scene will introduce new issues with screen-space postprocessing effects (they should not be affected).
utility layer renderers work fine for overlays, what about things that need to be occluded by the original scene? in my case the scene axes and grid should not be overlayed over the original scene.
adding the axes and grids to the original scene instead of the utility layer renderers adds some new challenges: post processing effects (such as e.g. DoF) will affect these meshes.
ive tried creating multiple scenes and/or multiple cameras (including layer masks) to handle this issue, however ive always run into issues regarding the post processing effects in the original scene (using default rendering pipeline and SSAO2 rendering pipeline).
If you want your grid and axes to always be rendered behind other components of your scene, you should considerer the renderingGroupId attribute.
See Transparent Rendering | Babylon.js Documentation
About postprocesses affecting all meshes, I guess this is normal as postprocesses are attached to a camera and apply to what the camera has rendered. A solution with multi-camera seems to be the only way.
thanks for the reply. however after some more tinkering ive realized that the scene axes and grid need to be occluded by the original scene, not just ābe behindā it (as stated in the original post). my goal would be to have something close to the blender viewport. there you can clearly see that the scene axes and grid are occluded properly by the cube:
ive updated my post with better wording (occluded instead of behind) to properly communicate my problem. sadly rendering group ids wont be of much help in this case.
ive tried the approach with multi-cameras, however had issues with the post-processing of the scene camera interfering with other cameras (e.g. errors, second camera not rendering, ā¦).
maybe there is a better/proper way to solve this instead of using multi-cameras? or am i just missing something crucial with the multi-camera approach?
By default, AxesViewer creates the axis with renderingGroupId=2, and the depth/stencil buffers are cleared between rendering groups. Thatās why they are displayed above the scene.
You can either pass null to the 3rd parameter of the AxesViewer constructor if you donāt want renderingGroupId to be updated, or call scene.setRenderingAutoClearDepthStencil(2, false, false, false); to avoid clearing the depth/stencil buffers for rendering group id 2.
As for AxesViewer not being affected by the post-processes while still being occluded by the geometry, I havenāt yet found a solutionā¦
after some more digging ive found out that theres a utility layer renderer which is supposed to keep the depth map, however after trying to use it this is the result of spawning all elements on this layer/scene: https://playground.babylonjs.com/#X3UEMG#11
Are you sure you tried hard enough using this approach? Looks to me like it is the pp breaking it. I would rather think this could eventually be avoided with a multicam approach combined with a depthRenderer? May be @Evgeni_Popov or @sebavan could have another look at it?
probably not, however at the same time im not that knowledgeable in that area specifically so resolving the issues ive faced there seemed quite hard for me. especially since it seemed to break a few rendering features.
however it breaking MSAA is a bit of a dealbreaker for me. also seems quite hard to implement in an environment where cameras can change and be re-created (e.g. different class). i could be very wrong on this assumption though .
Indeed. Same for me actually, dare I say it
Reason why I called back the experts. These guys helped me with a similar issue and if they canāt make it then Iām afraid nobody can (and certainly not me ) Letās just wait a little and hope for the best
Donāt you want the axis viewer to also be occluded by the geometry of the scene? Thatās the problem, if you want that it is not affected by the post-process at the same time.
sorry if the initial question/problem is a bit confusing: my current goal is to display scene axes (e.g. colored line meshes) and a grid (ground mesh + grid material) occluded by my actual scene. basically imagine a fresh blender scene/workspace. however, currently these axes are being affected by various post processes if they are spawned into the actual scene. using utility layer renderers or multi-cameras so far lead to issues with the post processing failing or the occluding will just straight up not work.
being able to control if gizmos are occluded by the scene or not would also be an useful option; however the primary goal is the one initially mentioned.
Sorry, but just to make this clearā¦!? From a (simple) UX perspective, why would you want to occlude the gizmo with the mesh? This doesnāt sound very user-friendly to me (of course, my opinion only). On the other hand, excluding the gizmo (and the grid) from post-processing does make sense and rings a bell for me.
EDIT: Apologies, I just did read your latest post more carefully. It seems you are not talking about the gizmo, but the scene axis. In case, the scene axis are static and could be simple lines parented to the grid. You wouldnāt need a gizmo or a utilityLayer for these, would you?
issues with this approach: without a utility layer they will get affected by post processing. with a utility layer and post processing the depth wont be respected (no occluding of axes and grid).
Ok, but isnāt is so that with a multicam approach and without using a utilityLayer to draw the scene axis, we could clear the buffer and render post only on the meshes viewed by the second camera and then also exclude the utilityLayer for the gizmoā¦similar to what @sebavan suggested for me to exclude both the 2D and 3D GUIs from PP (and then render the 3D GUI ābehindā the 2D GUI)?
Using the depth sharing technique described in my other post, you can make it work:
However:
it does not work with MSAA (FXAA can help)
you must use the geometry buffer renderer with SSAO2, not the prepass renderer (true for the 5th parameter of the constructor). Not too sure why (maybe because the line shader does not support the prepass renderer, or because it uses multi-render targets)
for some reasons, the 3rd rendering is not ok, while all others areā¦
.
) Letās just wait a little and hope for the best 