@patrick
could Kevin’s ellipsoid code get merged into the cesium trunk? I’d find it useful
Sorry for the late response. Got several points we would like to raise here. We’ve been working with Cesium daily in the past 2 years and have our share of insights (it’s going to be a long one… sorry in advance).
I think one main issue is big data - Visualization of Big Data is one prominent use for Cesiumjs. The issue with Big Data and Cesium is performance (memory, frame rate, load time etc.). This is the main theme of this post, but not entirely.
Here are some points we struggle with that we would love to see addressed during 2016 (would be happy to be actively involved in the process as well):
- Memory optimization - Loading cesium alone takes around 40MB, zooming in (hence, getting more imagery from the server) can get it to around 150-200MB of RAM. Add some data inside (around 1000 entities) and you easily get to 400-500 RAM.
In Cesium 1.16 and 1.17 big steps were made with the imagery/terrain compression. Haven’t checked that yet, but hopefully this might take some of the load of RAM when loading imagery from the server.
The dynamic data is the bigger issue here. When my apps reach 20,000 entities, the amount of RAM needed to hold the dataSources reaches to around 1.5 Gb. And these are relatively simple entities that hold a point and a label. If anything can be done about this memory intake of Cesium, it would greatly improve the ability of Big Data visualization with Cesium.
-
Usability and frame rate - Cesium’s rendering cycle takes too long for the single thread JS world. When testing with 20,000 entities, the “updatePrimitives” method was called over and over again, on every rendering cycle, for around 200-2500 ms each time. This takes the FPS down to around 10 on average, and doesn’t bode well for the rest of the app (not to mention trying to move/zoom on the map). Web workers is one way to do it - move more logic to them and then update the canvas as a last step. Throttle/denounce might be another way to do it.
-
GC optimization - related to (2), GC with Cesium is HEAVY! I see it a lot in big data dynamic apps. GC can take a few seconds sometimes. I believe that a lot of allocation is going on with all the “new” statements going around in the Cesium core code. Haven’t done as thorough research as I should have yet, but it’s definitely on my list of TODO, and would be happy to cooperate with the Cesium team on this (goes for all bullets :)).
-
Unrelated to big data, but I have to conform with the community here - Terrain on by default. Definitely a must this year.
-
z-fighting - this is a really big one when it comes to user experience with big data. When there are a lot of entities in an area, they create a flashing effect. The z-index feature could be a really nice enhancement.
-
2 dimensional representation - while Cesium does support the 2D and Columbus view, leaflet and other 2D maps do it much better. Curenttly, solutions rely on switching between cesium for 3D view and other solutions (i.e. leaflet) for 2D view. Improving the 2D view would allow developers to rely on Cesium alone and improve user experience as well as developer’s experience.
-
Clustering - it has been asked before, but not yet a part of Cesium. We’ve implemented our own client based clustering algorithm (http://webiks.com/ngcesium/clustering/), but this can be a real boost for big data visualization (here’s a leaflet example - http://tnocs.github.io/csWeb/).
-
Level of details - LOD as in a network-links for KML, would be great. Currently, we have to use some undocumented feature (which is also private and cannot be relied on for the long run, like the quad-tree portion of Cesium) in order to achieve this. Either it exists and not documented well enough (a live example would be great) or it needs to be added as part of Cesium.
-
Labels/billboards clutter - we cast our vote on this one as well.
If you reached this part, you must be a very patient person 
Thanks!
Yonatan Kra, CTO at Webiks.com
Interesting features for me could be…
-
a way to get the sun elevation/position in the sky for a given position / datetime.
-
changing color of sun glow to red when the sun is close to horizon.
-
a way to change the colour/texture of atmoshere.
For CZML, I would like to put a function in my CZML object, so that instead of doing the interpolation for me, CZML calls code that I define, allowing for more dynamic behaviors.
Thus, if I had an ellipse that I wanted to dynamically color, I could do something like the following:
ellipse: {
semiMajorAxis: 40000.0,
semiMinorAxis: 30000.0,
rotation: 45,
material: { solidColor: { color: colorFunction } },
}
Then, Cesium would call my color function with a few parameters, so that I can dynamically do whatever crazy logic I wanted, and return an RGBA color value.
Thanks all for the additional feedback.
@Berwyn - what pull request are you referring to?
@Yonatan - for 2D (6), what exactly do you want to see?
@RikM - to get the sun position use Simon1994PlanetaryPositions.computeSunPositionInEarthInertialFrame and Transforms.computeTemeToPseudoFixedMatrix. Changing the atmosphere color has been asked for before and would be a good beginner issue, I submitted #3439. Sounds like you are building something cool. What kind of app is it? Something for Mars?
@Blake - interesting idea. I’m not the security expert, but I don’t think we want CZML to execute arbitrary JavaScript functions. However, we could define new interpolation algorithms in Cesium or have a higher-level declarative way to define expressions (which may overlap nicely with styling 3D Tiles). What type of interpolation algorithms did you have in mind?
Patrick
JavaScript already has a significant culture around using callbacks, so I'm not sure this would be any worse than using jQuery or similar.
For example: Say I have two moving points on a map, a defender and an aggressor. Instead of having the color of the aggressor be static, or interpolated, I could provide a callback function for the color attribute, allowing the color to dynamically change based on the proximity of the aggressor to the defender.
With callbacks CZML could not only describe elements over time, but the behavior of elements in time.
JSON (and therefore CZML) doesn’t allow for functions to be defined, but you can do exactly what you’re describing today in JavaScript. After loading CZML, you can replace any property you want with a CallbackProperty, which lets you return any desired value.
This example uses this technique to change the color of a material depending on whether the entity is currently picked or not:
https://github.com/AnalyticalGraphicsInc/cesium/blob/master/Apps/Sandcastle/gallery/Picking.html#L88
I am developing a paragliding flight simulator! And the atmosphere color/texture could help me to simulate the different weather conditions.
@Patrick - regarding 2D. We have customers who could use the 2D-3D
transition. Cesium's performance in 2D falls behind other "2D dedicated"
geo libraries. I haven't delved into the code (so far, I've used 3D only,
but a request came from several sources for a 2D geo spatial based app).
The idea would be to have a view of 3D for 3D relevant data, while falling
back to 2D when it's not relevant, hence earning a performance boost to the
app. Currently, falling back to 2D in cesium gives no significant benefit
in that aspect, while falling back to leaflet for instance, does improve
performance. Thus, we fallback from Cesium in 3D, to leaflet in 2D instead
of using Cesium in 2D. Increasing Cesium's performance in 2D mode, would
greatly improve the user experience in "hybrid" apps, as well as the
developer's experience (not having to learn and switch between 2 API's).
This comes in addition to various features that exist "built in" in
libraries like leaflet (not to mention that huge amount of plugins that
exist to leaflet). Not only usability features, but also UX oriented
features. Things like animations etc. are very easy to handle in leaflet,
since it's mostly the good old CSS animation. I do not mean animation in
the context of "track an entity in flight" What I mean is simple things
like this: http://tnocs.github.io/csWeb/ - notice the animation on
cluster/decluster. In Cesium, animation is HARD. Not only it is a resource
comsuming event, it is also partly a Mathematical problem.
So there are actually 2 points here: Performance - Cesium is great in 3D,
but falls behind when it comes to 2D. Cesium looks great up front, but is
very hard to customize (and even harder to customize efficiently) - mainly
for UX effects.
@RikM cool simulator! Connect with Sarah if you want to include it in your showcase on the Cesium website.
@Yonatan thanks for the details. Currently, Cesium treats 2D as a special case of 3D (top down orthographic) so there are 2D-specific optimizations that we just haven’t added yet as we have been focused elsewhere. As for animation, improvements to the core animation system will work in both 3D and 2D when we can get to them.
Patrick
1. working with image coordinate system (pixls) with camera model projections.
2. ability to transform from pixel in the image to geo and vice versa.
3. project several images and tranforms between them
4. scalbar widget
My prioritized wishlist:
1. Clamp to ground for entities.
2. Support scaleByDistance for labels. I need this to replace a website that currently uses the Google Earth plugin.
3. A default keyboard handler that uses the arrow keys. (I realize this is easy for us to implement, but it seems redundant for all of us to implement keyboard handlers.)
Thanks for the input. For (3), there is also a related Sandcastle example if you haven’t already seen it.
Patrick
+1 on drawing/editing
also: including a TypeScript definition file in each release would be a huge time saver. right now i’m jumping through a bunch of hoops trying to generate one for the 1.17 release :\
I follow Mauricio Giraldo for the need of a TypeScript definition file.
Thanks Patrick. Yes, I saw the keyboard example. It's strange (to me) that the example removes the default mouse handling and uses alpha keys to move the camera (rather than the arrow keys). I don't expect that it'll be difficult for me to implement a handler, but it seems odd (again, to me) that there isn't a default keyboard handler. I expect that everyone who ports from Google Earth ends up spending a day implementing a handler.
Side note: I'd put "Add a navigation widget" high on my wish-list, too.
Thanks!
Steve, to be honest you’re one of the first people who have brought this up; so I don’t think the problem is as wide spread as you may think. That being said, I agree that having default keyboard bindings available (even as an option) would be a good idea (especially since GE already has it). We’ll write up an issue for it, but no promises on a timeline.
However, if you do plan on writing one yourself, we would love a pull request for it. (hence the beauty of open source) It could start out as just a standalone class that gets instantiated, but eventually we could potentially fold it in as a default. I have a feeling there are going to be some tricky edge cases that will have to be dealt with as well.
I’d love to see a Mapbox vector imagery provider. As especially Mapbox is now moving from pixel map tile data to vector map data, which is rendered on the device and many companies use the same format, I’d love to have an imagery provider for this as well.
I think it would be useful to be able to bind or change model skins (textures) in real time. Or at least linked at a load time.
Sample use case. Imagine a scene with many identical models, that you may differentiate with a different skin. It could be a car races or some other competition.
As it is today, we have to create and load a separate model for every instance and experience at least two disadvantages
- higher network traffic and load time for tens of models
- lack of flexibility in application deployment. For any change in event participants or for a new event the models should be converted again. Some batch conversion process with a command line utility is still possible but makes things too complicated
Vladimir