Streaming Czml Performance

First, I just wanted to throw out some performance observations and get a sanity check. I’m loading anywhere from 2,000-10,000 satellites by dragging and dropping 25MB CZML files into the Viewer widget. I’m finding that I can load 3 days @ 2 minute time steps for roughly 4000 satellites before the display updates too infrequently to be useful. Each satellite consists of a linked billboard and a label. If I add ellipsoid bubbles around each satellite, I can only show roughly 1000 satellites. If I take the scenario down to 1 day @ 2 minute time steps, I’ve found I can load 10,000. These scenarios all seem to equate to roughly 12 files (thus 12 CzmlDataSources get created). Is this in line with what you guys would expect, performance-wise, for a load like that? I can’t imagine my customer wanting to see all of this data at once, but I am interested in loading it all in but not showing it, so I just want to make sure I’m doing things as efficiently as possible.

I’ve now moved to a server-sent event stream, and according to the CZML Structure Wiki:

To faciliate high-performance streaming, CZML may also be streamed using modern browsers’ server-sent events(EventSource) API. When using this API, each CZML packet is streamed to the client as a separate event

How many CzmlDataSources should I create for these individual satellite packets that are coming in? I’ve tried using a CzmlDataSource for each packet (satellite), but that’s bogged down the display too quickly. I’ve tried using a single CzmlDataSource for all incoming packets (via the process method), but I can’t find any mechanism in the API to notify the visualization that new data has been processed, so the satellites never appear in the scene. I thought the DataSourceDisplay._onDataSourceChanged method might do this, but it looks like that’s only for changes to the time varying property.

Thanks,

Eric

Anyone have any direction for me as to the most efficient way to add thousands of objects into a scenario via a stream? I’m currently sending back roughly 20 at a time and creating a new DataSource each time, but things get very choppy while the DataSource gets loaded into the scenario. Not sure if there is a more efficient way to do this. I can be flexible on both the server side and client side as needed.
Thanks!

Eric

eventSource.onmessage = function(event)

{

try {

dataSource.process(JSON.parse(event.data), source);

this.cesiumViewer.dataSources.add(dataSource);

dataSource = new Cesium.CzmlDataSource();

} catch (error) {

this.cesiumViewer.onDropError.raiseEvent(this.cesiumViewer, source, error);

}

};

I think your rendering performance will be better if you can minimize the number of data sources created. You should be able to process all packets into the same CzmlDataSource, instead of creating a new one each time.

Each data source gets its own set of visualizers, which means they each get their own graphics primitives. For example, if you make 10 data sources, each containing objects with billboards, that will end up creating 10 billboard collections, resulting in 10x the number of draw calls.

I have also seen choppiness while loading new data. I believe the CZML loading code can be further optimized, and that is on the roadmap. Most of our effort so far has gone into optimizing rendering speed after data is loaded. One option is to investigate putting time-slicing logic into the loading code, so only a certain number of milliseconds are spent parsing and loading packets of data each frame. This would be similar to how terrain and imagery are loaded, which maintains consistent FPS at the expense of slower overall loading. It may also be possible to move some of the CZML loading logic into Web Workers, but it’s hard to know whether that will help.