Wow, it's so great to see all this input so quickly! I put together a small Google Doc to help us spot trends in this thread. Keep the ideas coming!
> Label text improvement or alternative way to labeling.
@Ian can you please be more precise? Are there specific issues in the Cesium GitHub repo you are interested in?
> Altitude above ground level
@Klaus what exactly do you mean? Draw objects at a height above terrain?
@Jonathan really cool use cases for sub-surface. Do you happen to have a demo of your work-in-progress?
@Alberto said
> Redesign the Texture atlas so image updates reuse the same space in the texture atlas.
Keep an eye on #2319
Alberto replied: This fix is at the top of my list. Adding the ability to reset, and compress the texture atlas would be great. I'm using the workaround of using one billboard collection per billboard to bypass the texture atlas issue. This workaround is a performance hit when doing updates. I'm going to use a few collections and destroy the collections and create new collections when a count of updates is reached.
> - Better handling of the Gimbal lock. I checked in the World Wind Java map and there is no issue.
Can you please submit a issue for this with specific details?
> - Have a light version of Cesium with basic capabilities. for example, my projects will never use 3D models. Having a light version of Cesium, will it make any improvement in performance?
This would not really help with performance other than Cesium.js being a smaller download. In what scenarios could performance be improved for your use cases?
Alberto replied: You can disregard this request of a light Cesium If there is no significant performance improvement.
I updated the Google Doc summary of this thread. I’d like this thread to converge next week. What other feedback or +1’s do folks have? Any specifics for 3D Tiles? Surprisingly, we haven’t heard much about glTF yet, any thoughts here?
@Svetoslav is there anything in WebGL 2 you are most interested in? For example, uniform buffers will provide a nice raw rendering performance improvement and multisampled renderbuffers will allow Cesium to skip the FXAA pass.
@Alex underwater robots sound cool, do you have a demo link?
Going to be tough to beat everything you did in 2016 here are some thoughts.
Merge 3D Tiles into master.
Fix rendering artifacts (ie lables, zooming inside a mountain)
Improve performance with massive sets of entities. Think worldwide air/ship traffic
Improve Quality of Map Renderings
-OSM looks horrible compared to leaflet
-Mapbox’s vector tile support
All entities should be able to be clamped to ground. Outline support. Etc
Improve tile loading performance, would service workers be appropriate?
Reduce the size on the compiled javascript. Would tree shaking help?
Modernize dependencies. We have better/more efficient options than knockout.
Better VR support (Good excuse for AGI to buy some VR gear, it would demo great, and be fun to develop)
In support of Nicholas’ contribution, let me +1 performance improvement of large 4D datasets.
Cesium’ entity time encoding and resolution is fantastic, but the need for constant checking of the time window seems to severely penalize performance with a lot of objects. A key use-case is object movement tracking (e.g. vehicles) with a line showing the past trail.
Performance collapses when the time slider is used to see how objects move in relation to each other, with lines apparently being completely redrawn – and points interpolated – every time. There also seems to be a race in the background when the clock ticks.
I am on soft ground here, since I have not examined the relevant code, but maybe the renderer could add an index on entity time, possible combined with GPU parallel processing of iso-time blocks of that index? That could help in VR world too.
Based on the other latest contributions I am also getting very excited about seeing WebGL 2 with uniform buffers +1.
Improve tile loading performance, would service workers be appropriate?
@Nicholas Cesium already uses workers to process downloaded tiles; we can improve utilization here, but most of the gains will come from smarter loading scheduling and culling.
Reduce the size on the compiled javascript. Would tree shaking help?
@Nicholas I’m curious: in practice, is the size of Cesium.js causing problems for your users? We do plan to improve things here, but most bottlenecks are with downloading content, not the code. Is your main concern initial app loading?
Modernize dependencies. We have better/more efficient options than knockout.
@Nicholas lol, knockout was the lightweight option when we started! This is not my area, but what do you suggest nowadays?
Better VR support (Good excuse for AGI to buy some VR gear, it would demo great, and be fun to develop)
@Nicholas We plan to update VR with #4311 and #3909. What other support do you want to see? Also, I am curious about what VR apps you’d like to build.
Improve tile loading performance, would service workers be appropriate?
@Nicholas Cesium already uses workers to process downloaded tiles; we can improve utilization here, but most of the gains will come from smarter loading scheduling and culling.
Reduce the size on the compiled javascript. Would tree shaking help?
@Nicholas I’m curious: in practice, is the size of Cesium.js causing problems for your users? We do plan to improve things here, but most bottlenecks are with downloading content, not the code. Is your main concern initial app loading?
The initial load can sometimes be slow. Sometimes we have to deal with a slow connection and there is a couple seconds where cesium is loading. Not a huge deal, but something to consider if you switch build systems.
Modernize dependencies. We have better/more efficient options than knockout.
@Nicholas lol, knockout was the lightweight option when we started! This is not my area, but what do you suggest nowadays?
I hear you! Javascript can move fast. I would probably pick whatever your devs want to work with. React, Vue, etc.
Better VR support (Good excuse for AGI to buy some VR gear, it would demo great, and be fun to develop)
@Nicholas We plan to update VR with #4311 and #3909. What other support do you want to see? Also, I am curious about what VR apps you’d like to build.
We have a bunch of geolocated models. Being able to do a virtual tour of these models at a given time (shadows etc) would be a huge step forward for our application.
So far it looks like the biggest trends are sub-surface visualization, performance, 3D Tiles, KML, and the texture atlas. Here’s the updated Google Doc.
We’ll have continuous planning threads throughout this year, but I would like to wrap up this initial discussion in the next day or two, so if you have input or +1’s we’d like to hear them, then I’ll do a more detailed summary.
In the future, will cesium include the tools to measure something in vertically, calculate volume of 3D tile and also calculate the height from sea-level? Sorry, if this ever been ask in the group, but I happen to find that vertical measurement is not possible.
Some final words before Patric closes this thread, based on extremely positive experience with the new Opera Neon browser (on Win10x64).
Twice the image resolution, lines incredibly sharp, no more gripes on label and image quality, and problems with disappearing objects and zooming with latest Chromium engine gone. Seeing the poorer quality of other browsers open with the same app is actually puzzling.
I have no idea what Opera has done, but probably something with webGL implementation. (Some CORS paranoia issues appeared in my app, but they had a simple workaround.) To me this experience puts many of the comments on the current thread into a different perspective, and it may be far easier to get a quick improvement on some of the display quality issues than assumed. The troublesome aspect is that some of this may be in the hands of browser developers.
Hope other people could confirm and get the positive results I got, though.
@Jazlan any measurements that can be done client-side will likely go into Cesium; otherwise, it would be part of the REST API for the upcoming cesiumjs.com. Either way, we want to cover all of the use cases you mentioned.
@Kjell thanks for sharing your experience with Opera Neon, I have not tried it.
I finally got a chance to read through this thread and I just wanted to add a big thank you to the community for all of the great feedback and a big thank you to Patrick for putting together an awesome summary doc of the discussion.
It sounds like a lot of what the community wants is exactly what we want to work on and I’m really excited about what the future holds.
First off, I’d like to extend a huge thank you to everyone involved in Cesium development and over at AGI. It’s been a treat working with the Cesium code – there’s always an awe factor when showing friends and colleagues Cesium-based projects. I’m extremely grateful for all the work and support the Cesium team has put in over the past few years!
In the future, I’d love to see more development on CZML and chronologically interpolable properties. I’m creating a tool used internally in my company that’s replacing our existing 3D mapping solution. The thing that really blows people away in demos is when I mention Cesium’s built-in timeline and the capability to show how data changes over time. Such a great feature!
The ability to work with negative elevations would allow a huge subset of the mapping community to utilize your tool. I work in the oceanographic sciences and am seeking a tool that would allow our group to render bathymetric data in 3D over the web. There is so much potential here for great visualization to be done if we could just work out of bounds of the land.