Performance differences due to distance

Hi there, I’m fairly new to Cesium and have been using it to attempt to put together a little web app displaying the positions of satellites orbiting the Earth.

The issue that I’m hitting at the moment is an apparent impact on performance between a scenario in which I am plotting only near-earth satellites (i.e approx < 2000km from the Earth’s surface) and one in which a similar number of far-earth satellites, i.e. > 35,000km. In both cases the number of entities is roughly the same - around 30ish satellites comprising a billboard, path, and polyline projected from a ground point on Earth to the satellite’s position in space. In the case of the near-earth satellites, it runs smoothly on both desktop and mobile browsers. In the far-earth case, however, performance is notably degraded, and on mobile the frame-rate is almost unusable.

So I was wondering if, based on this description of what I’m trying to do, there is a known issue, or something obvious that I may be doing wrong that would result in this drop in performance?

Assuming it’s okay to post a link, you can (hopefully) observe the behaviour here: Find Satellites - very much a work in progress, so don’t expect anything near a polished, fully functional app there!

Thanks in advance for any suggestions.

Welcome to the Cesium community!

That does sound unusual - if you have the same number of entities just in different positions, it shouldn’t lead to such a noticable performance difference. It sounds like you may be triggering a bug perhaps. Are you able to reproduce this in Sandcastle (https://sandcastle.cesium.com/index.html?) and paste a link here? That’ll help us determine if it’s a bug or something you can fix in your app.

It’s definitely more than okay! You can always share your work here or in the Showcases category, even if it’s just a work in progress and you’re looking to get some feedback: https://community.cesium.com/c/showcases/8

This looks really cool - where does the data come from?

Thanks so much for the reply, Omar!

The data comes from a NASA feed at https://sscweb.sci.gsfc.nasa.gov/ - it provides historical data going back decades, but also predictive data for a heap of satellites currently orbiting. The documentation on the API isn’t great, and there are limits on how much data you can get at once, but by regularly polling the API for satellites currently available with data over the next few hours and dumping those results in a json file to be consumed by the app, I can show real-time data all from static files. I guess to be even more Cesium-ish I could transform the data into czml, but there are other parts of the app that might display or use the data in different ways, so it kind of makes sense to me to have a data model that is decoupled from the specific requirements of Cesium.

Anyway…

It definitely seems to be the presence of polylines that is triggering the performance degradation. I’d like to have a line projected from Earth to each satellite’s position in orbit. If I have that switched off, there’s no noticeable difference switching between the set of near-earth and far-earth objects. When I am plotting polylines, there is, and the issue becomes more pronounced the larger the distances. If I scale or cap the distances at roughly that of the Moon (384,000,000 metres or so) then performance is just about okay, but if I don’t reduce them at all, and try to plot satellites at distances like 183,054,323,000 metres, it just stutters to a halt. Obviously these are huge numbers, and you might expect Javascript to run into issues there, but it’s odd that plotting a single point at that distance from the Earth is fine, but drawing a line is not.

I’ll try and get a Sandcastle reproduction but I thought I’d post this elaboration in the meantime (I’ve not had a huge amount of time to dedicate to this since I posted, hence the late reply!)

Here’s a sandcastle I put together to (hopefully!) show what I mean:

Slooow lines when really really big

Thanks for putting together this Sandcastle example! I’m actually not seeing this performance different. I modified it slightly to display the FPS. On my laptop I’m seeing 30 FPS regardless of whether “near” or “far” is shown.

Can you tell me what FPS you’re seeing for each case? Or is the slow-down you’re referring to the initial start-up time to create these lines?

I think the different in drawing that line vs drawing a very far away point is that a polyline is subdivided along its length (typically to accurately visualize a line that curves around the Earth). One thing to consider here is to set the arcType to “none” (see https://cesium.com/docs/cesiumjs-ref-doc/global.html?classFilter=arcT#ArcType), otherwise the granularity parameter controls this subdivision: https://cesium.com/docs/cesiumjs-ref-doc/PolylineGraphics.html?classFilter=PolylineGr#granularity.

Let me know if this helps.

This is very cool - thanks for sharing this! The only dataset I was aware of current locations of satellites was the data from Celestrak (https://celestrak.com/) which provides it as TLEs, that I think requires using software like STK to convert those readings into paths that you can render in CesiumJS.

I think the different in drawing that line vs drawing a very far away point is that a polyline is subdivided along its length (typically to accurately visualize a line that curves around the Earth). One thing to consider here is to set the arcType to “none”

Omar my good man, that’s it! The annoying thing is that I had already used arcType.NONE elsewhere, so should have realised that the lines I was drawing in that case should have been the same. Of course with the two points having the same lng / lat, just differing in height, no curvature was visually apparent, so this obvious point didn’t occur to me.

Having adjusted the arctype appropriately, performance vastly improved. Thank you!

FYI, in the sandcastle, I was getting about 7fps once all the lines had been created and drawn, max CPU, and mouse pointer struggling to keep up. I’m not on a particularly high-powered machine, though - an 8 year old 4 core 8GB laptop. I suppose there are few use cases that would ever call for geodesic lines to be such a length, and even in that case there’s the granularity configuration that you mention to enable reasonable performance, so all good :slight_smile:

1 Like