Viewer causes renderingGroupId to become invalid

Bugs
1

The sample project：test.zip (65.0 KB)
Our project used defaultViewer of the viewer to build the scene, and I found renderingGroupId invalid.
This is an unusual situation：

异常代码
异常代码964×1022 65.7 KB

异常
异常1968×1110 73.9 KB

This is normal：
正常代码
正常代码865×1001 64.5 KB

正常
正常1936×1094 19 KB

仅仅只是 new DefaultViewer 就会导致本该正常的另外一个本该正常的场景同样发生renderingGroupId 失效的问题，我怀疑可能是 new DefaultViewer 时，修改了某个常量导致了这个问题。可以下载示例代码压缩包后 npm install、npm dev 进行复现。

2

Just the new DefaultViewer will cause renderingGroupId to fail in another otherwise normal scene. I suspect that the new DefaultViewer may have changed a constant to cause the problem. npm install and npm dev can be downloaded to reproduce the sample code.

3

I don’t see any change in the viewer since at least march this year which could explain this new behaviour…

It looks like scene.setRenderingAutoClearDepthStencil is called to disable clearing. You can try to add:

scene.setRenderingAutoClearDepthStencil(0, true);
scene.setRenderingAutoClearDepthStencil(1, true);
scene.setRenderingAutoClearDepthStencil(2, true);

after you get the scene with let scene = viewer.engine.scenes[0]; and see if that helps.

4

Ok, I found this one.

That’s because the viewer is setting RenderingManager.AUTOCLEAR = false, which disables the clearing between the rendering groups.

You can reactivate clearing by doing RenderingManager.AUTOCLEAR = true; after let scene = viewer.engine.scenes[0];.

Note however that this is not new, the viewer is disabling this clearing since april 2018.

5

I think there’s some static property that controls how renderingGroupId works, otherwise scene and engine shouldn’t contaminate each other.

6

Thank you. That’s right