Hi Cesium team,
We have been using the Cesium JS library as the 3D model viewer at app.t2d2.ai. While it works fine for most of the 3D models, I ran into this issue when loading a particularly complex GLB file of a large stadium. Any light you can throw on this and how to solve would be appreciated. Please let me know if you need further context on how we have setup the Cesium viewer on our app. Thanks
Badri
{
"name": "RuntimeError",
"message": "Failed to load model: <clipped...>.glb\nFailed to load glTF\nMaximum call stack size exceeded",
"stack":
Original stack:
RangeError: Maximum call stack size exceeded
at hFe (http://localhost:4200/scripts.js:1:1485400)
at _2e (http://localhost:4200/scripts.js:1:1465979)
Handler stack:
Error
at new WS (http://localhost:4200/scripts.js:1:487641)
at yg.getError (http://localhost:4200/scripts.js:1:1283011)
at Mk (http://localhost:4200/scripts.js:1:1466197)
at yd.process (http://localhost:4200/scripts.js:1:1470535)
at nVe (http://localhost:4200/scripts.js:1:1728233)
at xo.update (http://localhost:4200/scripts.js:1:1730158)
at $s.update (http://localhost:4200/scripts.js:1:2224045)
at y0e (http://localhost:4200/scripts.js:1:3403442)
at Jy (http://localhost:4200/scripts.js:1:3402244)
at zi.updateAndExecuteCommands (http://localhost:4200/scripts.js:1:3400095)
Handler stack:
Error
at new WS (http://localhost:4200/scripts.js:1:487641)
at Ha.getError (http://localhost:4200/scripts.js:1:1386506)
at xo.update (http://localhost:4200/scripts.js:1:1730254)
at $s.update (http://localhost:4200/scripts.js:1:2224045)
at y0e (http://localhost:4200/scripts.js:1:3403442)
at Jy (http://localhost:4200/scripts.js:1:3402244)
at zi.updateAndExecuteCommands (http://localhost:4200/scripts.js:1:3400095)
at Kdt (http://localhost:4200/scripts.js:1:3411136)
at dT (http://localhost:4200/scripts.js:1:3411334)
at zi.render (http://localhost:4200/scripts.js:1:3413061)"
To provide additional context…
This is how we initialize and add the 3D model:
const viewer = new Cesium.Viewer('cesiumContainer', {
imageryProviderViewModels: imageryViewModels,
selectedImageryProviderViewModel: imageryViewModels[2],
animation: false,
timeline: false,
infoBox: false,
homeButton: true,
fullscreenButton: false,
selectionIndicator: false,
creditDisplay: true,
geocoder: false
});
// Remove the Terrain section of the baseLayerPicker
viewer.baseLayerPicker.viewModel.terrainProviderViewModels.removeAll();
// Add 3D model
const entity = viewer.entities.add({
name: this.projectDetail?.profile?.name,
position: Cesium.Cartesian3.fromDegrees(
this.projectDetail?.location?.longitude,
this.projectDetail?.location?.latitude,
0
),
model: {
uri: this.currentAssetDetails?.url
}
});
Without the option to reproduce the error locally, it’s difficult to pinpoint the exact reason for the error. Two things that might help as first analysis steps:
- Could you run this with an unminified version of the application? Right now, the stack trace contains these
at _2e ... parts where it’s impossible to figure out which function this actually is.
- Can you drag-and-drop the model into glTF Validator to ensure that it is a valid glTF model? (For example, if it was invalid due to cycles in the node hierarchy, then this could explain the error…)
Hi @Marco13 ,
Thank you so much for your reply.
- I understand and will try to run this locally with an unminified version and report back shortly.
- Thanks for sharing the glTF validator. I tried it and it reported no errors. Sharing the head of the validation message below.
{
"uri": "Mercedes-Benz-Stadium-Main-3d-model.glb",
"mimeType": "model/gltf-binary",
"validatorVersion": "2.0.0-dev.3.8",
"validatedAt": "2024-06-26T14:33:15.751Z",
"issues": {
"numErrors": 0,
"numWarnings": 0,
"numInfos": 75,
"numHints": 0,
"messages": [
{
"code": "UNUSED_OBJECT",
"message": "This object may be unused.",
"severity": 2,
"pointer": "/meshes/730/primitives/0/attributes/TEXCOORD_0"
.....
I got the same error when loading the model locally with a barebones setup
{
"name": "RuntimeError",
"message": "Failed to load model: GLB/Mercedes-Benz-Stadium-Main-3d-model.glb
Failed to load glTF
Maximum call stack size exceeded",
"stack":
"Original stack" :
RangeError: Maximum call stack size exceeded
at D9e (https://cesium.com/downloads/cesiumjs/releases/1.114/Build/Cesium/Cesium.js:6127:100839)
at YFe (https://cesium.com/downloads/cesiumjs/releases/1.114/Build/Cesium/Cesium.js:6127:81535)
Handler stack:
Error
at new gL (https://cesium.com/downloads/cesiumjs/releases/1.114/Build/Cesium/Cesium.js:76:4642)
at Pb.getError (https://cesium.com/downloads/cesiumjs/releases/1.114/Build/Cesium/Cesium.js:6120:22)
at ZN (https://cesium.com/downloads/cesiumjs/releases/1.114/Build/Cesium/Cesium.js:6127:81858)
at Pm.process (https://cesium.com/downloads/cesiumjs/releases/1.114/Build/Cesium/Cesium.js:6127:83649)
at DUe (https://cesium.com/downloads/cesiumjs/releases/1.114/Build/Cesium/Cesium.js:7637:38598)
at So.update (https://cesium.com/downloads/cesiumjs/releases/1.114/Build/Cesium/Cesium.js:7637:37230)
at aa.update (https://cesium.com/downloads/cesiumjs/releases/1.114/Build/Cesium/Cesium.js:8787:110537)
at pxe (https://cesium.com/downloads/cesiumjs/releases/1.114/Build/Cesium/Cesium.js:12927:32080)
at dg (https://cesium.com/downloads/cesiumjs/releases/1.114/Build/Cesium/Cesium.js:12927:28854)
at Pi.updateAndExecuteCommands (https://cesium.com/downloads/cesiumjs/releases/1.114/Build/Cesium/Cesium.js:12927:26122)
Handler stack:
Error
at new gL (https://cesium.com/downloads/cesiumjs/releases/1.114/Build/Cesium/Cesium.js:76:4642)
at nc.getError (https://cesium.com/downloads/cesiumjs/releases/1.114/Build/Cesium/Cesium.js:6124:22)
at So.update (https://cesium.com/downloads/cesiumjs/releases/1.114/Build/Cesium/Cesium.js:7637:37344)
at aa.update (https://cesium.com/downloads/cesiumjs/releases/1.114/Build/Cesium/Cesium.js:8787:110537)
at pxe (https://cesium.com/downloads/cesiumjs/releases/1.114/Build/Cesium/Cesium.js:12927:32080)
at dg (https://cesium.com/downloads/cesiumjs/releases/1.114/Build/Cesium/Cesium.js:12927:28854)
at Pi.updateAndExecuteCommands (https://cesium.com/downloads/cesiumjs/releases/1.114/Build/Cesium/Cesium.js:12927:26122)
at eft (https://cesium.com/downloads/cesiumjs/releases/1.114/Build/Cesium/Cesium.js:12927:39162)
at GT (https://cesium.com/downloads/cesiumjs/releases/1.114/Build/Cesium/Cesium.js:12927:39360)
at Pi.render (https://cesium.com/downloads/cesiumjs/releases/1.114/Build/Cesium/Cesium.js:12927:40388)"
The error might still be caused by the glTF itself - for example, when the glTF contains a reeeally deep node hierarchy or so. But I’ve never encountered this sort of error in CesiumJS until now, so it’s still not clear whether it’s indeed an issue with CesiumJS. (Do you know anything about the structure of that glTF asset? I assume that it is some sort of CAD/BIM model…?)
Yes this is a BIM model and could be a really deep node hierarchy. I think it’s this one: Mercedes Benz Stadium 3D - Buy Royalty Free 3D model by Shin Xiba 3D (@Xiba3D) [e75fcc0] - Sketchfab Store converted to GLB. It actually opens on my local 3D viewer (takes a really long time though).
Ok, some more experimentation with my local barebones setup yielded this:
- It loads properly in Cesium releases 1.96 and below (I tested back to 1.5x)
- The
Call Stack Exceeded error starts from release 1.97 onwards.
Does this help Cesium Team to get closer to this issue? I can share the GLB file privately if needed for your testing. @Marco13
Narrowing it down to a specific version certainly helps a lot: There has been a considerable refactoring in Cesium 1.97, regarding the architecture of (glTF) “Model” classes.
It’s still not clear what exactly causes the error, though.
I had a short look at the SketchFab model (preview) that you linked to. That’s a lot of seats in that stadium. Depending on how exactly this was converted to glTF, this might literally result in a node with 71000 (!) children to be created. (This should still not cause a crash, but … might bear some challenges for some rendering engines).
If the model is not unreasonably large, then you could consider sending it to support@cesium.com , with a link to this thread. It’s hard to say how much effort it will be to figure out (or even fix) the root cause of this, but having a test case to reproduce it could definitely help to investigate this further.
1 Like
Yes, this is indeed a complex model. I originally used obj2gltf with default options to convert the assets to GLB. After encountering this error, I also opened the original 3DM file in Rhino and exported to GLB and GLTF with various options but all of them result in the same issue.
As per your suggestion, I will reach out to support@cesium.com with a url link to the GLB for your further testing. Thanks again for all your time and efforts looking into this. Appreciate it!
Badri
After investigation of the GLB, it turned out that this was indeed caused by many fine-grained elements in that model (probably the seats or other repetitive parts of the building) that triggered an error in CesiumJS.
The error is tracked in CesiumJS should not use `push.apply` for potentially large arrays · Issue #12053 · CesiumGS/cesium · GitHub
A preliminary solution for that particular model was to use glTF-Transform (Command-line quickstart | glTF Transform) and apply the optimize command to the model.
Thank you Cesium Team! I can confirm that post-optimization with the gltf-Transform tool, the model is much lighter and loads much faster and more importantly - without glitches on the Cesium viewer.
Best,
Badri
Hey, @Marco13 I have the same “Maximum Call Stack Size Exceeded” issue in my project, but with .kmz file. This issue happens only for certain large projects. You can download one of them from this link WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free
Best,
Roman
@romario_panas From a quick test with a Sandcastle like this
const viewer = new Cesium.Viewer("cesiumContainer");
const options = {
camera: viewer.scene.camera,
canvas: viewer.scene.canvas,
screenOverlayContainer: viewer.container,
};
viewer.dataSources.add(
Cesium.KmlDataSource.load(
"../../SampleData/kml/batchawana_surveys.kmz",
options
)
);
(loading that file locally), I could not reproduce the error. Maybe there are other aspects of the project that cause this error?
@Marco13 how can I upload my batchawana_surveys.kmz to sandcastle?
@romario_panas I tried this locally - i.e. not on https://sandcastle.cesium.com/, but with a local server.
When you clone CesiumJS from https://github.com/CesiumGS/cesium, and run npm install, npm run build and npm run start, it will start a local server so that the sandcastle is available at http://localhost:8080/Apps/Sandcastle/index.html. All files that are in the local copy of cesium/Apps/SampleData/kml at main · CesiumGS/cesium · GitHub are then available in that sandcastle, so you can just put your file into that directory and load it as shown above.
@Marco13, got it, thanks!