Low polyline primitive performance in cesium for dynamically changing geometries

Hi there,

Test case:
Create 10000 polyline primitives with 2 coordinates, add them in one polyline primitive collection, add the collection to scene.primitives. From their references, change em dynamically with request animation frame. FPS drops to near zero. I guess or I believe there is a problem on polyline primitives’ points setter. 25000 billboards, there are no problems, 60fps, but when you add to polyline primitives into equation, every application created will have low fps and performance issues.

There is a callback property managed by widget or viewer but I am not using viewer. On the other hand even I use it, callback property creates complexity problem when creating software architecture. You should keep references somewhere and shape your application just for cesium’s callbackproperty. You cannot bind container object to that callback property. If you have composite shapes, to be able to manage callback properties, you need to hold your ear with opposite hand unfortunately.

I already used minimum # of polyline primitive collections with many polyline primitives. Cesium is good when you are showing things statically but at high demanding rates like real time visualizations, it starts to lack some features. Creating example with 100000 points, it is okay. Creating example with 100000 moving points with different images + vectors hits the wall.

Any suggestions on improving performance with dynamically changing polyline primitives?

There is an already issue on github, but seems won’t be fixed soon (2017 issue):

The reason a lot of dynamic polylines are slow is because rendering a polyline on the globe requires curving it along the surface, so the geometry needs to be recreated and re-sent to the GPU. The solution to this would be using dynamic buffers, to avoid the need to re-send everything to the GPU every frame, as noted here: https://github.com/CesiumGS/cesium/issues/932.

In the meantime, there may be a few optimization tricks you can do depending on what you’re trying to visualize in your application. I think moving 100k points in a primitive should be fast. You mentioned “different images + vectors”, are these images changing over time? Is the other vector data moving over time? Have you considered creating a pooling mechanism where you have a fixed number of points in the scene, and as the camera moves figuring out what entities should be represented in this view, and rendering only those? This is more or less the underlying principle behind 3D Tiles that allows you to visualize datasets with billions of points, for example, and I think is how the upcoming vector format of 3D Tiles would handle that for supporting time dynamic features.

Heya there,

Thanks for the reply, the issue you linked was exactly the one that I’ve read but couldn’t find again. Yeah that’s the case. Also themikelester’s issue is so close to my situation. It is mentioned on the same issue as linked issue.

I already used object pooling since object creation was also taking time and caching em then just replacing coordinates improved performance but anyways, this was another story. Yeah it works but it doesn’t change the performance problem on primitives already placed on sphere.

Thanks for the suggestions. Using bounding box and showing em only, maybe removing non visible primitives at far camera distances etc. But they are not applicable in my case as well as object pooling. I am aware of in 5m^2 space if there are 1 million vectors and if I am looking em from 1m km away it is meaningless to render all of them since they will hit same pixel. I know 3d tiles, point clouds, I used em already but on 3d tiles you don’t have vector representations for each point. Let’s say the use case have 8 different color of icons. They have no performance problems. I can even put 25/30k or maybe more icons and move em with high performance. Actually the highest performance on billboards I see was on cesium to be honest. Images oftenly never change. But when they have 3-4 vector representations created with polylines, the situation changes.

Thanks for enlighting me about dynamic buffers. Maybe I can work on em. I don’t know gl side so much but I believe I will have the knowledge soon. I can catch things in no time.

Also you mentioned polylines are required to be curved to fit sphere. I don’t need curved polylines, I don’t need to have something like ground primitives (I guess they are working differently like texture based). I don’t need segmentation on lines. Maybe there could be an option to say it doesn’t required to be segmented. Many scenarios have short lines which doesn’t get affected by sphere. Even many distance calculations shortcut too little distances.

If segmentation to create curve is the main reason of performance problems, I can solve it in no time. Yet, I must work for dynamic buffers. Firstly I must understand what is dynamic buffer :slight_smile:

Thanks for the response again,

You should be able to do this by setting the arcType of the line to none (see https://cesium.com/docs/cesiumjs-ref-doc/ArcType.html#.NONE). I’d be curious to see if this leads to a significant performance boost in your test cases.

Hoyla again from Brazil, Samba Djappe!

There is a solution I could come up with. I believe there is no way to increase performance after this point. I hope that I am wrong. I will be waiting for further improvements on polylines in cesium’s graphic stack. I will learn webgl soon, but I am pretty sure that for webgl devs@cesium have more knowledge&experience than me.

I have been thinking… maybe cesium can provide canvas for us (which we can change dynamically) so we can use it as video texture. Therefore, I can use some library like pixi.js and do webgl mumbojambo parallel with cesium to fasten the process.

Anyways, for providing more info, here what I have done yet:

Zoom zoom zoom capoeira mata um… (means “keep up the good work” in brazil)

This is already possible, you can pass a video HTML element or a canvas as the image to a material for your polygon. See: https://sandcastle.cesium.com/index.html?src=Video.html.

If this approach works out for you I’m sure it would be of interest to others to post your results here!