Question, who’s using billboard.eyeOffset.z for anything?
Modifying this Z value doesn’t change the apparent screen position of a billboard, it only affects the depth-ordering of the billboard with overlapping items. But the value is expressed in meters, and the number of meters needed to influence depth order changes with zoom distance from the camera. For example, when the camera is far away from some billboards, moving a billboard by as much as a whole meter might not have any effect on depth ordering. But zoom in too close, and that same billboard could end up behind the camera.
So what I’m testing now is the idea of moving the Z value by effectively a percentage of the distance between the object and the camera (or possibly the distance between the object and the near plane of the containing view frustum, still working on that). The goal is to be able to supply a somewhat-arbitrary unitless number, similar to a CSS “z-index” type of unitless number, and have that represent a near-guarantee of depth ordering for different billboards placed at exactly the same location.
There would be no guarantee of the handoff between app-supplied depth ordering and real-world depth ordering for billboards that were not in precisely the same location. Yet I still have hope that this could be made to “seem natural” in a way.
Let’s say you have billboards “A” and “B”, and you want “A” to be in front when they overlap at the same location. But the two are separated by 100 meters, and the user has swung the camera around for a close look at “B”, leaving “A” in the background. In this case, B still occludes A even though A has a higher z-order, due to B being quite obviously in front. But as the user slowly zooms away from the pair, they come closer together onscreen, and at some point “A” pops in front as the percentage-based z-ordering gets large enough to overwhelm the physical distance between them. Essentially, that’s the feature being proposed here: The physical distances control depth order when the camera is close, but when the camera is far enough away that it’s hard to distinguish distances between objects, at some point the app-supplied z-ordering will take over instead of the physical ordering. The details of how close the camera is when this handoff happens can be tuned to some extent by changing the z-order values, but it may not be an exact science.
What kind of API would the community want to see supporting this? Here are some options:
(b) The same kind of flag could be placed on an entire BillboardCollection, or on the entire DataSource. I don’t like this option much either, mostly because there’s no good way to indicate in CZML whether this should be enabled, and of course eyeOffset.z can be supplied via CZML. Perhaps the flag could be added to the CZML document packet, and affect the setting on the BillboardCollection owned by the DataSource that loaded the CZML document. This seems a bit clunky, but it does preserve backwards-compatibility, by defaulting to false.
So you can tell I’m in favor of breaking it to fix it via ©. Would this cause problems with your existing Cesium apps?