Cesium in 2017 - what do you want to see?

This is a reply from Matthew to a post of mine about loading large kml files( this support would be great! ):

**The good news is that as part of the work we are doing for cesiumjs.com and 3D Tiles, we will eventually have a way to convert large KML files like your into a 3D Tiles dataset, at which point supporting this use case will be trivial; but I don’t have an ETA on when KML->3DTiles pipeline will be ready. The Cesium side of things is moving along though and you can see Dan’s pull request here: https://github.com/AnalyticalGraphicsInc/cesium/pull/4186 If you were to generate vector tiles from your data, they would load beatifully in that branch; but that is probably quite involved at this point. **

Depending on your timeframe, I expect vector tiles support to be pretty far along within the next 2 months but drag/drop KML -> 3D Tiles support will be several months further out.

Is there any time table for these features?

Scott

Thanks again for all the feedback. Keep it coming!

+1 for additional labeling options.

@Chris what options in particular?

Performance improvements are always +1

@Willem in your experience, what scenarios would benefit most from performance improvements?

support for local/multiple terrains

@Frédéric @Terry stitching together terrain at runtime is not out of the question, but will come with pretty significant performance and complexity. This is much better done offline and will be part of our upcoming cesiumjs.com.

cesiumjs.com KML → 3D Tiles conversion

@Scott we haven’t published a timeline for this yet, but there will be a cesiumjs.com update soon. If you want to contact me directly, I can see if someone at AGI can evaluate your KML and see how far along the converter is for it.

Thanks,

Patrick

Polylines on terrain, more focus on bug fixes, and the ability to show subterranean structures such as tunnels.

Hello Patric (and the team),
Great management initiative. I must say Cesium capability development has exceeded my expectations in the year since first making the acquaintance. Importantly, to me it has become business-critical and truly impresses.

Key on my improvement list is:

  1. Consider split into a stable and development branch/track. The stable track would focus on rapid bug fixes to allow automatic updating without concern. The development track would then be free to test ambitious and possibly breaking changes.

In addition, Cesium still misses some important features that I have either had to work around or have not been able to accomplish:

  1. Dynamic KML network links!!! The current “static” update at launch is not enough and prevents a lot of very dynamic content that Cesium fundamentally already supports.

  2. Ability to safely and easily set default sandbox parameters to allow scripts (have not figured out how to do this robustly, and for me it is essential for dynamic Infobox content). I know this could arguably concerns about security.

  3. Ability to blend layers when baseLayerPicker=true. Two scenarios: one for true visual blending, the other for having different imagery at definable zoom thresholds (min-max ranges).

  4. A bunch of smaller additions:

  • Better ability to control infobox dimensions, including automatic fitting to loaded content.

  • Ability to parametrically completely stop Cesium doing any webgl (globe update) work when under certain conditions, say, when the Infobox is open or when another non-modal window has focus.

  • Implementation of a full-text search widget.for registered fields in data layers.

Appreciate your fantastic work!

Best regards,

Kjell

It would be really great to see photorealistic rendering feature as in Google Earth.
We have developed an AutoCAD plugin that connects the two worlds together (AutoCAD with Google Earth) and we are currently in the process of migrating to the Cesium ecosystem.
You can watch a demo of that feature in https://youtu.be/75aTZUM0jGg

Thanks!

Hi,

we would really like to see the following thinks in 2017

Thanks,

Jannes

Thanks all for the great input, I updated the Google Doc.

There’s lots of interest in sub-surface visualization. I’m surprised there isn’t more interest in modules and deployment. Please speak up if you have ideas here.

Consider split into a stable and development branch/track

@Kjell thanks for the kind words and all the ideas!

For branches, we currently consider the master branch to be the stable branch and then we have short-lived branches for bug fixes that are merged into master often and some longer-running branches for big changes like 3D Tiles. More on our branching strategy is here. What benefits do you see from an explicit development branch? Is Cesium’s master branch not stable enough? Is it somehow hindering the speed at which we merge bug fixes?

It would be really great to see photorealistic rendering feature as in Google Earth.

@bampakoa I’m going to take this as a vote for 3D Tiles. :slight_smile:

I really like your AutoCAD/GE video, I should introduce you to some folks at AGI. Please email me directly.

Patrick

Patrick-

From your list

  • Polylines on terrain; without outlines, polygons clampedToGround on terrain is only half-baked; do I really need to create a single-image provider and overlay a raster of the polygon boundary LINES in 2017? It would save me a lot of work if polylines clamped-To-Ground become a reality in 2017!?!
  • The awesome capabilities of Cesium are being obscured by the presentation
  • polygons clamped to 3D terrain would look really cool, if their boundaries rendered, but there’s something missing.
  • text labels just do not render as readably as users expect - I find even large print hard-to-read; seconding Ian Walberg’s comment “The label text improvement is to the clarity of the label text which is typically quite poor and very difficult to read in our experience.”

Hi Patric,

