Kml problem

The attached kml file renders filled in when it’s loaded in Google Earth, but does not when loaded into Cesium. Does anyone have an idea how I could change the kml to get the same results?

TIA, Scott

1_1493648562.kml (1.91 KB)

With the file you supplied, I’m seeing identical behavior in both Cesium and Google Earth. Can you better explain what you are seeing differently? Perhaps with screenshots of both GE and Cesium?

I don’t see anything in Cesium. If you zoom way in, you can barely see a line. I think I’ve figured it out though. We load all kml with the clampToGround set to true. This is probably why you didn’t see a difference. I noticed that if I change the altitudeMode to relativeToGround in the kml then things load as you’ve described. Is there anything you could add as far as the expected behavior? It seems like if the kml specifies clampToGround and the kml is loaded with clampToGround=true then the lines are barely visible.

Scott

Unfortunately there’s no good solution here at the moment.

The problem is that when you set clampToGround to true, all polylines are drawn using corridor geometry (which is in world space, not screen space) so zooming out and in causes the width of the “line” to grow and shrink. We’ve experimented with recomputing corridor geometry automatically in these cases so that we can approximate screen-space pixel width, but this is fairly CPU intensive when there are a lot of lines. (and rendering is GPU intensive with lots of ground primitives as well).

Obviously everyone (including me) wants to see “true” polylines on terrain that behave no differently than normal polylines, but this is an open research problem for us and doing it efficiently in WebGL is incredibly difficult. There’s even a chance that the only long term solution will be having a server do some computation up front (which will probably be our solution for lines on terrain support in 3D Tiles).

Sorry I don’t have better news for you, but you can follow along this issue https://github.com/AnalyticalGraphicsInc/cesium/issues/2172 which will be updated if/when we make progress on this.

As an aside, I’ll add that solving problems like this for the web is one of the reasons 3D Tiles exists, the approaches that Google Earth and other applications take are simply not viable in JavaScript and WebGL, making supporting legacy formats like KML more challenging than they seem at face value.

It seems as though I have two choices. I could change our kml writer to always use relativeToGround, or never use clampToGround=true when loading the kml. Unfortunately, I can’t really selectively set clampToGround=true when loading kml. Is there an advantage to either approach?

Scott

I’m not really sure how relativeToGround helps you here, since it fundamentally changes the meaning of the altitude values (unless you mean you would set relativeToGround and then update all of your altitudes accordingly). There’s really no advantage to one or approach or the other, it all depends on your exact use case and what you’re trying to accomplish, so just goes with what works best for you.

The long term answer is that we really want clampToGround to be the default and for the behavior to match what you would expect (lines sized in screen space and clamped to terrain), but that’s easier said than done.

This is still UNRESOLVED, I understand the problem, but I have not found any workaround.

Minimized sample is:

var viewer = new Cesium.Viewer(‘cesiumContainer’);

var options = {

camera : viewer.scene.camera,

canvas : viewer.scene.canvas,

//elipsoid:Cesium.Ellipsoid.WGS84,

//clampToGround: false

};

viewer.extend(Cesium.viewerCesiumInspectorMixin);

var zoomTarget;

var kmlFile = “https://raw.githubusercontent.com/ainthek/map-projects/master/data/samples/altitudeMode.relative0.kml”;

var promise = Cesium.KmlDataSource.load(kmlFile, options);

Cesium.when(promise, function(dataSource) {

viewer.dataSources.add(dataSource);

zoomTarget = dataSource.entities.values[0];

});

viewer.flyTo(promise);

``

Can you describe what your issue here is? Is your goal to have this label clamped to the ground?

<iframe width="100%" height="500px"

src=“https://cesium.com/cesiumjs/cesium-viewer/index.html?source=https%3A%2F%2Fraw.githubusercontent.com%2Fainthek%2Fmap-projects%2Fmaster%2Fdata%2Fsamples%2FBMXRaceTracks.googleearthpro.kml”>

Goal is to have labels visible :wink:

When I drag the file, in viewer, sometimes it works sometimes it is “underground”.

When the file is supplied as URL in ?source= attribute, it is all underground:

All layers in KML are clamped:

https://cesium.com/cesiumjs/cesium-viewer/index.html?inspector=true&source=https%3A%2F%2Fraw.githubusercontent.com%2Fainthek%2Fmap-projects%2Fmaster%2Fdata%2Fsamples%2Fanimated%2F2Tracks%2F2Tracks-OnePath2.kml&view=17.107596969021365%2C48.208057039530395%2C849.4394228064385%2C27.690398517150967%2C-37.14320709640736%2C0.021862316192612214

You need to also tell CesiumJS to clamp the KML to the ground (even if the KML has that setting).

You can do this if you put your app code in Sandcastle (or hosted anywhere else like on Glitch), the getting started guide shows you how to do this:

https://cesium.com/docs/tutorials/getting-started/

And then you can set the clampToGround as needed and/or do the double viewer.flyTo workaround I recommended here: https://github.com/CesiumGS/cesium/issues/4327#issuecomment-604005624

Thanx for your time:
a) so it is bug and it is not resolved yet, correct ?

b) your sandcastle demos shell include terrain: var viewer = new Cesium.Viewer(‘cesiumContainer’,{
terrainProvider: Cesium.createWorldTerrain(),

});

c) it is still ugly it goes underground and up.

But thanx