What would you like to see in CesiumJS?

Hi all!

Recently, the CesiumJS team has been prioritizing some internal and developer-oriented fixes recently like testing and tooling improvements, and a re-vamped model architecture. We’ve also worked on more user-facing improvements like support for 3D Tiles Next and improved atmosphere rendering.

Now, we would love your input for what to see in CesiumJS in the near future!

Please help us prioritize what you would like to see in CesiumJS. Your feedback can be as short as a vote for a topic, or a more detailed response. Links to existing GitHub issues are also welcome.

A few things on our mind:

  • WebGL 2 by default
  • Visual quality improvements, such as billboards and label rendering
  • An easier-to-use Camera API
  • Documentation and learning content improvements
  • Tooling or packaging updates
  • Sandcastle app improvements, new or improved learning examples
  • Web XR
  • Web Assembly

To incorporate your feedback into the roadmap, we’d love your input by the end of September. However, we always value your input, so please feel free to add anything afterwards if it comes to mind.

Gabby and the CesiumJS team


@Gabby_Getz ,

Seems, you people are really working hard to make improvements in cesium js. And whatever points you have pinned above, after working on these points it will be easier for people to understand and learn cesium js for their applications.

Gabby, Also I would like to suggest you, your team should be a little more frequent to reply on the questions which are getting asked by cesium js users and developers, If you will give us right answers on right time then it will motivate us to be more friendly using cesium js in our applications.


Thanks for your feedback @basant1431, and thank you for being patient with us as we balance development and community support.

Hi there,

Actually, there is one thing I’ve thought about quite a bit that’s been, well, not impossible to work with, but something I thought could be done better; events.

There’s a few events here and there in the system, in different objects, and so on, however they’re not always consistently named or placed in context (ie. ready vs. onReady), sometimes they’re named with or without their source (ie. loaded vs. tileLoaded), sometimes plain events, sometimes Promises, sometimes callbacks, and so on. Sometimes an event returns a known error class instance, other times “some data” you have to figure out, and so on. Sometimes you get an Event error, and a Promise ready (that sometimes is called readyPromise, other times just ready). You have the same system across all the various collections, so instead of Collection.added/removed/changed, we get named events like Collection.dataSourceAdded/dataSourceMoved/dataSourceRemoved when we already know it’s a Collection for DataSources. Would be nice to have a simpler model that’s consistent across it all (if just for using proxy functions) with just Collection.added/removed/changed, etc. think like a Collection interface.

Then there’s all these things I wish there were events for, for example with EntityCollections instead of three different events, we get this compound; CollectionChangedEventCallback(collection, added, removed, changed), but I would love that split into individual events. And … what does ‘changed’ mean? There’s no info on what has changed, so I have to invent some kind of change detection to figure it out, even though I suspect you already have one hidden in there somewhere … (never mind that it’s a Collection with a CollectionChanged name…)

Which leads me to the lifecycle thing; an event triggers because something happened, however for the most part we get no events for things that are about to happen. For example, I might get a CollectionChangedEventCallback(collection, added, removed, changed) where I find some entity removed, however by that time it’s often too late, for example I had some callback function in the render cycle attached to it, and now I get a crash unless I do checks like against this, which feels counter-intuitive. It would be great to have a before and after event, like EntityRemovedBefore(entity) (and if you want to be fancy, timed ones to allow for reactions to events, as in “about to be removed in 5 ms”), or go the full hog with a lifecycle event structure (as in, all events gets init,begin,during,end events).

Some collections don’t even have events, like PointPrimitiveCollection (or any primitive collection) or PolylineCollection. And some places there’s callbacks instead of events, like PropertyBag can be instantiated with a createPropertyCallback (which has the description “A function that will be called when the value of any of the properties in value are not a Property” which, uh, I’m having a hard time understanding :slight_smile: ). There are other places that uses callbacks where events make sense, and probably vice-versa.

All in all, and just off the top of my head (I didn’t do extensive research into this, it’s just from memory working with the API over the years), it would be great to maybe tidy up some of these things. More and more applications are becoming event-driven (I do a lot of RxJS event driven stuff, and I often have to proxy and hack around the API to make it work).

Having basic event listeners is fine and all, but there are also lots of things we could do to make things more consistent, more efficient, leaner, and by extension, easier to understand through simpler, more consistent and more plentiful events.

