When creating the ClippingPlanes, is there a limit below the surface of the earth where they can not be applied?
It is difficult to recreate a sandcastle, but the same code that works for tilesets just below the earth’s surface will only show the planeEntity for very deep objects andthe ClippingPlanes themselves will not be applied when moving the entity.
Both when this deeper object alone is added to the viewer and when it is added together with another object near the earth’s surface where the clippingPlane works the clippingPlane is not applied to the deeper object.
Hi @mholthausen, when I try to place the tileset below the earth surface and apply the ClippingPlanes, it seems to work fine for me. This is the sandcastle that I created to test it out. Please let me know if it is your use case.
Hello @BaoTran , thanks for your answer. The sandcastle does not quite match the use case.
In our case the tileset represents a geological layer in the underground and is already placed by itself in a depth of ~150,000 m using true world coordinates. Here the PlaneEntity is displayed correctly, but the tileset is not clipped (tileset.root._isClipped is false here).
If I create this layer in our pipeline with the actual height values +150,000 the clipping plane can be applied. The same happens when I move the tileset via the modelMatrix like in your Sandcastle to a depth of 150,000 m.
It seems that no clipping planes can be applied to tilesets that are already placed so deep under the earth’s surface by themselves.
In our viewer, there is no difference in the way the tilesets are added to the viewer, whether it is a tileset near the surface or deep underground. The assignment and positioning of the clipping plane to the tileset is also done via Cesium, right?
Perhaps, at this depth, the usage of clipping planes on tilesets that have been positioned directly without changing the modelMatrix is technically not intended?
Edit:@BaoTran I have created a Sandcastle that reflects our case pretty much. If you change the url (lines 54/55) to the respective tileset and reload the sandcastle, you can see the behavior of the clipping planes. It is the same layer data, one is placed at -140,000 m, the other one at -5,000 m.
Any help here is highly appreciated!
Hi @mholthausen, it seems like the reference matrix of the clipping plane (the matrix that aligns the plane with the tileset) is identity, which will place the plane incorrectly. I’m not entirely sure the cause of it. One thing I notice is that the computed transform of the tileset.root, which is a part of the reference matrix calculation, is also identity.
You can work around the issue by modify the clippingPlanes.modelMatrix = Cesium.Transforms.eastNorthUpToFixedFrame(tileset.boundingSphere.center);
This should align the plane correctly with the tileset. This is the modified sandcastle (line 64). Please let me know if it works.
Hi @BaoTran, thanks for your answer!
This works for the lower placed tileset very well. But this transformed modelMatix is also applied to the clipping planes of tilesets whose clipping planes are already working (see screenshot). This is also visible in your modified sandcastle if you use the first url, where the clipping plane is not placed to the plane entity.
Is there a way to check if the reference matrix of the clipping plane is already placed correctly? If this is the case I would not execute a transformation.
This solution is kind of a hack since we are accessing to the private reference matrix. So, the reference matrix that the clipping planes use is clippingPlanesOriginMatrix. You can multiply the clippingPlanes.modelMatrix with the inverse of the reference matrix to only use your own reference. This is the Sandcastle example (line 63). However, since the reference matrix is private, I’m afraid it can be changed in the future. But this should work for both cases.
Another solution is that the reference matrix above is constructed if the tileset bounding volume’s center is above the minimum height -100,000 in this code. Notice that _initClippingPlanesOriginMatrix is multiplied with root.computedTransform to create the reference matrix clippingPlaneOriginMatrix in this code. So if the bounding volume’s center is above that minimum and root.computedTransform is an identity matrix which it is in your case, you may not need to construct the model matrix.
The two above solutions are kind of hacks though. I will open a github issue within this week to remove the height limit above. I’m not quite sure why it is -100,000 meter
Thanks @BaoTran, this seems to work very well. I will keep my eyes open if there will be any changes in future versions. May you drop the link to the issue here as soon as you could create it?
