Hey Scott – we’re having some trouble reproducing your issue locally. Can you post screenshots of the issue with the stk and vr-the-world datasets? Also what browser, OS and graphics card are you using?
- Rachel
My understanding was that ClampToGround is not supported (yet?) for polylines, linestrings, anything linear including the boundary of polygons. Only points and polygon (fills) can be clamped to ground.
ClampToGround option also requires XY coordinate pairs with no explicit third Z value, not even zero. It does not work with the same data that GE would clamp to ground.
You’re correct that it’s not yet supported for polylines on terrain, but we work around this specifically for loading KML using corridor geometry. Check it out here:
- Rachel
Rachel, my one attempt using the corridor geometry for KML datasource on 3D terrain was a waste of time. It was unsatisfactory for visualization. It is not a solution, it's a workaround by definition. Good luck to you with that workaround in your use case, but I don't think the limited resources of the cesium team are intended to help make workarounds into client solutions. I quit going down that road, because anything i develop based on a corridor geometry workaround may go down the drain, if/when a polyline clamping solution is implemented. Consider corridor geometry better than nothing, but manage your expectations. If it worked well, then polygon boundaries could simply be rendered as corridor geometry, IMO, and this forum would be filled with happy reports from developers satisfied with the result. I share your pain, don't shoot this messenger, and the cesium team is welcome to correct me if I'm wrong
Chrome, Windows 7 Enterprise, NVIDIA Quadro K2100M
These two pics are from the exact same camera position. All I did was change the terrain provider. As you can see the kml LineStrings have moved quite a bit.
Thanks,
Scott
Scott-
Have you considered that the KML line-strings may NOT be moving, and that the terrain is what’s different? There certainly are differences in the vertical values of different terrain sources. What is the horizontal accuracy of the two terrain sources?
You have demonstrated a very interesting issue, but it may not be related to the Cesium data viewer at all.
Best regards, Jon
Jon,
If the camera is in a top down view the roads line up perfectly. As I rotate(pitch) the camera down the roads move away from the underlying imagery with the VR terrain. This doesn’t happen with the AGI terrain. I’m really not sure why this is happening, and I don’t really know anything about the terrain sources.
Scott
Yes, exactly. I noted that the “same camera position” shows the roads in identical locations compared to the screenshot frame, but the underlying aerial imagery shifts with the VR terrain.
I think you have an issue with the VR terrain data, not the Cesium data viewer. You confirmed that “top down” is okay, so its not a horizontal accuracy issue, the issue is the relative vertical accuracy of the two terrain sources you compared.
The underlying imagery moves away from the roads, not the other way around.
The roads are your “reality check”, they are the one constant, remaining in the same position.
It caused by the parallax, or perspective view. The VR terrain (with the aerial imagery draped over it) is noticeably different, and lower, than AGI STK terrain, and as you change the camera pitch, you are looking underneath the roads, which appear suspended in the air above the VR terrain. But the roads are in the same position as when you viewed them compared to STK terrain. The roads didn’t move up, the VR surface moved down,
Scott (and Rachel)
Frankly, this gets back to my earlier rant with Rachel. Scott’s line-strings are NOT “clamped to ground”.
Hi Scott,
Yes, this is happening because your polylines are actually under the terrain instead of on top of it. We have a workaround in KmlDataSource that will tell the code to use a corridor that is clamped to terrain instead of a polyline if you set the following properties on your LineStrings
1
gx:altitudeModeclampToGround</gx:altitudeMode>
``
The corridors have a width in meters so they don’t stay the same width in pixels the way polylines do when you zoom in and out. But this is the best workaround we have until we have full polyline on terrain support.
Best,
Hannah
That definitely fixes the problem, however the performance is not acceptable. The frame rate drops down to 12-4 FPS. Is this issue being worked on? Or is this something that will be fixed by the 3d-tiles/vector features coming up?
Scott
Hi Scott,
Yes, with the amount of data you have using 3D tiles will ultimately be the best solution for you. I think we’re going to be working more on vector tiles soon.
Best,
Hannah
We have a graphics service that creates kml for points, lines, and areas. The areas are clamping to the terrain correctly, but I’m still having trouble getting LineStrings to clamp to the terrain.
Is there a sample KML file that demonstrates the proper way to get lines to clamp to the ground?
Scott
I wasn’t setting clampToGround = true when the kml was loaded. I added that, and the lines are now clamping to the terrain correctly!
Glad you figured that out, and thanks for posting your solution back here!