Anyway, just my little input there.



  • Visual quality improvements, such as billboards and label rendering
  • Tooling or packaging updates
  • Documentation and learning content improvements. I know some blog articles might had mentioned, e.g., how to improve performance when large geojson/objects imported, migrate to version 1.97+, move from webpack to vite/esbuild, however, more pratical examples are always welcome.
    Also WFS support, and some toolbox as plugins of CesiumJS, like Density plot module, easily add/edit shape/geometry/label/ on map, 3D presentation module, flow field addon… Maybe some of them are out of scope/not practical, but if any ideas or examples had shown, that’s also a great help. Amazing and really appreaciate what Cesium had done so far. Thank you all for working on these.

I think I posted this the last time you asked for priorities, but I’d sure love to see a “bug bash”, going through known open bug issues (currently 578!), assigning severity, and addressing the worst of them.


Thanks all for the feedback so far!

We definitely hear you on topic such as API consistency/ease-of-use, bug fixes, and documentation/learning material. I would love to hear if there are more specific ideas regarding documentation and learning material. What topics would be most helpful? Is there anywhere in particular which has gaps?

Please keep the ideas and feedback coming!

1 Like

Well, there’s a lack of documentation on how your various bits hang together and can use Cesium the best / most performant, etc. so more examples of how you use it properly. You pick up bits and bobs in the Sandcastles, but I’d love to see more of systemic things, like more advanced examples of callback properties (and any change detection underneath), property management, entityCollections, entities and sub-entities (flat vs. node structures), global style management, primitive vs. dynamic entity collections and hybrid models, and pretty much anything in the API listing that doesn’t have a Sandcastle or code example with it.

Also, there must be a reason you create stuff in the API, either for performance, or compatibility, or something, so some explanation (even if just in the API doco) about it, for example AssociativeArray() instead of Maps (and instead of polyfills), similarly binarySearch(), clone(), etc. and if it’s just trying to be an API that can do it all.

There’s also probably a clear delineation between stuff for the foreground and background, like proxy/defaultProxy you probably use, but there’s no documentation on use or impact, so no way for the foreground (our developed apps) to use it. There could be smarts and advantages lurking within!

So, the summary of this one is more and better documentation, with better explanations for why these objects and properties exist, especially in relation to other parts of the API, and how to use them. To extend the guides, something like “Architectural implications and considerations of using Cesium”, “How Cesium works under the hood (loops, hooks and object management)”, and the like.

I was going to say maybe also update JsDoc … weirdly, yours claim to be 3.6.10 when the latest version is 3.5.5, so maybe there’s some unlinked branch/clone you’re on … but I’d love to see a generated version where the left pane stays contextually (or scrolls to) the selected part of the API.



  • Aesthetic improvements for imagery tile LODs
    • Alpha blend / fade from one imagery tile to the next requested tile
    • This would greatly increase the visual aesthetics of cesiumJs
    • open issue: Alpha blending for imagery layers LODs · Issue #8140 · CesiumGS/cesium · GitHub
    • Another aesthetic improvement would be to have the underlying ellipsoid base layer pattern to be something other than deep blue, maybe a light grey with some gridlines would be more pleasing
  • Vector Data
    • as 3D tiles
    • support of vector imagery providers
  • Terrain layers at runtime
    • Currently we can only have one terrain provider at any one time. Would be great if we could have multiple terrain providers, similar to how multiple imagery providers are supported via imagery layers.
  • Per-feature selection for tiled BIM/CAD models, where properties from raw models (IFC for example) are persisted in 3DTilesets
  • Scene Ray methods
    • Make methods such as scene.getpickray public

Migrate to TypeScript. :grinning:


Yes, similar to TomPovey, support for merged terrain models. We currently do it by merging at the backend, but to have a front-end way to merge terrains (with rules; support for multiple terrains) would be a massive step up.

Cheers, Alex


I love @Alexander_Johannesen’s idea about documenting performance do-and-don’t tips.

Also, @nshen, consider me “team Typescript” 100% – I would be thrilled to help with that transition. It should be a lot easier now that everything is ESM already.


I loved your all ideas @Alexander_Johannesen and @TomPovey you have also given very valid points, Hope Cesium Team will consider to provide cesium js community all above things.

