DistanceDisplayConditions for polygons is unreliable and inconsistent

[fawick]

What happened?

For small values of the far value, the DistanceDisplayConditions is not applied reliably. Also it is inconsistent between various geometries.

For example, in the Sandcastle link I provide, there are four entities:

1. pointEntity: shown at 1000 or below
2. lineEntity: shown at 1000 or below
3. polygonGraphics1 which is supposed to be shown at a distance of 1000 or below
4. polygonGraphics2 which is supposed to be shown at a tenth of that distance, i.e. 100 or below

Upon zooming in, both polygons are shown before the point and the line. The difference in their far distance of factor 10x is does not seem to be taken into account.

My expectation is that polygonGraphics1, pointEntity and lineEntity start to be shown at the same distance and that polygonGraphics2 would require a lot more zooming in than the rest.

Reproduction steps

1. Add entities with polygon, polyline or line with the equal DistanceDisplayCondition
2. Zoom in and out
3. Observe that they are not shown at the same distance.

Sandcastle example

https://sandcastle.cesium.com/#c=rVfbbuM2EP0VIn2IjFUVXiXK8QbdeoO06GIbNEH7EPtBK9E2sbJkUFRSt8i/l9TFlmVlvSkiAzZIzpkZnjkcynGeFRo8SvEkFHgPMvEEpqKQ5dr7s5pzZmdxNZ7mmY5kJtTsbHQ5y2ZZXCGTSEd3ealicYieloXO1x93q875Jk+3S4M5t/A6oLdHF16UJM5+3I3RIJGJ8DDLAHgA5vkxoB6kPicBDwMcQMZcO02h54eIE0zCkGLqUwDmbg8U+j4OCEMYIrwHwQBByjjDvh+yIRQyH8w5QiHfoXhAUAgxJpgiPABCFBMf08BkEnZADBOICfEZJwMgzAghHFOTIe1sioQ8xJSGPBja1HcxMcvmx7ziDq+1L8gQ8ylCBBLiVp4CiCilPuK+jwLMdtGb2IYzDAkPWUjdJnKACOM+JRBx3rMnIaPQZmX31NozRANkgzAc9swZhwELuInj78xDnzPK/MCHmPeyOZ19S8OizGIt8wzEea4SmUVaFB+Uirb3+TRSZiCjrBo7HYMR+NeGaykspPVQNOo/svZSkS31ysoZgEWugJMKDaQxh5fmZwKObc38u3dNFLCP8CDnBtUerzY94i2UOWdiqYQouoGN+QOcu6A3heZ1Ks/2Swldqmwfwqw8d+UhM32daam3h2e7nnOqBFvs+ERmdWnYrtojt0abEON2q3Ge5mrvyI68218//+bWy3mpU9OApgNWP3/6MG3NNvJvkd7Jf8QYYHgI/UsmejUGqJlNZKGjLBYfZbFJo63pcEmzl85mP75g5EAXIAjhqHEWp9F6c5/fqLzMkjHQqhTVyrP5frac73ubJyyBsul5HZq7Tc/me5r8dGvtxkdiOVGOWqYPdVFIWxTfBb0y0Xm7vbURkJJR2iP+5o/r68+NyVPNLnt7dk9yuCerS+FKChWpeLVFhxTe1n3vl3bZOXn82xtoZN0fNM8bFW1WMi6GQ7SrjsX1EV7Lae/mrIi1xZoWRTW400pmS+f8h4V5IOT8fNDdbrs9f1Gafonir7cq3whlpNN2PafpMU0X2LNl24BbKXgwzkuFPQx7srLHF1FdQfRtvS+tgvo5nT5j3QDWshD6Xq6FaQw7PoAlpJeLV6zyJ5OQJePS6BCQw8x3pOE3khh+WWL41RLD/0dipjYvSAy/mcTwNyWG30ZidZ0GNYZfrzH8Ko3h79cYflljzVtyHK0Nb94iNaqpk0xKFdW9FHr1HZeIQlt52RivvYtdc1FC42gEQLPHWXbmnk0KvU3FVd3NAfhJrje50qBUqeN5F1qsDenG/cWXMv4qtBcXRf1qAcDkogudJPIRyOT9wD8Je2sWhVlZlGl1Z8/OriYXxv4ImuaROT7L3x+FMqW2Zit09ame9DxvcmGGw0id50acquf5Pw

Environment

Browser: Chrome, Firefox
CesiumJS Version: 1.126
Operating System: Windows 10

[ggetz]

Upon zooming in, both polygons are shown before the point and the line. The difference in their far distance of factor 10x is does not seem to be taken into account.

My expectation is that polygonGraphics1, pointEntity and lineEntity start to be shown at the same distance

To level set, the distance for DistanceDisplayCondition is not applied uniformly to every entity. It's based on the camera distance to the entity's bounding sphere. Since the polygon is much larger than the line and the point, the bounding sphere is much bigger. This means, it's closer to the camera, and therefore shows up first.

and that polygonGraphics2 would require a lot more zooming in than the rest

That would be my expectation as well. Though there's a lot of moving pieces in the provided example with regards to the property system.

@fawick Could you provide a bit more info abut the use case? Is there a minimum example you could provide that demonstrates the issue?

[fawick]

Could you provide a bit more info abut the use case? Is there a minimum example you could provide that demonstrates the issue?

Ah, well, I had hoped that this Sandcastle would serve as such a minimum example.

In my usecase, I typically have an area which is roughly a few kilometers in width and height (an airport). In such an area, there is a CustomDatasource with some hundreds of entities with PolygonGraphics geometry. Each PolygonGraphics only covers a few square meters. The geometry of the polygon may be complex and result in a lot of GL triangles upon triangulation (ground signs expressed as text glyphs expressed as GeoJSON). Here are two example of the Cesium view.

To reduce clutter in the viewer as well as to reduce GPU load I would like to prevent showing these polygons until the user has zoomed in a lot.

However, with a new Cesium.DistanceDisplayCondition(0, 100), the signs are starting to be shown at a much higher "camera altitude" already.

[ggetz]

Ah, thank you for the explanation @fawick!

I think clustering as a concept is how we would handle decluttering. However, being honest, our implementation of this is not as fully featured as it could be.

If I were to implement your use case with the given API, I would probably add a callback property for each polygon's show property. It would turn all polygons on or off at once based on the camera height.

I'm a bit concerned that the CallbackProperty's in your sandcastle example for the polygon hierarchies may be causing issues as well: See #12474.

I'm going to preemptively close this issue since it seems not to be a bug itself. But let me know if you think otherwise, and we can reopen this.

[fawick]

Thank you for the suggestions @ggetz!

Unfortunately, clustering is a bit undesired for this use case as this would also cluster the entity point graphics (smaller green dots) which shall be kept separat even for "high-altitude views".

I am going to look into having a dynamic callback property for show that takes the camera position into account. Do I understand correctly that using CallbackProperty is assumed to be only problematic for polygon.hierarchy? All other properties are "good to go"?

[ggetz]

I am going to look into having a dynamic callback property for show that takes the camera position into account. Do I understand correctly that using CallbackProperty is assumed to be only problematic for polygon.hierarchy? All other properties are "good to go"?

Yes, CallbackProperty is a mature part of the API at this point and I would expect it to work well for other properties.