Discrepancy between zoomTo() and flyTo()

CesiumJS
1

I get a discrepancy between the viewer’s zoomTo() and flyTo() methods when I specify the offset. Zoom is rotated the way I want, but fly isn’t. The discrepancy is the same whether in 2D or 3D. And in both cases, the range/height offset value is ignored. Here’s my code:

var viewer = new Cesium.Viewer(‘cesiumContainer’, {
navigationHelpButton: false,
navigationInstructionsInitiallyVisible: false,
baseLayerPicker: false,
geocoder: false,
timeline: false,
animation: false,
sceneMode: Cesium.SceneMode.SCENE2D,
baseLayerPicker: false,
imageryProvider: provider
});

var heading = Cesium.Math.toRadians(90);
var pitch = Cesium.Math.toRadians(-30);
var height = 10000;
if (viewer.dataSources.length > 0) {
//loop through datasources to find entities with the selected object’s id.
for (var x=0;x<viewer.dataSources.length;x++) {
var matchingEntity = viewer.dataSources.get(x).entities.getById(objectId);
if (matchingEntity != undefined) {
viewer.flyTo(matchingEntity, new Cesium.HeadingPitchRange(heading, pitch, height)).then(function(result){
if (result) {
viewer.selectedEntity = matchingEntity;
}
});
}
}
}

``

The attached images show the effects of both methods, with me manually zooming in since the range didn’t work.

flyto 2d.JPG
flyto 2d.JPG867×504 79.6 KB

zoomto 2d.JPG
zoomto 2d.JPG751×463 61.4 KB

2

I forgot to specify that this is for v1.6.

3

Just wanted to chip in as well and mention that I haven't been able to get height/range in the HeightPitchRange function to work either. I was wondering if it was something I was doing wrong.

4

Bart,

Thanks for the write up. Apparently the low-level camera flyToBoundingSphere function (which is what viewer uses) is documented to always orient north in 2D. I think that’s a design mistake so I opened a new issue to be sure we change it: https://github.com/AnalyticalGraphicsInc/cesium/issues/2473

I also think there is a bug in your code. While zoomTo takes an the offset as a second parameter, like so:

viewer.zoomTo(matchingEntity, new Cesium.HeadingPitchRange(heading, pitch, height))

flyTo has quite a few different options, so the second parameter is an options object offset being one possible property.

viewer.flyTo(matchingEntity, {

offset: new Cesium.HeadingPitchRange(heading, pitch, height)

})

Of course you could easily argue that this is an API issue and could be made easier to use, such as making both functions take an options object. It seemed silly to do while implementing though since zoomTo only has one optional parameter (though if we ever add a second, it will definitely happen).

I hope that helps.

Thanks,

Matt

5

The code I used had the HeadingPitchRange setup properly and I still haven't been able to get the range to work properly.

ch.viewer.flyTo(ch.viewer.entities.getById('Germany'), {offset: new Cesium.HeadingPitchRange(90,-90,5000000000)})

Here.. ch is an object with several shortcuts to objects within Cesium and contains many helper functions I use. I have a label on every country, with the id of the entity being the country name. This doesn't work. It zooms all the way into Germany.

Thoughts?

6

David,

I assume that’s a typo and you mean HeadingPitchRange? Here’s a complete working example, just paste into Sandcastle and comment one of them out.

var viewer = new Cesium.Viewer(‘cesiumContainer’);

var redRectangle = viewer.entities.add({

rectangle : {

    coordinates : Cesium.Rectangle.fromDegrees(-110.0, 20.0, -80.0, 25.0),

    material : Cesium.Color.RED.withAlpha(0.5),

    outline : true,

    outlineColor : Cesium.Color.RED

}

});

//45 degree counter-clockwise rotation from, 30 degree pitch looking down, 4000000 range.

//Omit range to use the calculated default.

viewer.zoomTo(redRectangle,

          new Cesium.HeadingPitchRange(Cesium.Math.toRadians(45),

                                       Cesium.Math.toRadians(-30),

                                       4000000));

viewer.flyTo(redRectangle, {

offset : new Cesium.HeadingPitchRange(Cesium.Math.toRadians(45),

                                      Cesium.Math.toRadians(-30),

                                      4000000)

});

