Recently, the CesiumJS team has been making improvements in a variety of areas to support the 3D geospatial and visualization ecosystem. Changes in the past year have included visual quality and lighting improvements, support for additional glTF extensions, increased voxel capabilities, better clipping for 3DTilesets, and improving documentation like our guide for using CesiumJS with Webpack and Vite.
Now, we would love your input for what to see in CesiumJS in 2025 and beyond!
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.
Context around use cases helps us prioritize
Specific feedback or specific improvements is helpful; e.x. “More learning materials about how to control model animations” or “Add more example code in the API reference docs” are both much more helpful than “More documentation”
We would also appreciate hearing from the community specific suggestions regarding documentation and learning content updates, tooling or packaging updates, and targeted performance benchmarking and optimization that would be most helpful to you.
To incorporate your feedback into the roadmap, we’d love your input by the middle of February. However, we always value your input, so please feel free to add anything afterwards if it comes to mind.
Thank you for considering community feedback. Our team has been actively working with CesiumJS since 2022, and we would like to bring several important issues to your attention:
3DTiles 1.1 Rendering Quality Issue We are experiencing significant visual quality issues since the implementation of the Reality Tiler. The textures show much more pronounced flickering and grain effects compared to version 1.0. Despite our attempts to adjust SSE parameters, the problem persists. This issue is detailed in this discussion.
3DTilesets Clipping Performance While clipping improvements have been mentioned, the current implementation severely impacts performance (see GitHub issue). This feature is crucial for us, and the lack of a performant solution forces us to perform clipping manually during preprocessing. It’s surprising that this functionality isn’t prioritized, especially when other WebGL engines like Esri handle it efficiently. An optimized implementation would save the community hundreds of hours in BIM and 3D model integration.
Tileset Z-index Management The current depth management is limited to depth testing against terrain, which proves insufficient for fine-grained control of individual tilesets. For instance, our semantic buildings appear above the terrain even when they should be hidden by relief features.
Dynamic Color Adjustment The ability to modify imagery layer colorimetry at runtime would be invaluable for ensuring color consistency between imagery layers and 3D tilesets.
These improvements seem essential for optimizing CesiumJS usage in a professional context.
Looking forward to your thoughts on these matters and potential solutions.
That issue has become a bit of a catch-all beyond a 3D Tiles extension– including things like geometry performance broadly, and support for Mapbox Vector Tiles.
Would you mind adding some specifics to your use case? I’m guessing performance of large-scale time-dynamic vector data?
Thanks @janerivi! While parsing these JSONs could be accomplished now through CesiumJS’s math utilities, assuming this is a widely adopted standard, a loader function for this type of data would seem appropriate.
Hello!!!
I am mighty interested in your adding Unity6 WebGPU to your platform list!!! I am most interested and I invite you to contact me if you would like to discuss my assistance in any way… I am willing to help in any way that I can!
Thanks
i would very much welcome it if the shadow theme was improved. there is a lot of talk but as far as i understand there is no solution. maybe with a second camera behind it?
Give Property a type parameter so it becomes Property<T>. Then, where we have types like Property | string, replace them with Property<T> | string. I think this is doable with jsdoc using @template.
SHP, KML, GeoJSON etc.. - performance improvements & support for additional formats
Support of vector imagery providers
Merging 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