Cheers :slightly_smiling_face:

  • Typescript
  • More shader interpretation blog
  • The experimental OGC API

Wrote up an issue in the CesiumJS repository about adding support for declarative rendering in HTML.

That would allow consumers to set up Cesium using just HTML, something like the following example.

Please give a thumbs up to the issue or add your comments. Thanks!

<cesium-view shadows animate>
  <cesium-navigation-controls hide-help></cesium-navigation-controls>
  <cesium-tileset src= "../SampleData/Cesium3DTiles/Tilesets/Tileset/tileset.json"></cesium-tileset>. 
1 Like

Web Assembly all the way.
Nothing is more important than been side-by-side with the cutting edge tech, and giving the developers the tooling which is in phase with their development tools.

  1. I really want to see that cesium can improve the display effect of 3D models (such as BIM models). Compared with the rendering effect of threejs, the gap is still very obvious.
  2. It can support webgpu, etc., greatly improving performance. Now, when there are a large number of bim models, the performance is not good.
1 Like

Surprisingly, it seems like you have a big plan in mind
As a senior user of Cesium, I have very realistic ideas
You must pay attention:
1.Cesium has done a great job in the geoscience module, and can even be said to be the best. But the display effect must be further improved, and I even think it will affect the lifespan of Cesium. For example, the display effects of Three and Babylon are very good, and I sincerely hope that Cesium can improve the display effect
2.I think pursuing WebGPU now is too extreme. It seems that Cesium should design the API to be more scalable and flexible, so that developers can easily insert their own glsl, wgsl, and so on The team should carefully consider this, as just one team has limited energy, but if this extension works, more and more developers will contribute! I am willing too!
3.I have noticed that the Cesium team has put a lot of effort into Cesium for UE. To be honest, in recent versions of Cesium, we clearly feel that they are all fixing something and still feeling a bit disappointed. We are not quite sure whether the main focus of the Cesium team is to continue improving Cesium or to focus on UE? I believe this is a confusion for many people.
4.I noticed that in the latest version of Cesium, Cesium cameras have added some drift like effects, but if you are not familiar with the control, it can easily pop up, which once again proves that Cesium cameras need to be further optimized. Of course, in such a large coordinate system, there is indeed too much to consider, but I believe in the strength of the Cesium team!
5.Here comes the metaverse! Cesium must make corresponding responses in terms of digital humans and bones. I know that previous versions of Cesium also support some skeletal animation, but as we all know, the current level of support is not enough, such as a complex expression. Cesium now uses vertex attributes to handle it, but because WebGL has a limit on the number of vertex attributes that can be transferred in a single time, Cesium cannot do complex expressions for digital people, but babylon uses texture methods and now supports these functions.
6.The latest version of Cesium has added global Google tilt photography data. Is this data just for display or is it commercially available? Is there a clear response to this?
7.A relatively old problem is that Cesium’s expression of water surface is too weak. Now it’s just a surface, making some noise, but further down, nothing can be done. For example, adding reflections of actual objects and simulating real waves, it should be noted that in a real scene, water is often very important
8.Can we consider loading vector tiles similar to Mapbox? PBF and MVT can also be displayed on Cesium now, but the effect is too poor.
9.Cesium seems to lack support in the physical world, such as wind, frost, rain, snow, day and night, and multiple light sources
There’s still a lot more, I’ll continue after dinner…


We cannot expect Cesium to become an all-powerful warrior, but there are indeed many things to try in between

For example, Cesium has long supported the opening of the underground. For example, after opening the underground, it seems that there is no plan for how to present and cut the geological body. As well as the cutting of the terrain, it is impossible to achieve the cutting of concave polygon. I know why, because the mathematical and geometric algorithm used by Cesium’s cutting plan now can not identify the concave and convex parts, We can now expand the use of textures to achieve arbitrary polygon clipping.

However, these can all be avoided through other means. The biggest expectation of CESIUM now is to improve the display effect. Rough models and flat scenes are becoming increasingly difficult to meet the requirements of modern graphics. I recall the surprises that Cesium brought to developers in 2014, and I am very looking forward to the same surprises that Cesium will release in future new versions. I wish Cesium would become better and even become a standard in geographic 3D graphics

1 Like