Iman’s problem is killing me, I’m very frustrated.
The forum seems filled with other developers posting issues loading 3D models.
The cesium team; Sean, Patrick, Matt; seem to be coming from a totally different geospatial background than a GIS analyst/developers like myself, who are attempting to use Cesium as a 3D GIS dataviewer.
The first paradigm-shift for GIS developers is that Cesium’s default map has no compass and north arrow, it has a clock control; (something I am beginning to really appreciate, btw). I intend to get that *compass and north arrow *cesium-navigation mix-in working, but you guys should have a DEMO of that cesium-navigation working in SANDBOX, for pete’s sake… as a part-time developer, integrating cesium-navigation into my code is a PIA, and my first quick attempt failed. But I digress…
IF the model is “georeferenced” in a “projected coordinate system” (PCS), not a “geographic coordinate system” (GCS), in ESRI ArcGIS terminology, that means the position and orientation are already known, before ArcGIS exports to .dae/COLLADA,
THEREFORE all of us GIS-background folks expect that the known ArcGIS position and orientation properties should carry-over as a native property to the datasource, when the model is 1st exported from ArcGIS Desktop to COLLADA, and 2nd, converted to GLTF or GLB, and 3rd, added to Cesium’s entities. If there were enough hours in the day, i would have QA tested this to death, and figured this out months ago, and so would dozens of other wannabe cesium js developers from the ArcGIS world.
There is some disconnect on our (GIS developers) communication with the Cesium team, and misunderstanding of Cesium’s documentation, regarding the position and orientation of 3D GLTF models.
Matt & Patrick say it should work.
Sean writes “The position and orientation need to be provided.”
What Iman and I have been saying for months is: WE DON’T KNOW WHAT the position and orientation properties are…
The position and orientation are embedded in the GIS data format, when the model was “georeferenced”; once the model renders in the ArcGIS software in the correct X-Y position and rotation, and Z value for height/elevation, it’s not exposed to the ArcGIS user.
The 2D-footprint of the 3D model has an X-Y bounding rectangle that can be queried indirectly by the ArcGIS user, but the center of the bounding sphere, in WGS84 coords… Sean, if I knew, I would provide it.
position and orientation has been lost in translation of our models…
It is only revealed to an ArcGIS user, if the export to COLLADA included a KML file, within which ESRI calculated a Position coordinate using undisclosed, internal methods, and if you are smart enough to open that KML with a text editor to copy the X and Y.
Iman and I have shared the experience that loading GLTF models in Cesium DOES NOT WORK, unless we can determine the centroid coordinates, in WGS84 crs, of the model’s bounding sphere.
Part of the issue is that Cesium needs a GLTF in WGS84 coordinates, and that transformation, from
Yet the Cesium team agrees that it should work.
I don’t think it’s a Cesium or WebGL bug, it’s a communication & documentation failure.
“I am a smart person”, lol, but I’ve thrown hours, days, maybe a week into this over the past 3 years. If I could get georeferenced GIS data from UTM or State Plane projected coordinate systems, converted into MultiPatch and exported to DAE, then converted to GLTF/GLB, then loaded in Cesium easily and semi-automated, I would be off-to-the-races making online maps to visualize that data in 3D, and showcase Cesium, instead of debugging code; and dozens of other GIS developers would use it, too.
Part of the disconnect in my understanding is how the georeferencing information (position&orientation) are properties of one MultiPatch in ArcGIS, but upon exporting that entity to a COLLADA model, ArcGIS may determine the original position&orientation transformed to WGS84 coordinates for inclusion in a KML for conveniently viewing the DAE in GoogleEarth, but the position&orientation are NOT in the COLLADA XML. Omitting the position&orientation from the DAE file allows instantiating multiple copies of that model at multiple new position&orientations, if you know the models original position&orientation, required to calculate the transforms to any new position&orientations, or to insert just 1 copy in that original position&orientation.
I’m leaning towards this being an issue in the ArcGIS export-to-COLLADA, not Cesium’s API, nor the http://cesiumjs.org/convertmodel.html, and wonder if I should look into how GDAL handles multipatch-ESRI-shapefile (or FGDB featureclass?) export-to-COLLADA.
Maybe my thoughts above will jog someone else’s memory, and enlightenment will follow…