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.

Thanks!
Gabby and the CesiumJS team

7 Likes

@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.

2 Likes

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.

Cheers,

Alex

4 Likes
  • 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.
2 Likes

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.

4 Likes

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.

Cheers,

Alex

3 Likes
  • 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
3 Likes

Migrate to TypeScript. :grinning:

2 Likes

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

3 Likes

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.

2 Likes

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: