We’re excited to share that we’ve started to bring iTwin Platform APIs to Cesium, aiming to provide a complete platform for digital twin experiences for the built and natural environment, shaped by the community’s real-world insights and continuing feedback. iTwin APIs power digital twin solutions used in architecture, engineering, and construction (AEC) apps—and across industries—to design, build, and operate infrastructure around the world. By exposing these APIs through Cesium, we want to enable Cesium and iTwin developers to build powerful applications with full geospatial context and advanced infrastructure digital twin workflows.
Start by checking out our introductory blog post to learn what iTwin can bring to your Cesium projects. Then dive into our initial set of tutorials that helps you build a CesiumJS app with reality data from Cesium ion and design models from iTwin.
We’re just getting started in introducing what’s possible with iTwin and Cesium. In future tutorials, you can expect to see examples of querying metadata from your iTwin, interacting with elements through spatial searches or SQL-like queries, and navigating directly to specific components in your model. We’ll also explore how to combine multiple iTwins within a single scene and how to incorporate advanced iTwin APIs like clash detection, change tracking, and issue management, bringing even more engineering intelligence into your geospatial applications.
We want the roadmap for iTwin APIs enabled in Cesium to be shaped by your real-world insights and feedback. We’d love to hear about your experience using iTwin APIs and what APIs or capabilities you would like to see coming to Cesium first. Share your thoughts below!
Hi, I have successfully done the tutorial which was simple to do which is great. One thing I am interested in is accessing the attribute/metadata of the model. When I click an element I get
Hi I added the following comment on LinkedIn to the following post
I believe it need a clear warning this is not production ready.
WARNING Experimental Security Issue:warning:
On things the blog and tutorial does not mention which I believe is very important that this is all experimental. I like to delve into understanding how this all works to see what state it is in if ready for production. hashtag#Bentley is excellent in flagging features as experimental (Technology Preview) What I understand is happening is mesh-export is called (Technology Preview) https://developer.bentley.com/apis/mesh-export/
is called to generate 3D tiles which are stored in CDN Cloud Service - Amazon CloudFront.
This is where the magic is in that its all integrated.
The issue is if you follow the tutorial you create an unsecure form of the data which is not authenticated when accessing so anyone with the URL can access the data. It is also not clear which country that data is stored at.
This important to understand and be aware of as one has a tendency to maybe use it on their own data and if that data is confidential you could inadvertently create a data security risk.
I believe hashtag#Cesium should make this clear in their Blogs and Tutorials.
Hi @lxrp_marco, at this stage the 3D Tiles embed some crucial information about the iModel and it’s elements such as the Element ID. This may not necessarily be so useful on it’s own, however it is the foundation for future workflows we’re working on. These will enable simple lookups (eg. get metadata for this element) and complex SQL-like queries (select all elements that meet conditions XYZ). We’d love to hear about any specific use cases you have in mind so that we can make sure to consider them as we work towards this capability.
Thanks for this feedback. These guides are certainly aimed at getting started and driving feedback from the community so that they can steer our direction, so we’ll try to make that clearer. Yours and others feedback is exactly what we need, so thank you for reaching out!
The issue is if you follow the tutorial you create an unsecure form of the data which is not authenticated when accessing so anyone with the URL can access the data.
To clarify the way this works, you generate an iTwin Share Key, which has a user customisable expiry (90 days is the default, but you could define shorter). This is used by your CesiumJS application to interact (read-only) with iTwin API’s such as Mesh Export. In a production app, you would determine how you’d want to generate this key. It could be embedded by the app by you (if a public facing app that doesn’t require auth), or you could generate it on the fly once your user logs in with your own authentication system. Tokens can also be revoked for more control. This is similar to how Cesium ion tokens operate.
When the Mesh Export API is called, a temporary URL is generated to the iModel’s 3D Tiles. This URL also has an expiry of approximately 4 days. I don’t believe the expiry can be controlled yet (would love your thoughts on this) but you can also revoke these URL’s if you wanted to implement tighter controls.
It is also not clear which country that data is stored at.
This data is all still in the domain of the iTwin Platform - let me circle back with the specifics, especially with regards to cloudfront.
I believe hashtag#Cesium should make this clear in their Blogs and Tutorials.
Noted - we’ll make some updates. Thanks again for the feedback!
Thanks for providing the great tutorials on CesiumJS x iTwin. Overall, it’s been great and very straightforward. However, I did come across a few hurdles during the walkthrough, which I’ve listed below:
Zoom issue: When launching the app locally, the viewer does not zoom into the asset. When launching the app, it just displays the world globe.
Step clarity: In the second stage, the phrasing can be confusing: references to “step 2” are ambiguous as each main step also has sub-steps. Perhaps renaming the main steps as “chapters” or something else could improve clarity.
Syntax update 1: In the second stage, the tutorial suggests:
**itp imodel create --name “Rail Bridge Design” --save**
However, after some further digging, the correct command is: itp imodel create --itwin-id “your-itwin-id” --name “Rail Bridge Design” --save
4.Synthax update 2: In the 3rd stage, the tutorial suggests: itp context set --itwin-id "your-itwin-id –imodel-id “your-imodel-id”
I found that the correct prompt is: itp context set --itwin-id “your-itwin-id” --imodel-id “your-imodel-id”
Apart from that, both the app (hosted locally) and the sandbox worked without any flaws. I hope this feedback helps improve the tutorial experience for others.
Interesting - are there any errors in the console suggesting a tileset didn’t load? If it doesn’t zoom, it’s usually because the tileset isn’t loaded. An incorrect Cesium ion Asset ID or Cesium ion token could cause this.
The –-itwin-id is only needed if the ID didn’t save in the previous step (when the iTwin was created). Did you perhaps use the itp itwin create command without –-save flag? When the –-save flag is used, the iTwin ID is stored and automatically used by future commands so that you don’t need to continually paste in the iTwin ID into every command.
WARNING Experimental Security Issue:warning: