GroundPolylineGeometry missing/occluded segment

[wallw-teal]

GroundPolylinePrimitive/Geometry with specific points produces a missing or occluded segment (with or without terrain; also with GEODESIC or RHUMB arc types). In the following example, changing the second vertex latitude to 48.499 fixes the issue.

Sandcastle example: Sandcastle example

Browser: Chrome 74.0.3729.131 and Firefox 66.0.5

Operating System: OS X 10.14.4

Edit:
This is easily reproducible with lines which are already interpolated along geodesics, but not with the same granularity as Cesium. The items producing this issue in our application are geodesic lines between points with a granularity of 100km.

[OmarShehata]

Thanks for following up on this @wallw-bits. I'm surprised shifting the position ever so slightly fixes that gap.

@likangning93 do you have any advice on where to look here? Lowering the granularity from the default 9999 does help here, but the gap is still large enough to be seen from space at 500.

[likangning93]

@wallw-bits I might not have time to dig deeper into this for a few days, but if it helps, GroundPolylinePrimitive has a parameter for visualizing the geometry under-the-hood, debugShowShadowVolume. The technique we're using to draw line segments on terrain is actually pretty different from the classic multipass shadow volume technique, but it still involves a piece of geometry that intersects whatever surface the line segment should be clamped to.

With debugShowShadowVolume enabled, I'm seeing that a volume exists for the missing segment even though the segment itself fails to draw on terrain:

GroundPolylineGeometry encodes a description of each volume as a series of planes and attaches this description to each vertex in each volume. It's possible that some of the points/vectors describing these planes for the missing segment have NaN components, when I get a chance to debug I might start by trying to filter for these. All of these vectors and points and whatnot eventually get crammed into typed arrays using Cartesian3.pack, so I'd start by adding NaN checks in there that trigger a debugger and then try to trace the computation that went bad from there.

[wallw-teal]

I looked into this a bit. I did not see any NaN values describing those planes (which I assume to be the bottomPositionsArray, topPositionsArray, normalsArray, etc. in that class). However, if I have breakMiter() always return false, that fixes the issue.

[wallw-teal]

@likangning93 Further inspection shows that the normal computed at the inbetween point here and subsequently packed into normalsArray is the only normal in the entire array that differs from the others. If you make those three values in normalsArray the same as the others, it works.

Therefore I'm fairly sure that the issue lies in computeVertextMiterNormal(), but I'm not familiar with the computation. It does not hit the coplanar shortcut or the flip check in that function. All the other vertexes (start/end and the vertexes for the interpolated segments) use computeRightNormal() instead.

[likangning93]

Thanks @wallw-bits! I think I have a hunch as to what's going on:

GroundPolylineGeometry miters between polyline segments according to an epsilon check, but it does this by simply computing a normal as the average of the directions from a point to its previous and next points.
This issue reveals that just averaging the directions fails when the points are so far apart that the curvature of the Earth matters - I think the normal is ending up more towards the center of the earth than tangent along the surface of the ellipsoid. I'll try using ellipsoid surface tangents instead and see if that fixes this.