Hi,
I uploaded CityGML - no error shown - and would like to download it from ION.
Due to problems in showing the content, i checked the files with the 3d-tiles-validator.
I got hundreds of errors - from CONTENT_VALIDATION_ERROR, CONTENT_JSON_INVALID, BINARY_INVALID_ALIGNMENT, …
Does this mean, that Cesium ion could not produce a valid 3d-tiles file ?
Hi esg,
Can you let us know what asset id this was for so we can investigate the issue further?
Hi Mark,
it is AssetId 4522606 – i have download the tilesDownload LoD2-DE_HH_2025-03-14_ogc.zipuncompress it and checked it with 3dtiles-validator
Thanks for sharing that information. I was able to confirm that it did show errors for me as well. I have reached out to other members of our team who are more familar with the 3D tiles validator and CityGML tiling to see if they have any insights.
Are you having any issues viewing the data or is it just the validation messages you are concerned about?
Hallo Mark,
yes I had a lot problems to display the CityGML - i use on one side Cesium 1.92 and I see only 3-4 buildings of the whole town. so I wondered if it depends on the values of screenspace-error or if there are data inside the 3d-tiles. Using this dataset in a sandcastle everything looks fine !
The CesiumJS version in the second screenshot is 1.65, and this is more than 5 years old. One can see that there are several buildings, but they are all displayed at only two different places. It’s difficult to pinpoint the reason for that (maybe there is some error message in the developer console that should appear when you press F12), but I’d say that one can simply not expect such an old version to still be able to process more recently created data sets.
(Note that this is entirely different than the opposite direction: Data that was created 5 years ago should (and generally does) work in the most recent CesiumJS version. But new data may include some new features that are simply not supported by old CesiumJS versions)
But… all that is unrelated to the 3D Tiles Validator issues. When a newly created data set is not valid and generates validator errors, then that’s an issue and has to be investigated further.
Hi Marco,
sorry I disagree - also Cesium 1.65 was able to display Cesium 3DTiles of format 1.0 !!
That is a question of which format is delivered, not which viewer is used - in my opinion !!
There aren’t any errors on the console in the old viewer !
In the 1.91 i see single buildings but not more !
That is only sandcastle - no code from me !
There seem to be different CesiumJS version numbers involved:
Is there a specific (older) version of CesiumJS that you would like to use? (Or conversely: Is it not possible to just update to the latest version, 1.139, which seems to work properly?)
also Cesium 1.65 was able to display Cesium 3DTiles of format 1.0 !!
That is a question of which format is delivered, not which viewer is used - in my opinion !!
That’s correct. I don’t know (from the tip of my head) which tileset version the GML tiler is currently generating. But if it is generating 3D Tiles 1.0, then it should indeed work in older CesiumJS versions as well.
With one small caveat: Maybe there was some sort of bug in one of these older CesiumJS versions that was fixed in the meantime. That’s hard to say for sure. But when the same tileset is not displayed propery in 1.65 and 1.91, then this would mean that this bug was not fixed between these versions, and that’s unlikely.
In any case (regardless of the CesiumJS version and why exactly things are not working in certain versionss), there is something wrong with the data, given that the 3D Tiles Validator declares this tileset as ‘invalid’. (Which of these validation errors could be the reason for the rendering issues remains to be investigated).
I hope that someone from the Cesium ion / tilers team can have a closer look at this asset (with asset ID 4522606 as you mentioned), to see what could be wrong there.
If the downloaded tileset is ~“not too large”, and if it can be shared (maybe as a private message), then I might have a closer look at the tileset and the validator report. This could just be a first investigation. I could probably not fix the issue at the source, in the GML tiler. But maybe I can find out what exactly is wrong and why it is not displayed properly in older CesiumJS versions.
Hi Marco,
sorry, to clear the situation:
We have a bigger application at our customer based on Cesium 1.91. The customer has problems to deliver the necessary data. The customer would like to use Cesium Ion Self hosted and tested the data with Cesium ion. The customer loaded the dataset, i used.
In the examples:
I used the 1.65, because I could reproduce a difference, very fast. This morning I do a new installation with npm install of the 1.91 and use the sandcastle to reproduce the behaviour of my application. The behaviour is, that I only see single buildings - like in my application.
I use the following code:
Cesium.Ion.defaultAccessToken ="XXX";
var viewer = new Cesium.Viewer('cesiumContainer', {
terrain: Cesium.createWorldTerrain(),
// shadows : true
});
viewer.scene.globe.depthTestAgainstTerrain = true;
//Add Cesium Inspector
viewer.extend(Cesium.viewerCesiumInspectorMixin);
$('.cesium-viewer-cesiumInspectorContainer').css('visibility', 'visible');
var tileset = new Cesium.Cesium3DTileset({
url: Cesium.IonResource.fromAssetId(4522606),
});
tileset.readyPromise.then(function(tileset) {
viewer.scene.primitives.add(tileset);
viewer.zoomTo(tileset, new Cesium.HeadingPitchRange(0.0, -0.5, tileset.boundingSphere.radius * 2.0));
}).otherwise(function(error) {
console.log(error);
});
The data is in Hamburg
I could look at the building and send the CityGML of that region !
I have uploaded a smaller Dataset in Cesium ion 4538441, only one file
I could also send you the xml - private
Maybe there is a problem in ion - I chose the texture option and clamptoground to the Cesium World terrain.
Maybe someone from @cesium-tilers can have a closer look at …
and see whether anything stands out. If you send me the downloaded tileset of the smaller one (as a private message) then I can also have a look, but cannot promise anything - if there is a bug, then it will likely have to be fixed in the GML tiler.
Hi Marco,
i have put the original xml und the 3d-Tiles Files.
Ihave produced a even smaller one only 3 buildings !
LoD2_HH_test.zip (3.1 KB)
LoD2_32_574_5922_1_HH.zip (163.4 KB)
(Edit: Removed one file based on user request)
Any NEWS ?
Juggling priorities…
However, I had another look. The validation errors (just to keep track of that) are of two forms. Several errors are
{
"type": "BINARY_INVALID_ALIGNMENT",
"path": "1/1/1.b3dm",
"message": "The byte length must be aligned to 8 bytes",
"severity": "ERROR"
},
That’s clearly invalid. It’s not a “critical” error, insofar that many tools will not rely on the alignment. But any specification-compliant tool could rely on the alignment, and it could crash, so that should simply be fixed. It is already tracked internally, but I don’t know when this will be addressed.
There is one other error:
{
"type": "CONTENT_JSON_INVALID",
"path": "1/1/0.b3dm",
"message": "Batch table property \"gml:name\" array length must equal features length 161.",
"severity": "ERROR"
}
That’s also invalid. It might also cause crashes in other applications. I think that it is not tracked explicitly, and I haven’t investigated the details. I’ll just add it to the internal issue for now.
That said: We had some discussion about ‘versions’ above:
But new data may include some new features that are simply not supported by old CesiumJS versions
That is a question of which format is delivered, not which viewer is used - in my opinion !!
That’s correct. I don’t know (from the tip of my head) which tileset version the GML tiler is currently generating. But if it is generating 3D Tiles 1.0, then it should indeed work in older CesiumJS versions as well.
One thing that was not taken into account in this discussion is that of the tile content. Specifically: glTF (.glb files). And even more specifically: Which extensions this glTF contains, and which of them are supported in the client. And to come to the point: Whether the client supports the KHR_draco_mesh_compression extension. By default, GML is tiled into Draco-compressed data (and KTX textures, if applicable). Older versions of CesiumJS may not support this.
When upploading your data, you should disable KTX and Draco compression:
The result should be a data set like this one:
Forum 45502 - GML Errors - LoD2_32_574_5922_1_HH.zip (426.4 KB)
This can be loaded in CesiumJS 1.91 with a Sandcastle like this one:
const viewer = new Cesium.Viewer("cesiumContainer", {
globe: false
});
function loadTileset() {
const tileset = new Cesium.Cesium3DTileset(
{
url: "http://localhost:8003/tileset.json",
debugShowBoundingVolume: true,
}
);
viewer.scene.primitives.add(tileset);
const offset = new Cesium.HeadingPitchRange(
Cesium.Math.toRadians(-45.0),
Cesium.Math.toRadians(-45.0),
2800.0
);
viewer.zoomTo(tileset, offset);
}
loadTileset();
The result should then look like this:
Let me know if anything doesn’t work.
Hi Marco,
I saw your message today - I tested also and my result is, that the ClampToGround is the problem !
I tested my small dataset and set no draco, no texture and no coordinates !
–> Result everything is fine in Cesium 1.91
–> but you could only use the dataset with wgs84 ellipsoid
if I set clamptoground with Cesium WorldTerrain
–> I got wrong results
–> Could the EPSG:25832 be a problem for the clampToground
Hi Marco,
I have now made more tests - and definitely from my opinion it is the clamptoground parameter
I also produced a file with converted coordinates to EPSG:4326 and this doesn’t changed anything
wgs84 ellipsoid cesium world terrain
EPSG:4326 in CityGML fine under surface
EPSG:4326 clamp to world terrain fine under surface
So question:
What EPSG could be used that Cesium ion produces data (with the clamp to ground option) which could be viewed with Cesium 1.91
I used the Converting to/from CityGML files | CityJSON to convert the CityGML from one srs to another !
Rüdiger
WGS84 ellipsoid:
Cesium World Terrain, buildings lie under the surface allthough clamptoground is used !
I don’t have particular expertise in that area. Maybe @cesium-ion : Are there any known constraints or limitations when it comes to GML and clamping it to CWT?