Re stable vs. development track. My idea was that the monthly master release cycle could be a little too frequent for both end users and developers. Don’t misunderstand me, I really like the fast pace of development. Over the past half year, several releases have broken our app and where we had to either manually change Cesium.js or revert to the previous version. Fortunately, the Bug Bash cleared out a lot of these, but I am generally concerned that production code gets properly tested. Call it fast and slow ring, if you wish. Ultimately, Cesium’s success requires that show-stopping “A” bugs are identified.

The thing that came out of the latest Cesium release, for example, was that zooming got broken with Cromium v55. I guess the jury is still out whether the problem is Google or Cesium, but with automatic browser updating now typically being the default, it effectively killed our app. The only remedy was to manually install the previous browser version and disable updating (which is kludgy in itself). I suggest that this problem could have been captured before the January 2 release in a RC loop with users. Getting users involved in testing at the branch level would of course be ideal, but I think it is too much to ask of most.

One very simple alternative approach, while maintaining the current cycle, is to ask some users to be in an “early bird” group for testing say a week ahead of regular release. Our app has certainly shown itself capable of exposing issues early :wink:

Other than that, KML network link updating is top (triple upvote) on my list…

At the same time I very much support proposals for continued increase in visual quality, with labels as top pri (strangely, labels are fine on my low-res MacAir, but not on vanilla Windows.)

Kjell

Hi Patrick,

We do not have a particular performance issue in mind. Our application uses WPF with a web-control (IE11), and IE11 is not the best in performance, unfortunately.

Thanks, Willem

Hi all,

I think it would be great if 3D-Tiles would be developed further, two things in particular:
- GroundPrimitive support for more Geometry types (polylines.. extrusion..)
- Streaming support for vector features (something along the lines of mbtiles)

I think this is pretty basic functionality (what devs expect when using Cesium) that would help so many people and applications.

Also I think it would be very good to rethink the loading strategy of imagery layers (and terrain) which has been marked more or less here: https://github.com/AnalyticalGraphicsInc/cesium/issues/3857

I think (hope?) this is really low hanging fruit, meaning minimal effort for maximal performance gain.

And these, but they have already been marked "priority":

https://github.com/AnalyticalGraphicsInc/cesium/issues/4368

https://github.com/AnalyticalGraphicsInc/cesium/issues/4673

And finally I guess subsurface support would be very nice!

Have a good one!

Lucas

+1

+1

Finish 3D Tiles spec and Cesium implementation +1

Performance improvements under the hood. Cesium is still not on par with compiled C++ desktop viewers as to the rendering performance. Cesium gets sluggish at times especially when a ot building data is streamed. I would love to have a smooth navigation at a constant framerate even when a lot of data needs to be processed in the background.

+1

+1

Redesign the Texture atlas so image updates reuse the same space in the texture atlas.

> 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?

Hi Patrick,

here is a little bit of something:

http://www.unet.univie.ac.at/~a0707856/Vienna_underground.html

I'm looking for a way to integrate these models in a performant
webmap/virtual globe. If Cesium had sub-surface support, it may be the
ideal tool!

Cheers, Jonathan

+1

We’re loving all the feedback! It is great to see such an active thread and so much interest in Cesium’s future.

New or improved tutorials and code examples.

@Left thanks for all the input on doc. If you have the time to write a tech blog post on your dev and debugging tips, we would be happy to spread the word and even publish as a guest blog post on the Cesium website. Let me know what you think.

3D model documentation has been frustrating lately, needs more than one simple Sandcastle example of what works.

@Left there’s a new example in Cesium 1.29 on model coloring and silhouettes. There’s also another in this development-only example on transforms that perhaps could use more visibility.

What other 3D model examples would you like to see?

Is the incomplete branch for Shapefile and GPX datasources a non-starter

@Left the priority for these just dropped off as we focused on the bigger vision of 3D Tiles. Cesium may still get native support for these (GPX in particular), but converting to 3D Tiles will result in better performance for massive datasets and runtime styling.

The only remedy was to manually install the previous browser version and disable updating (which is kludgy in itself)

@Kjell thanks for the release candidate idea. We could do something as lightweight as just post to the forum and twitter a week before the release and encourage folks to test master. A release zip is available from CI.

We’ll try it for the next release and see if we get some input.

Also, there is another remedy for your issue: contribute a fix. The growth of the Cesium user community is outpacing the growth of the core team (yes, a great problem!) so contributions are always very much appreciated. Get started here.

Also I think it would be very good to rethink the loading strategy of imagery layers (and terrain) which has been marked more or less here: https://github.com/AnalyticalGraphicsInc/cesium/issues/3857. I think (hope?) this is really low hanging fruit, meaning minimal effort for maximal performance gain.

@Lucas lol, if this were easy, it would already be done. For some specific cases, like one layer completely covers another, the optimizations are straightforward. The general case requires more work; true 3D is much harder than 2D since multiple LODs can be visible in the same view. We will be doing a number of optimizations to 3D Tiles in the next few months that we will also apply to terrain and imagery as they prove effective.

Thanks!

Patrick