I have some problems understanding exactly how clipping planes work, both positioning and making them actually do what I want to.
Preface/goal
It is important to note that I use a custom terrain provider.
I have an underground geometry. The geometry touches the surface of the terrain and exists below. Imagine it as trench. I want to clip through the terrain at the top of this geometry. It is currently an entity of type polylineVolume because it supports custom shapes (Trapezoid). This entity is not included in the Sandcastle example, only itâs coordinates.
The attempt
I have tried constructing two parallel lines from the original path. The distance between these lines are 0.5 of the trapezoid top width on each side of the original path. Then I extract the coordinates to form a rectangle/polygon. These coordinates serves as a basis for the clipping planes, and is the area I want to clip. I calculate a midpoint and vectors to position the planes.
I use a Plane for each clippingPlane to visualize the position, as I havenât been able to find a way to visualize clipping planes properly. This can be seen in the Sandcastle example below.
The ultimate goal here is to make the terrain clip between the lines seen in the provided Sandcastle link.
The problem
I canât make the clipping planes work. There is no clipping at all. They are constructed from the same values as the panes, and they should overlap which after my understanding should make the terrain clip.
The planes are skewed and not aligned between the coordinates they are drawn between. I can see there are differences based on position on the globe, but I would like to know if there is a more robust way to construct the position/orientation of planes with arbitrary coordinates. I have temporarily hardcoded a solution locally on my machine using a Matrix3 rotation.
Are there any suggestions to how I could move forward to solve this? Most of the information I could find online has been tried without me getting any wiser. Any hints, solutions or resources on how to solve this are appreciated.
The planes are skewed and not aligned between the coordinates they are drawn between. I can see there are differences based on position on the globe, but I would like to know if there is a more robust way to construct the position/orientation of planes with arbitrary coordinates.
The planes are assigned a certain orientation (as you noticed: depending on the position). When you change the code that creates the plane toâŚ
const bluePlane = viewer.entities.add({
name: "Blue plane",
position: midpoint,
// --------------------------------------------- ADD THIS LINE:
orientation: new Cesium.Quaternion(0, 0, 0, 1), // Identity
plane: {
plane: new Cesium.Plane(normal, 0.0),
dimensions: new Cesium.Cartesian2(15.0, 5.0),
material: Cesium.Color.BLUE.withAlpha(0.5),
},
});
then the orientation of the planes should match what you expect.
I tried to follow the computations in your sandcastle, but it requires a bit of time and effort to go through the code and figure out where exactly something goes wrong - particularly, since âsomething being wrongâ might very well just be a sign error (e.g. some wrong order in some cross product, or maybe a point missing in some list).
So I re-used a few snippets from the sandcastles that I created in the threads above, and created this:
It takes the line that you defined, creates a polygon (âtrenchâ) with a certain width, and then uses the points of this polygon to create a bunch of clipping planes. This is broken into a few functions with // short comments that hopefully show the most important steps:
Create a version of that line that is shifted ârightâ
Create a version of that line that is shifted âleftâ
Concatenate these (reversing the second list) to create a âpolygonâ
Create clipping planes from each two consecutive points of that polygon
Throw these clipping planes into a ClippingPlaneCollection
Note that the ClippingPlaneCollection has an inherent limitation: It can, by principle, always and only represent a convex polygon. When the âtrenchâ that you are modeling there is not just a straight line, then this approach plainly wonât work. In that case, you should be able to simply use clipping polygons which have recently been introduced, are described in the blog post at Hide Regions of 3D Tiles or Terrain with Clipping Polygons â Cesium , and might be exactly what youâre looking for.
I tried it out, and the Sandcastle does include that approach (just uncomment the useClippingPolygon() call at the bottom). But unfortunately, there seems to be some precision issue when applying this to the given terrain: The polygon is not represented cleanly when it is very narrow. (When setting width = 10.0, then it somehow works, but still not perfectly).
Thank you for the detailed response. This is really useful.
Iâll be testing some of your snippets right away to see where things went wrong in my example.
My sandcastle example is unfortunately a bit messy since it has undergone several rewrites with different methods. It is however good to see that we have the same thought process on how the logic should be broken down.
I have already tried ClippingPolygonCollection, but I experienced the exact same problem as in your sandbox. Seems to be an issue in the Clipping Regions Demo as well. Unfortunately, there are widths down to a minimum of 0.6 we will have to work with.
The ultimate goal is to extract points from a polyline, form a shape between each point, then create the clipping path (planes). The trench can have different angles, but will ultimately be a combination of straight lines which needs to be connected. I believe this can be solved with additional logic, as the offset coordinates wonât be âconnectedâ. e.g. finding a midpoint.
ClippingPlaneCollection seems to do the trick here, even with its limitations. The clipping will be used in smaller areas, and a visualization without noise would be optimal. Is it the terrain provider that makes the clipping shape âstutterâ when moving the camera? Itâs a noticable difference compared to the Terrain Clipping Planes Demo.
Is it the terrain provider that makes the clipping shape âstutterâ when moving the camera?
I also noticed that. And I cannot pinpoint the exact reason. Some guesses:
It might be related to the terrain provider, but in a non-obvious way. (Using that terrain provider in the âTerrain Clipping Planesâ Sandcastle does not show that âjitteringâ).
It might be related to the geographical location. Usually, the poles are more difficult than the equator (in terms of precision). But the line here is at 62 degrees, which should not cause an issueâŚ
It might also also be the fact that the line that is supposed to be carved out is really tinyâŚ
This may warrant some further investigation (it may be worth tracking that in an issue, but preferably, with more detail about the conditions under which this âjitteringâ can be observed)
I believe this can be solved with additional logic, as the offset coordinates wonât be âconnectedâ. e.g. finding a midpoint.
Yes, if this is supposed to be a âwide polylineâ, then the question about the exact outline comes into play.
(An aside: All this is already solved within CesiumJS, on the level of drawing polylines - but I donât think that there is a way how this is explicility exposed in the API).
A usually important degree of freedom is the connection method for the âjoinsâ, being âbevelâ, âroundâ, or âmiterâ. But⌠to some extent this may become obsolete: WIth the clipping planes being âinfinitely largeâ, the join style could become âmiterâ automatically. The midpoints in your image could just be computed as the intersections of the respective outline parts. When there are very narrow angles, then there are (literally) corner cases that have to be considered, but that may not be important right nowâŚ
The more important point is: The ClippingPlaneCollection can only model convex shapes.
It might also also be the fact that the line that is supposed to be carved out is really tinyâŚ
By using your modified sandcastle example and adjusting width to 100, it seems to be the same amount of jittering, just a bit less noticeable because of the scale.
The more important point is: The ClippingPlaneCollection can only model convex shapes.
Yes, that explains some of the problems Iâve had with ClippingPlaneCollection.
For the shape in my example to be shown underground I see three options:
Use ClippingPlaneCollection. Pros
Works for our current use case with modifications. The user will have to manually choose through a custom interface which midpoint to construct the clippingPlanes from, given a midpoint between each coordinate in the polyline. Cons
Canât handle concave shapes.
Produces jittering in terrain/shape on provided coordinates / terrain provider.
Use ClippingPolygonCollection. Pros
More freedom in constructing the shape.
Does not produce the same jittering as ClippingPlane. Cons
Does not work in smaller areas. Requires that polygons support smaller areas or with higher precision.
Use GlobeTranslucency Pros
Can visualize the full shape underground. Cons
Freedom of camera movement makes camera positioning unpredictable. Camera suddenly âjumpsâ to another position on the globe.
Thanks again for thorough information. I may create an issue on Github about the polygon size as that seems to be the optimal solution in our specific case. Iâll mark the question as solved since your answers have given me the information and perspective I need to move forward with the issue.
