KML linestring clamp to ground fails

[hpinkos]

Reported on the forum: https://groups.google.com/forum/?hl=en#!topic/cesium-dev/9wvnNNQcLTA
This KML renders fine when clampToGround: false but doesn't render anything when clampToGround: true. Zooming to it then causes a crash in Scene updateFrustums because NaNs populate the frustum values.
track.kml.txt

var viewer = new Cesium.Viewer('cesiumContainer');
var options = {
    camera : viewer.scene.camera,
    canvas : viewer.scene.canvas,
    clampToGround: true
};


viewer.zoomTo(viewer.dataSources.add(Cesium.KmlDataSource.load('../../SampleData/kml/track.kml', options)));

[hpinkos]

Here's another example from https://groups.google.com/forum/?hl=en#!topic/cesium-dev/7h3W_ICb4wM

test3.kml.txt

[mramato]

This is a corridor geometry bug but only happens when clamping to ground (remove height in the below to break it).

var viewer = new Cesium.Viewer('cesiumContainer');

var redCorridor = viewer.entities.add({
    name : 'Red corridor on surface with rounded corners and outline',
    corridor : {
        positions : Cesium.Cartesian3.fromDegreesArray([
                                                        -16.41549000000001,28.44423000000001,
            -16.41549000000001,28.44423000000001,
            -16.41505000000001,28.44430000000001,
            -16.41507000000001,28.44430000000001,
            -16.41473000000001,28.44460000000001,
            -16.41429000000001,28.44452000000001,
            -16.41430000000001,28.44453000000001,
            -16.41428000000001,28.44452000000001,
            -16.41416000000001,28.44434000000001,
            -16.41415000000001,28.44434000000001,
            -16.41397000000001,28.44408000000001
                                                    ]),
                                                    width : 1,
        height:0,
        material : Cesium.Color.RED.withAlpha(0.5),
        outline : true,
        outlineColor : Cesium.Color.RED
    }
});

viewer.zoomTo(viewer.entities);

[hpinkos]

This is happening because the bounding box/shadow volume minimum isn't quite low enough. For small shapes it's equal with the level of the tile and results in z-fighting.

See #4485 for discussion

[hpinkos]

We should really try to fix this soon. Look how bad this example looks:

var viewer = new Cesium.Viewer('cesiumContainer');

var entity = viewer.entities.add({
    position: Cesium.Cartesian3.fromDegrees(-95.0, 40.0),
    ellipse: {
        semiMajorAxis: 500.0,
        semiMinorAxis: 500.0
    }
});

viewer.zoomTo(entity);

[hpinkos]

Also reported here: https://groups.google.com/d/msg/cesium-dev/hEuF6TWyKdQ/32CP1WhEBQAJ

[hpinkos]

This one still seems to be a problem, unfortunately

var viewer = new Cesium.Viewer('cesiumContainer');

var redCorridor = viewer.entities.add({
    name : 'Red corridor on surface with rounded corners and outline',
    corridor : {
        positions : Cesium.Cartesian3.fromDegreesArray([
                                                        -16.41549000000001,28.44423000000001,
            -16.41549000000001,28.44423000000001,
            -16.41505000000001,28.44430000000001,
            -16.41507000000001,28.44430000000001,
            -16.41473000000001,28.44460000000001,
            -16.41429000000001,28.44452000000001,
            -16.41430000000001,28.44453000000001,
            -16.41428000000001,28.44452000000001,
            -16.41416000000001,28.44434000000001,
            -16.41415000000001,28.44434000000001,
            -16.41397000000001,28.44408000000001
        ]),
        width : 1,
        material : Cesium.Color.RED.withAlpha(0.5),
        outline : true,
        outlineColor : Cesium.Color.RED
    }
});

viewer.zoomTo(viewer.entities);

[hpinkos]

This one is still broken as well #4326 (comment)

[pjcozzi]

@hpinkos check out the debug views for these. Does it matter if they are on terrain or on the ellipsoid? Does hacking in a large negative direction solve the problem? Or is this because the width is defined in meters, not pixels, so the volume becomes very thing?

[hpinkos]

The corridor now renders correctly when added using the Primitive API, but not the Entity API

var viewer = new Cesium.Viewer('cesiumContainer');
var scene = viewer.scene;

var redCorridorInstance = new Cesium.GeometryInstance({
    geometry: new Cesium.CorridorGeometry({
        positions : Cesium.Cartesian3.fromDegreesArray([
            -16.41549000000001,28.44423000000001,
            -16.41549000000001,28.44423000000001,
            -16.41505000000001,28.44430000000001,
            -16.41507000000001,28.44430000000001,
            -16.41473000000001,28.44460000000001,
            -16.41429000000001,28.44452000000001,
            -16.41430000000001,28.44453000000001,
            -16.41428000000001,28.44452000000001,
            -16.41416000000001,28.44434000000001,
            -16.41415000000001,28.44434000000001,
            -16.41397000000001,28.44408000000001
        ]),
        width : 1,
        vertexFormat : Cesium.PerInstanceColorAppearance.VERTEX_FORMAT
    }),
    attributes : {
        color : Cesium.ColorGeometryInstanceAttribute.fromColor(new Cesium.Color(1.0, 0.0, 0.0, 0.5))
    }
});

var primitive = scene.groundPrimitives.add(new Cesium.GroundPrimitive({
    geometryInstances: [redCorridorInstance],
    appearance: new Cesium.PerInstanceColorAppearance({
        closed: true
    })
}));

scene.camera.setView({
    destination: Cesium.Cartesian3.fromDegrees(-16.41549000000001, 28.44423000000001, 100)
});

So the problem is unrelated to the shadow volume problem

[mramato]

If someone wants to look at this, the geometry for the Corridor is created in CorridorGeometryUpdater.createFillGeometryInstance and then it's used in StaticGroundGeometryColorBrach in the createPrimitive block around line 86. There's probably an unrelated bug specific to CorridorGeometry in the Entity API.

[hpinkos]

I'm going to open a new issue with more specific details since we fixed the shadow volume problem.