Model distorted from shape file to gltf

Hi,

I have been struggling several weeks to convert a model I have in ESRI shape file format to glTF and visualize it properly on Cesium!

(I actually have lots of models like that which are in LOD1 and LOD2)

My model is in SWEREF99 which is used in Sweden and heights are in RH2000 which is national height system in Sweden.

what I did is to convert coordinates to Geocentric and then convert it to COLLADA using FME software, and then to glTF using Cesium’s online converter tool.

After converting to COLLADA model seems OK, but when I convert to glTF and try to visualize it on Cesium model gets distorted and ends up somewhere near earth’s center!!

Where could it go wrong?

What is the best streamlined process to convert and visualize models from shape files?

I attached a folder containing my shape file, converted COLLADA model and glTF model as well.

Any help is much appreciated because it is part of my thesis work and I am desperate to get it done but I have been stuck in this for too long. :frowning:

Thanks in advance!

model.rar (4.47 KB)

Hello,

Are you setting the model orientation property? This is how you’ll position your model. Take a look at this example: http://cesiumjs.org/Cesium/Apps/Sandcastle/index.html?src=3D%20Models.html&label=Showcases
Otherwise, you might need to use the CESIUM_RTC extension in the glTF to position the model.

Best,

Hannah

Iman-
RE: What is the best streamlined process to convert and visualize models from shape files?
I am just another developer, adding my two-cents-worth of input regarding your question.

I took a look at your shapefile in ArcGIS, and see that it is a rectangular polygon, representing a building roof-top “footprint”.

I assume for your purposes of generating a 3D model, you have chosen Multi-patch geometry, and are attempting to extrude 3D buildings using the 2D “footprint” and building height attributes for the 3rd dimension.

In theory, your approach loading gltf models would permit applying photo-realistic materials to the building models’ surfaces, and converting rooftop data from GIS shapefiles into a virtual 3D world suitable for computer-gaming, and high-quality fly-through animations in Cesium.

First, I could not load your .gltf model.

I used ArcGIS Desktop 10.3, ArcToolbox, Conversion Tools, Collada, Multipatch to Collada, to convert your multipatch shapefile, which output 2 files: ID_0.dae and ID_0.kml

The KML contains the insertion point for your model, 18.070008205824664, 59.323336434606304

Using the online converter, https://cesiumjs.org/convertmodel.html, I created ID_0.gltf

Here’s a code snippet of what I had working; paste it into Sandcastle’s 3D Models example, with ID_0.gltf in the appropriate path, and it will load correctly.

Set the Terrain provider to STK Terrain, and you will see the correct elevation for the building.

console log should show height = 52.264872275241345.

Sandcastle.addToolbarButton(‘ROOF MODEL’, function(){

try{

var positionOnEllipsoid = Cesium.Cartesian3.fromDegrees(18.070008205824664, 59.323336434606304);

var modelMatrix = Cesium.Transforms.eastNorthUpToFixedFrame(positionOnEllipsoid);

  viewer.entities.suspendEvents();

  viewer.entities.removeAll();

  var url = 'http://127.0.0.1:4001//wordpress/wp-content/plugins/lftgly/datasources/gltf/model/ID_0.gltf';

  var height = 0;    //height above ellipsoid in meters;

  var positions = [Cesium.Cartographic.fromDegrees(18.070008205824664, 59.323336434606304, height)];

  var promiseTerrainHeight = Cesium.sampleTerrain(viewer.terrainProvider, 11, positions);

Cesium.when(promiseTerrainHeight, function(updatedPositions) {

   // positions[0].height and positions[1].height have been updated.

   // updatedPositions is just a reference to positions.                  

  height = positions[0].height;

  console.log("height = " + positions[0].height);

  var position = Cesium.Cartesian3.fromDegrees(18.070008205824664, 59.323336434606304, height);

  var heading = Cesium.Math.toRadians(0);

  var pitch = 0;

  var roll = 0;

  var orientation = Cesium.Transforms.headingPitchRollQuaternion(position, heading, pitch, roll);

  var modelTerrain =

      viewer.entities.add({

                    name : url,

                    position : position,

                    orientation : orientation,

                    model : {

                        uri : url,

                        minimumPixelSize : 128

                    }

                });

viewer.trackedEntity = modelTerrain;

viewer.entities.resumeEvents();

 Cesium.when(modelTerrain.readyPromise).then(function(){

    //modelTerrain.addEventListener;

});

});

} catch(error){

 var strMessage = '...an error occurred adding Cesium Model (terrain): ' + error.message;

 console.log(strMessage);

}

});

``

Good luck, Iman!

Here’s the .dae & .kml exported by ArcGIS from your shapefile, and the .gltf that the code snippet loaded successfully

ID_0.dae (14.3 KB)

ID_0.gltf (15 KB)

ID_0.kml (750 Bytes)

Hi Jonathan,

Many thanks for your time and answer,

The thing is, I have a shapefile that contains several buildings in LOD2. I just extracted a very simple building to upload here for illustration purposes!

having said that, It is not possible to simply extrude these buildings and somehow I need to convert them to gltf models.

According to a prior conversation I had to Sean Lilley, if the model is already georeferenced it should be possible to upload it without having to specify position and orientation, but I could not figure out how to do so!

