Was there a breaking change in 1.32 to scene.morphTo3D ?

CesiumJS
1

After updating from 1.31 to 1.32, my code that toggles from 2D back to 3D using viewer.scene.morphTo3D(2.0) hangs-up the browser with ballooning memory usage.

I cannot reproduce the issue on my localhost, I have no problems running on my development laptop.

The issue only occurs with the code loaded on my GoDaddy-hosted development server.

I reverted the GoDaddy-hosted development server to Cesium 1.31, and the issue goes away.

After several frustrating hours, trying to narrow-down the cause, it looks like it may be related to

Cesium 1.32 "Added support for an orthographic projection in 3D and Columbus view.

  • Set projectionPicker to true in the options when creating a Viewer to add a widget that will switch projections. #5021
  • Call switchToOrthographicFrustum or switchToPerspectiveFrustum on Camera to change projections."
    My attempt to create a Sandcastle example, using a snippet of my code, follows. Set the ScenePicker in the Viewer to 2D, then click the “3D” button.

var viewer = new Cesium.Viewer(‘cesiumContainer’);
Sandcastle.addToolbarButton(‘3D’, function(){
switch (viewer.scene._mode){
case 2 :
Cesium.when(viewer.scene.morphTo3D(2.0),function(){
viewer.scene.completeMorph();
console.log(“scene.morphTo3D completed…”);
});
break;
case 3 :
console.log(“already in 3D scene mode…”);
break;
}
});

``

When I paste this example code into http://cesiumjs.org/Cesium/Apps/Sandcastle/index.html?src=Hello%20World.html&label=Showcases

change to 2D, and click “3D” button, it results in the following error:

An error occurred while rendering. Rendering has stopped.

An error occurred while rendering. Rendering has stopped.
undefined
DeveloperError: A PerspectiveFrustum or OrthographicFrustum is required in 3D and Columbus view
Error
at new DeveloperError (http://cesiumjs.org/Cesium/Source/Core/DeveloperError.js:44:19)
at Camera.update (http://cesiumjs.org/Cesium/Source/Scene/Camera.js:922:19)
at Scene.initializeFrame (http://cesiumjs.org/Cesium/Source/Scene/Scene.js:2519:22)
at CesiumWidget.render (http://cesiumjs.org/Cesium/Source/Widgets/CesiumWidget/CesiumWidget.js:685:25)
at render (http://cesiumjs.org/Cesium/Source/Widgets/CesiumWidget/CesiumWidget.js:72:32)

I do not get this error, or any error, on my development site!

The viewer begins to render the scene in 3D, then fails to load any more tiles, as TaskManager shows one of the chrome.exe processes eating up 2GB of available memory.

Does anyone have a suggestion for the next step in troubleshooting and resolving this?

Thanks-

-Jon

2

I confirmed on my localhost (development laptop) that when running Cesium 1.31, the Sandcastle example above switches from 2D to 3D scenemode without errors.
The Sandcastle example above throws the error while rendering on my localhost when running Cesium 1.32.

Apparently, I need to provide some new parameters to the 3D scene? Shouldn’t there simply be a default for PerspectiveFrustum or OrthographicFrustum ?

3

I do not understand WHY this broke in 1.32, but I figured out the completeMorph is breaking my code.

viewer.scene.morphTo3D(2.0) has 2.0 seconds to complete the morph from 2D to 3D

The Cesium.when should run the callback function when that morphTo3D is complete. To minimalize this example for Sandcastle, I omitted the rest of the logic, which is a flyTo that I don’t want to start until after the morphTo3D is complete.

I do not recall why I had included viewer.scene.completeMorph(); before the (omitted) flyTo, but it is the completeMorph that is breaking the code, and causing either a memory leak, or throwing a rendering DeveloperError.

If allowed to complete, without forcing completeMorph, then morphTo3D does automatically switchToPerspectiveFrustum, from the 2D OrthographicOffCenterFrustum.

After morphTo3D(), I do not have to explicitly run viewer.scene.camera.switchToPerspectiveFrustum();

Forcing completeMorph(); leaves the viewer in Cesium.OrthographicOffCenterFrustum and throws the error.

4

I opened issue #5197

5

Thanks Jon! I posted in your GitHub issue asking Dan if he can look into this.

-Hannah

6

Thanks, Hannah. I hate to be a PITA. I did find a workaround for my code.
Now I can start work on some new features.

I know y’all prefer a “minimalist” sandcastle example, like I posted this morning. I hope I didn’t aggravate Dan by posting 3 more complex test examples that show a flyTo after the morphTo3D, with and without the workaround. I know you are all busy, but the #5197 issue I ran into may have implications for other users down the road.

I appreciate the fix in v1.32 to the polygons clampedToGround not displaying correctly in 2D, that first appeared in v1.31

Best regards,

Jon Hall

603-616-8066

7

No problem, Jon! More detail is helpful for us to get to the root of the problem, so we appreciate the example for reproducing the error.
We’ll try to get this fixed for 1.33, but Dan has a lot on his plate so it might have to be pushed off a little later. But either way, we’ll try to address it soon.

Thanks again!

Hannah