7

Like everything else in Cesium, HeadingPitchRange takes radians and meters. This was an oversight and we will be adding a HeadingPitchRange.fromDegrees function for 1.7 (because I’m already sick of having to convert all of the time too :slight_smile:

8

Not sure what the deal is but, even copy and pasting your example in.. it absolutely does not work. Your example in the sandcastle works. Taking the flyTo and putting it in the Chrome dev console and running the same thing with my entity, does the same thing every time

9

Thanks, Matt. Your’e right about my flyTo() bug. I replaced my flyTo() method with one similar to yours, but like David, I’m still seeing the range offset value being ignored in my code.

I think there is a difference between a dataSource’s entities and the viewer’s entitities. In my code, I’m using a CzmlDataSource,and when I put my code into Sandcastle, I see the range offset being ignored:

var viewer = new Cesium.Viewer(‘cesiumContainer’);

var redRectangle = viewer.entities.add({
rectangle : {
coordinates : Cesium.Rectangle.fromDegrees(-110.0, 20.0, -80.0, 25.0),
material : Cesium.Color.RED.withAlpha(0.5),
outline : true,
outlineColor : Cesium.Color.RED
}
});

var czml = [{“id”:“document”, “version”:“1.0”},{“id”:“7056”,“name”:“BEAXM6NLHF”,“point”:{“color”:{“rgba”:[255,0,255,122]},“outlineWidth”:1,“pixelSize”:10,“show”:true},“position”:{“cartographicDegrees”:[-93.5783,40.0997,0.0]}}];
var czmlDataSource = new Cesium.CzmlDataSource(“testCzml”);
viewer.dataSources.add(czmlDataSource);
czmlDataSource.load(czml, ‘Test CZML’);

/*
//45 degree counter-clockwise rotation from, 30 degree pitch looking down, 4000000 range.
//Omit range to use the calculated default.
viewer.zoomTo(redRectangle,
new Cesium.HeadingPitchRange(Cesium.Math.toRadians(45),
Cesium.Math.toRadians(-30),
4000000));
*/
viewer.flyTo(czmlDataSource.entities.getById(7056), {
offset : new Cesium.HeadingPitchRange(Cesium.Math.toRadians(45),
Cesium.Math.toRadians(-30),
4000000)
});

``

Bart

10

Bart,

Checking the documentation, they are both Cesium.Entity objects so there shouldn't be a difference between the two. You can zoomTo and flyTo items from CZML and item inserted via the standard Entity API. One thing I have noticed though is that, I can't zoomTo CZML objects all the time. I'm not sure if its a situation of availability, the interval, or what the problem is. Earlier today, I was able to play a CZML that contained two moving objects. While ONLY the first was moving, I couldn't zoomTo. While both were moving, I could. The second object stopped moving and I could no longer zoomTo.

Also worth mentioning, my issue of the HeadingPitchRange not working is when referencing Entity API objects and not Entity objects created via CZML. I tried the changes Matt suggested and can't seem to make it work. The code he provided works fine when pasted into the Sandcastle but in my own code, does nothing. The only thing I changed was the object it references.

11

Just a bump to make sure this doesn't drop off the radar

12

No worries, this is definitely on my radar. You can’t zoomTo/flyTo a moving entity at this time while animating. The flights use the location the object is at the time you initiate the zoom/flight. It’s a limitation I hope to fix in the future, but it’s actually a pretty hard problem because flights operate on wall-time, not simulation time. (at least right now they do).

13

So, this isn't a complaint, I just wanna make sure I'm understand this correctly... so you're saying that, in order for me to do a zoomTo/flyTo all entities within the playback need to be, not moving? The reason I ask is, my example from before.. say I have two objects and my CZML timespan got from noon today until 1pm. Object 1 has epoch value set to noon, and has trajectory data to move it starting at time 0. Object 2 has epoch set to time 10 minutes after noon and has trajectory data from then on. In this case.. I can zoomTo/flyTo while both are moving, but not before Object 2 has begun moving.

I'm not sure if this is an issue with availability or what. I haven't had time to test it in the last few days.

Have you had the opportunity to look at HeadingPitchRange again? Was glad to see that Bart was having the same issue and that I wasn't going crazy