Clamping billboards to terrain - inaccurate positioning

[duvifn]

Hi,
Recently I encountered a problem with clamping billborads to terrain.
Clamped billboards are appearing with an offset of few meters (not a fixed offset).

In order to see this problem you can enter the following sandcastle example.
When you click toggle terrain button you will see the billboard (on the terrain). Click it again (turn the terrain off) and you will see it with some offset.

Sandcastle:

http://cesiumjs.org/Cesium/Apps/Sandcastle/index.html?src=Hello%20World.html&label=Showcases&gist=9a739769ae5f781db3ad3eed90c7cdb8

(I had to add the billboard again in the code since billboards are disappearing when terrain is toggled. Is it a known problem or should I open another issue for it?).

I looked at the code and found a point that could cause this problem, but since I am not experienced in this field I want you to confirm it.

Cesium uses geocentric normal when it calculates the (wrong) updated position.
You can see it here

However when I use geodetic surface normal in this calculation the result is acccuarte.

The following sandcastle example illustrates the difference between the two methods.
Run it and wait until tiles are fully loaded.
Then click 'Place Billboards On Terrain' button.

Three billboards should appear on the map:
Yellow billboard position is calculated with the current method.
Red billboard position is calculated with the GeodeticSurfaceNormal.
The green billboard is just a conversion of the original cartographic, with current terrain height, to cartesian.

The green billboard (cartographic to cartesian) and the red (GeodeticSurfaceNormal) should appear at the same position, so I made a pixel offset to the green billboard.

You can pick a billboard to see by which method it was created.

Sandcastle

http://cesiumjs.org/Cesium/Apps/Sandcastle/index.html?src=Hello%20World.html&label=Showcases&gist=8caeac6aa77715993dff4bf20addc806

You may wonder why the third result's height (green- cartographich to cartesian) is not exactly the same as the geodeticSurfaceNormal (red) height.
A quick look at the code in Globe.getHeight shows that it suffers from the same problem - it uses geocentric normal rather than surface normal.
As a result, the intersection point from which it extracts the height is different and hence the wrong result.

You can see the fixed code here ,
and here .
I can do a pull request for that if you think it's correct...

[hpinkos]

Wow, thanks @duvifn for digging into this and providing the detailed explanation and the code examples!
I think using a geodetic is the right thing to do here, but I'm not as familiar with this part of the code base.

@bagnell does this solution seem right to you?

[duvifn]

A quick look at the code in Globe.getHeight shows that it suffers from the same problem - it uses geocentric normal rather than surface normal.
As a result, the intersection point from which it extracts the height is different and hence the wrong result.

Probably this is the reason to #3411

[hpinkos]

Thanks @duvifn! I talked to @bagnell offline and he agreed that this change sounded correct. If you wouldn't mind putting together a pull request we would be happy to review it. You can see our contributing documentation here: https://github.com/AnalyticalGraphicsInc/cesium/blob/master/CONTRIBUTING.md

Thanks again!