An interesting point you mentioned above is “The KML contains the insertion point for your model, 18.070008205824664, 59.323336434606304”; how did you get that? I tried to use georefrenced models directly just because I did not know this insertion point! I should mention that I do not have ArcGIS but I have FME desktop.

I attached the shape file in case you have time to take a quick look at it. (it is NOT a proprietary file, so don’t worry about that.)

P.S: I have already extruded the whole city LOD1 buildings successfully, that is not a problem! :slight_smile:

Södermalm_Utskr-3D-Kuber_shp.rar (75.6 KB)

Iman,Hannah-
I have the same question, Iman, and I do not understand Hannah’s response, either.
“how did you get that?” - ESRI’s ArcGIS software calculated that coordinate; when exporting the multipatch .shp to COLLADA .dae, ESRI includes a .kml

I have no idea (yet) what that coordinate is, or how you and I might calculate it independently, WITHOUT using 3rd-party ESRI software, or FME.

I suspect that coordinate is the center of the model’s bounding sphere (volume) in WGS84 coordinates.

18.070008205824664, 59.323336434606304

ESRI shows the extent of the shapefile, in WGS84 coordinates, as 59.323542 to 59.323131, and 18.069575 to 18.070442 degrees.

Hannah, re: your suggestion that we might need to implement “the CESIUM_RTC extension, which introduces the CESIUM_RTC_MODELVIEW parameter semantic that says the node is in WGS84 coordinates translated relative to a local origin…”, from my layman’s understanding, this interface also requires the same insertion point coordinates, which Iman and I can’t determine, specified as the “local origin” of the model. Am I right, or is the local origin required by CESIUM_RTC as simple as 0,0?

PS. Hannah, would you or someone at AGI please update the Sandbox example you reference, which is throwing a warning about breaking-changes to headingPitchRollQuaternion(position, heading, pitch, roll) recently introduced (now 3 heading, pitch, roll parameters must be wrapped in a single HeadingPitchRoll object?), that will fail in 1.30?.

Iman-
I could only find one reference in ESRI ArcGIS help regarding that exported KML containing an origin point coordinate for the model

  • If the exported multipatch is in a projected coordinate system, such as a building stored in a UTM zone, then a KML file containing the coordinates as WGS84 will also be created in the output folder

Using ArcGIS, I re-projected your shapefile from SWEREF99_18_00, to GCS_WGS_1984, then used ArcGIS “Multipatch to COLLADA” tool, and it exported only a .dae model, no .kml file. I suspect that viewer.entities.add position property could be 0,0 for this COLLADA model, except that http://cesiumjs.org/convertmodel.html fails to convert this .dae to .gltf with an internal server error (500). That’s as far as I got testing that approach.

The Södermalm_Utskr-3D-Kuber_shp.rar you attached contained Byggnad_area_WGS84.shp, a shapefile of polygon geometry, not multipatch geometry, so I could not use it for testing.

Thanks-

-Jon aka left gully

Merry Christmas, Hannah,
I see that the 3D Models Sandbox example has been updated with the new line of code for the required HeadingPitchRoll object, my apologies,

Thanks-

-Jon

Hey there Iman,Jon and Hanna,
I'm also trying to render a .gltf for an archeological site and I'm having some problems, the buildings are not fit into the terrain, the model i use is converted from COLLADA using collada2gltf.exe, the model was created from shapfiles using Cinema4D and the height values were extracted from a DEM( i think IKONOS ).
i tried to extract building's heights using sampleTerrain , I've also downloaded USGS SRTM 1,CGIAR SRTM and GTOPO30 data and the heights that i extracted (using QGIS) are not the same as the one in the AGI terrain (the deference is between 15 to nearly 30 meters!!!)
THANKS
Musab

Iman,
Happy new year… following up on this, I used ArcGIS Desktop 10.3 to

  1. reproject a copy of the single building multi-patch to WGS84.
  2. ran ArcToolbox “multipatch to footprint”, to get a 2D copy of the 3D feature extent,
  3. ran ArcToolbox “add Geometry Attributes”, to find it’s 2D centroid in WGS84 coordinates
  4. The result: 18.070007058, 59.32333627
    That’s close, but not the 18.070008205824664, 59.323336434606304 numbers that ArcGIS calculated when exporting the multipatch to dae.

I had no way to calculate the centroid of the 3D model, for which the X-Y would very likely be different, in 3 dimensions, than the 2D footprint.

In summary, my conclusion is that the insertion point of a georeferenced model created in a projected coordinate system requires the X and Y components of the model’s bounding sphere centroid, re-projected from that projected coord sys to WGS coordinates. And the only reason we don’t use the Z, is that it may not agree with STK Terrain, so we substitute a Z value sampled from terrain at that X-Y insertion point.

I want to talk to Sean Lilley…

Thanks-

Jon

https://groups.google.com/forum/#!topic/cesium-dev/QRHascY9Pio
Okay, this is what happens when you open 2 threads for the same question. Now I’m going to try Sean Lilley suggested for georeferenced models in the other thread.
https://groups.google.com/forum/#!topic/cesium-dev/QRHascY9Pio