corridor performance

Hi!
We are using Cesium to display a lot of trails;
with polyline + flat terrain we can use how many tracks / points we want,
but if we use corridors + 3d terrain (terrainProvider: Cesium.createWorldTerrain()) we have a huge performance hit, it becames unusable at all (if it doesn’t crash).
We tried:

  1. to decimate the points per track (to just 2 per track!)
  2. to change the cornerType to MITERED
  3. to merge all points in a single track
    but we have not solved the problem. Point 3 gives us a modest improvement but we have 1 frame every 2 second so we need a huge improvement :slight_smile:
    We also tried to use polyline calculating the height of single points but there are a lot of problems (if you have convex terrain between two points the segment of the path is hidden below the terrain; it seems that the polyline has no z-buffer) so I doesn’t consider this an acceptable solution. As a workaround I prefer to display all trails on a 2D model and then switch to 3D just for the selected trail.
    QUESTION TIME :slight_smile:
    a) we are doing it wrong?
    b) I imagine that a simple object (a corridor) on a complex surface (the 3D terrain) requires a lot of polygons; I found a way to limit the texture resolution of the terrain but not the complexity of the 3D model. There is a way to limit that?
    c) [aside the corridor problem] can I tell Cesium to load terrain texture just for a precise area?

Thank you a lot! Is just 2 weeks we are working with Cesium but it’s incredible, really a huge project. You have my highest esteem :slight_smile:

We are using Cesium 1.43.

—Code—

for (var n in Tracks) {

Corridors[n] = viewer.entities.add({

corridor : {

positions : Cesium.Cartesian3.fromDegreesArray(Tracks[n][‘Points’]),

width : 10.0,

cornerType : Cesium.CornerType.MITERED,

material : Cesium.Color[Tracks[n][‘Color’]]

},

name : Tracks[n][‘Name’],

description : Tracks[n][‘Description’]

});

}

Update: using polylines with a lot of points (obtained with interpolation) we avoid the problem of the convex terrain between two points (polylines resolution is higher than the terrain one) and with depthFailMaterial we can manage the z-buffer problem; adding a little bit of height offset we manage the remaining biggest remaining graphical glitch BUT I consider that a workaround (there are some drawbacks), because the perfect primitive to draw a trail is a corridor.
It’s incredible that with the interpolated polylines (~120.000 points) we have absolutely acceptables performances, but drawing ~500 corridords with just 2 points each (begin and end, total ~1000 points) we have a huge performance hit.

I understand that a single corridor is composed of a lot of polygons but the performance difference is really huge, 1.000 points vs 120.000 points and 0.5 fps vs 25 fps (my estimate, if you need I’ll measure it).

Thank you!

Hi there,

I understand the frustration. We are currently looking into supporting polylines on terrain, so that will mostly likely solve the problem you are having here.

In the meantime, try setting the granularity property of the corridors. It reduces the number of samples along the length of the geometry.

Thanks, hope that helps,

Gabby

Hi Gabby!
I was more frustrated before finding the latest workaround, polylines + points interpolation + a little bit of offset, it’s dirty but works;
however clamped to ground polylines are the definitive solution, we are waiting for them :slight_smile:

(just curious: Cesium can clamp to ground complex geometries but not polylines, why?)

We’ll get a try with corridors + granularity.

Thank you!
Claudio

Good that you have some workarounds at least!

It came down to making sure they were efficient enough for realtime rendering. There is a much more in-depth discussion as well as some resources in issue #2172 if you’re interested in reading up!

Hi,

We are experiencing the same performance issues with corridors over a 3dtileset exported from ContextCapture, we use a clippingPlaneCollection to clip the terrain and base layer where the 3dtileset is. The workaround is the same. Use densified polylines with a little height offset to view them over the 3dtileset.

We are using version 1.43 of Cesium too.

With polylines performance is great, the movement of the camera when the 3dtileset is shown is smooth.

Great work! Thanks to the Cesium Team!

Awesome, glad there is a solid workaround in the meantime while we work on polylines on terrain!