geelong_mini_demo_bin_linux_v1.0-draft_x64.gltf was created using data made available from the City of Greater Geelong (gis@geelongcity.vic.gov.au) under a Creative Commons license. The data used to create this demo was originally obtained via email in .skp format (> 100MB so not suitable for inclusion in this repo), however there is also a lower quality dataset of the same region available on data.gov.au in .kml/.dae format (this dataset does not seem to contain building textures).

This demo is a trivial example to show Caesium's 3D capability with a simple available Australian dataset. The structure of the data and the nature of the demo does not really lend its self to more substantial extension for larger datasets (it is not expected that this method will scale and it doesn't leverage the 3D tiles capability which is designed for this scaleability - it is purely to demo some 3D capability to explore future potential).

The blocks used were extracted from the larger model using a traditional modelling tool into Collada (.dae) format. The gltf model was created from the Collada (.dae) model using the latest binary collada2gltf tool from Khronos (the standardising body of both the Collada and gltf formats):
https://github.com/KhronosGroup/glTF/releases
collada2gltf_linux_v1.0-draft_x64.tar.gz

The command line used to convert the model from .dae to .gltf was:
$ ./collada2gltf -i -e -f geelong_mini_demo_bin_linux_v1.0-draft_x64.dae 


The height of the buildings in the original model did not seem to correlate with the heights used for either the terrain or smooth surfaces, so the heights were set manually (by eye) in the CZML files so that the height looks approximately correct. The height is not perfect for either of these configurations since:
Terrain) The original data has a custom terrain surface defined (this was removed from the model deliberately when it was converted). The terrain surface from the tileset does not match with the terrain surface that was present in the original geelong model. This means that in some places the building models penetrate the terrain surface we are using and in some places the building models float above the surface. The Caesium viewer does not clip the model where the buildings intersect with the terrain model and so this makes the geometry look even funnier where the model extends below the surface of the terrain drawn. The height set seems to be a height that on average makes the model seem most sane (in some places it looks correct, in some places it seems to be floating, in some places it renders bizarrely because it is below the surface).
Smooth) Since the model has terrain data, the base height of the building is not uniform over the whole model and as a result the buildings start higher the further the model ground height becomes from the estimated smooth ground height. For this model the height is set at almost the models minimum height and is approximately zero on the corner of Police Lane and Little Malop Street. From here the remainder of the model appears to float as the elevation rises. This was done as it is more sane to look at the model floating then when any of the model is below the grounds surface (as it is clear to most viewers what is going on when the model is floating, however when the building height is below the grounds surface it is less intuitive because the model is not clipped to the ground and so the projection seems somewhat more strange).
It is not obvious how we could trivially make the dataset more seamlessly integrate with the globe surfaces. However two more complex options could be to extract the terrain from the 3D model and use this in the terrain tileset, or alternatively use the terrain currently used and intersect this with the models (gap filling where needed where the terrain height from the tileset is lower then the terrain height from the model). Alternatively for the smooth model the average of the terrain for the building in the model could be subtracted from the height of the building so that they fit more correctly to the surface.

The location of the origin of the dataset given was: Long 144.3568, Lat -38.1468. The accuracy was improved manually, by tweaking the model location with respect to the map imagery.

There are clearly a few polygons missing from the clock-tower on the corner of Ryrie and Gheringhap streets. It seems that this defect is present in the original model (visible in the modelling tool), and it looks like the polygons here have the wrong orientation (they are facing the wrong way). It is unknown why these polygons have the incorrect orientation and whether this a fault in modelling tool, or the original model, but it is important to note that it seems that this fault is not further down the chain. If you process without the -i option (which reverses the faces) you can examine all of the polygons with this problem.

This workflow does not work correctly with more complex/larger areas of data. While exploring I also tired a larger region however the model produced was not able to be loaded through Caesium. I did not investigate further to examine whether the fault here was caused by the size of the model being used, specific model attributes which were not present in this smaller data set (a subset of the data in the larger dataset) and whether the fault came from the conversion tools or the rendering pipeline.