flyTo gltf model

1. A concise explanation of the problem you’re experiencing.

I need to flyTo a gltf model. I want the resulting view to be fairly up close, so I was trying to use the boundingSphere of the entity/modelGraphics. Maybe I’m missing something, but I haven’t found an easy way to do this. Do I need to create a ModelVisualizer from the dataSourceDisplay property of the viewer?

2. A minimal code example. If you’ve found a bug, this helps us reproduce and repair it.

Sample code based upon one of the sandcastle demos online:

**// **myEntity.model is defined and loaded with a gltf model

var entityView = new Cesium.EntityView( myEntity, cesium.scene ); entityView.boundingSphere, new Cesium.HeadingPitchRange( 0.5, -0.2, entityView.boundingSphere.radius * 4.0 ) ); Cesium.Matrix4.IDENTITY );

// entityView.boundingSphere is undefined after creating the EntityView?

3. Context. Why do you need to do this? We might know a better way to accomplish your goal.

Fly the camera to ModelGraphics.

4. The Cesium version you’re using, your operating system and browser.

**Cesium 1.41, Windows 10, Chrome **Version 63.0.3239.132 (Official Build) (64-bit)

I figured it out, but in the process, I think found a bug. If you use the code above to view a tileset(boundingSphere), and then call flyTo with an entity the resulting camera position is bogus. If you move the camera after calling the lookAtTransform then the problem doesn’t happen. We have a list view of all of the items in the scene(clicking on item causes the camera to view that item), so this is easy to do in our application. tileset.boundingSphere, new Cesium.HeadingPitchRange( 0.5, -0.2, tileset.boundingSphere.radius * 4.0 ) ); Cesium.Matrix4.IDENTITY );

// without moving the camera, call

cesium.flyTo( entity, { duration: 2 } )

My guess is that moving the camera fixes the transform or something like that. See attached picture for the resulting view.


Hi Scott,

Great you solved your issue! The call to Cesium.Matrix4.IDENTITY ); is necessary. However we just encapsulated that into Viewer.zoomTo in this recent PR, #6104.

Does that help solve this? It will be pat of the release on Thursday.



I’ll test and update the results early next week.