BIM file uploads (eg IFC) support EPSG and WKID data being specified to set the location for a tileset. Ion REST API documentation – Cesium
I’d like to be able to do the same for GLTF data. Is this at all possible?
BIM file uploads (eg IFC) support EPSG and WKID data being specified to set the location for a tileset. Ion REST API documentation – Cesium
I’d like to be able to do the same for GLTF data. Is this at all possible?
If I understand your question correctly you would like to be able set options.inputCrs
with type: "GLTF"
when creating new assets via the API.
That options is not supported at this time with type:"GLTF"
. If you need to locate a GLTF asset you can use the Adjust tileset location button at the top of the righ hand panel in My Assets.
If that solution is not a good fit, can you give us some more context about your use case? Let us know what you are trying to do and why Adjust tileset location doesn’t work well for you.
Regards
Thanks - We have GIS scale data from CityEngine which we want to load into Cesium Ion.
Given the formats it supports, GLTF seemed the best option (but we could be wrong here) Export a model—ArcGIS CityEngine Resources | Documentation
(FYI - IFC whilst possible seemed to be taking ages to tile/hang)
Therefore given GIS scale of model, we need to factor in EPSG reprojection
It sounds like you are using GLTF as the input format to Cesium ion and would like to have 3D tiles as the output is that correct? Using GLTF as the Cesium ion output will not be good for large data sets as it will require the entire model to be loaded before anything is displayed.
Using type: "3D_TILES"
and options.sourceType
as 3D_MODEL
or 3D_CAPTURE
will enable you to pass options.postition
. While that won’t do a projection it will allow you to position the tileset in the correct position. Here is the excerpt from our API documenation:
The origin of the tileset in [longitude, latitude, height] format in EPSG:4326 coordinates and height in meters. This value is ignored if the source data already contains georeferencing information.
Yes, GLTF ideally as the format and 3D tiles as output. - From testing it seems like the tiler is working nicely with the GLTF - given there are several sub files - performance seems ok so far - however would be interested to understand the limitations with GLTF for this.
I was assuming that providing a 2D grid ref as input would mean reprojection on from Cartesian to WSG84 would be handled? Whereas just specifying the lat/long of model origin would not? I may be making incorrect assumptions here.
When you provide options.position
it will apply an affine transformation to move the data from the local GLTF coordinates to that location in WGS84. It will not do any reprojection of the data. This works well for smaller data sets (such as a scan of a building). If you have a data set the covers a large area (like a 500 km highway), this will result in some noticable differences from the reprojected positions at locations further away from the origin.
Currently we don’t support reprojecting non BIM GLTF data, but this is something that is on our radar.
As a work around, you could try breaking the single large data set up in to several smaller files with different origins to minimize the differences between the affine and reprojected positions
I think supporting that with other formats would be really helpful as an option. IFC whilst open, is not the most efficient format to work with. If there was support for GLTF reprojection that would be a very useful workflow.
From our tests, GLTF tiling is working a lot better than IFC on large scale models from sources such as CityEngine.