Return of WallGraphics Entity Parallax Effect When Tilting Globe

CesiumJS
1

Sorry for multiple (deleted) posts. Had problems with images in the post not appearing…

In May of 2017 I posted on the forum related to a problem with a parallax effect I was experiencing with a couple of different objects. Here’s a link to that topic:

https://groups.google.com/forum/#!topic/cesium-dev/4QsA6LPNMqo

At that time I was able to resolve the issue with both the ellipsoid and wall entity objects by providing surface elevation data through callback properties. However, last week I noticed that the wall entities are displaying the same parallax effect as before. I have not changed the code drawing these entities, so I’m not sure what the problem is.

The code used to add these WallGraphics entities looks like this:

var newCurtainSeg = cesiumViewer.entities.add({

id: this.TrackId,

wall: {

positions: new Cesium.CallbackProperty(this.updateCurtainPositions(this), false),

minimumHeights: new Cesium.CallbackProperty(this.updateCurtainMinimumHeights(this), false),

material: new Cesium.ColorMaterialProperty(new Cesium.CallbackProperty(this.updateCurtainColor(this), false))

}

});

``

I attempted to revert to older versions of Cesium to see if I could establish when this problem resurfaced, but that’s not as easy as I thought it would be. With the recent changes to Cesium ion related to a user tokens, elevation data and imagery I’m having a difficult time implementing old versions of Cesium.

A specific question I have about WallGraphics… The “minimumHeights” property is defined as “A Property specifying an array of heights to be used for the bottom of the wall instead of the globe surface.” This makes is sound like the globe surface will be used to define the bottom of the wall if the minimumHeights array is not provided. But this does not seem to be true. If I do not provide minimumHeights data I get a pretty significant parallax effect when I tilt the globe. In order for this parallax effect to occur it seems that the bottom of the walls must be defined somewhere below the surface of the globe. Should the bottom of a WallGraphics follow the globe surface if no minimumHeights data is provided?

Below are several screen captures showing the parallax effect I’m seeing. This flight has been paused, and the screen captures show the bottom of the WallGraphics appearing to move across the surface of the globe based on the direction the globe is tilted. Looking straight down from above the wall is lined up on the runway. But tilting either direction makes the wall appear to be shifted significantly toward the eye position.

wall_down.png
wall_down.png1000×500 724 KB

wall_tilt_1.png
wall_tilt_1.png1000×500 748 KB

wall_tilt_2.png
wall_tilt_2.png1000×500 755 KB

I’ve experimented with providing various values for the array of heights for the bottom of the wall. If heights match the ground elevation the parallax effect is almost eliminated. But since I have numerous aircraft visible at any give time and the walls are following the aircraft the performance takes a big hit if I try to use sampleTerrainMostDetailed to continuously update the minimumHeight values. And hard-coding values that “should” always be under ground still results in significant parallax effect.

Any ideas on an efficient way to draw these walls and prevent the parallax effect?

I’m using Cesium 1.50 and Chrome Version 69.0.3497.100 (Official Build) (64-bit) on a Windows 10 laptop.

Thanks,

Ro

2

A specific question I have about WallGraphics… Should the bottom of a WallGraphics follow the globe surface if no minimumHeights data is provided?

3

Hey Rob,

I was just typing out a response:

It does look like not passing in minimumHeights should clamp the wall to the ellipsoid, so the fact that you’re seeing this parallax might be a bug. Any chance you were able to recreate this in Sandcastle? I’m not seeing it on the green wall here:

Perhaps if you can create a Sandcastle that’s of roughly equal size & granularity to the wall you’ve got? And you don’t have terrain in your app right?

4

One thing that could be happening is that the wall is actually slightly below ground, and depth testing if off, so when you tilt you can see it through the ground like that. Can you confirm/make sure to set depthTestAgainstTerrain to true and see if that makes any difference?

https://cesiumjs.org/Cesium/Build/Documentation/Globe.html#depthTestAgainstTerrain

5

Hi Omar,

Thanks for the response. I am using terrain in the app via new Cesium.createWorldTerrain as seen below

terrainProvider = new Cesium.createWorldTerrain({

requestVertexNormals: true

});

``

I will attempt to put together a Sandcastle example. My application is moving these walls every few milliseconds, so it would be difficult to provide a decent apples-to-apples Sandcastle example with animation (since we use our own animation code). But the fact that the parallax effect is able to be observed when the animation is paused says that I should be able to produce an example with static data.

I’ll let you know when I’ve been able to put something together. Thanks again for the response!

6

Hi Omar,

I set depthTestAgainstTerrain to true, but it had no affect on the issue. It is interesting that I’m not only seeing this with the WallGraphics entities but also with my GLTF models. The aircraft models appear to slide/move closer to the eye/camera position when I tilt the globe. This can be seen very well when the aircraft are still on or near a runway and the globe is tilted.

As I mentioned before this problem existed with WallGraphics and Ellipsoid entities in the past, but had been addressed by providing ground elevation data for the entities. None of that code has changed, but the parallax effect has returned. And now it is being seen in the GLTF models as well.

We did recently subscribe to Cesium ion and are using Cesium’s WorldTerrain and Bing tiled imagey providers (although the problem exists regardless of the source of the tiled imagery).

As unbelievable as I’m sure this will sound… it’s almost as if the reference point for tilting the globe (or the reference point these objects are tied to) has changed.

7

Here’s a short video showing the movement of the WallGraphics and the GLTF model…

http://volans.airportnetwork.com/tmp/cesium_parallax.flv

8

Ok, yeah, that’s really quite a dramatic shift. How recently did you update or how often do you update your Cesium version? Have you tried the recent few versions (1.48, 1.47) ? Those should be recent enough that I’d think you’d be able to test on them, unless you’ve already tried them.

It almost looks like the model is under the terrain. That might be easier to debug, can you show me the code you’re using to create and position that?

Also, does turning off terrain make any change?

9

I update Cesium near the beginning of every month. I was able to revert to the last couple of versions (1.49, 1.48), but there was no improvement/change in the issue.

However, I just turned off terrain (or at least did not add any terrain) and that seems to correct the issue. My altitudes are affected/changed. But the parallax effect goes away completely for both the WallGraphics and the GLTF models.

Here’s a short video with no terrain: http://volans.airportnetwork.com/tmp/cesium_parallax_no_terrain.flv

What does this mean (that turning off terrain fixes the issue)?

10

Following up on that last post about the issue going away when I turn off terrain…

It is interesting to note that when I request the ground elevation from Cesium I’m getting values that are about 140 feet higher than they should be. For instance the videos I posted were of flights at London Gatwick. The elevation of the Gatwick airport is 203 feet. However, Cesium is reporting about 342 feet.

I’m using this method to retrieve the elevation data: var groundAlt = scene.globe.getHeight(Cesium.Ellipsoid.WGS84.cartesianToCartographic(position));

I’m using the code above for the airport’s reported lat/lon (lat: 51.14805556 lon: -0.19027778). I’m also using it to retrieve the ground elevation under my mouse, and when I check elevations around the area covered by the airport I get values ranging between 337 and 350 feet.

I would think that the elevation being reported by Cesium with Cesium’s World Terrain data should be much closer to the actual elevation values.

11

Deleted post to make a few edits to the Sandcastle Example.

I created a Sandcastle example that demonstrates the issue… Sandcastle Example

If you tilt the globe the WallGraphics entities will appear to “slide” across the globe surface toward the eye/camera position. However, if you comment out the terrain (line 17) and then tilt the globe the WallGraphics entities appear to remain in position as desired.

As I mentioned earlier it’s also interesting that Cesium is reporting elevation values about 140 feet higher than actual values (at least around the Gatwick airport).

Any ideas why this is happening or how to “fix” it?

12

Interesting… if I add the elevation “error” (about 140 feet) that is being reported by Cesium to both the top positions and the minimumHeight values for the red wall then the wall appears to remain in the desired position.

I’ve updated the Sandcastle example to demonstrate… Sandcastle Example Adding Elevation ‘Error’

I guess I’m going to start checking the ground elevation reported by Cesium in numerous places around the globe to see if the 140 foot “additional” elevation value is somewhat consistent of if it varies by location. I suppose I could begin to add this elevation “offset” to all of my elevation values.

However, if the elevation is actually wrong in Cesium World Terrain it would definitely be nice to get it corrected. I’m going to compare the values Cesium is reporting at airports around the world and report back here what I find.

13

For what it’s worth here is a sample of elevation data at numerous airports around the world versus what Cesium is reporting with Cesium World Terrain…

LGW (London Gatwick) Actual: 203’ Cesium reports: 339.4’ Difference: 136.4’

LHR (London Heathrow) Actual: 82’ Cesium reports: 206.4’ Difference: 124.4’

SFO (San Francicso) Actual: 13.1’ Cesium reports: -96.8’ Difference: -109.9’

LAX (Los Angeles) Actual: 127.7’ Cesium reports: -9.6’ Difference: -137.3’

ORD (Chicago O’Hare) Actual: 680’ Cesium reports: 555.2’ Difference: -124.8’

MIA (Miami) Actual: 8.5’ Cesium reports: -82.8’ Difference: -91.3’

DCA (Ronald Reagan) Actual: 14.1’ Cesium reports: -99.7’ Difference: -113.8’

SEA (Seattle-Tacoma) Actual: 432.3’ Cesium reports: 327.1’ Difference: -105.2’

SYD (Sydney) Actual: 30’ Cesium reports: 77.5’ Difference: 47.5’

AGP (Malaga) Actual: 52’ Cesium reports: 190.9’ Difference: 138.9’

CPT (Cape Town) Actual: 151’ Cesium reports: 256.3’ Difference: 105.3’

I don’t think I want to sample the “best” elevation data in the callback for the WallGraphics minimumHeights due to performance issues. So I guess I’ll need to find the difference between the documented/reported elevation for each airport and the elevation Cesium is reporting at each airport’s reference location. I’ll then need to add/subtract this difference to any object drawn in Cesium that needs a reference to ground elevation (WallGraphics’ minimumHeights, flight/model positions, objects drawn on the ground, etc.).

I’m not sure what else to do?? Any other suggestions?

14

I believe your values are referenced to MSL.

Scott

15

Hey Scott,

You’re correct. The airport elevations are MSL. I was thinking I was getting MSL reported from Cesium, but I see that cartographic.height says it is “The height, in meters, above the ellipsoid.”

So I’m trying to understand the implications here. How do I use that cartographic height data from Cesium? If it represents height in meters above the ellipsoid what does it mean when Cesium reports a non-zero value? Let’s take SFO for instance. Cesium reports the cartographic height at the airport’s reference point as -96.8 feet. What does this mean? It sounds like the reference point for SFO is 96.8 feet below the ellipsoid? This doesn’t make sense to me. Does it to you?

If it does make sense then how would I relate/translate this value to MSL?

16

And why did adding that “difference” in elevation (between what cartographic.height reported and the airport’s elevation MSL) to the minimumHeights values for the WallGraphics seem to “fix” the issue?

17

Rob,

A good explanation of what’s going on is here and information about how to convert between MSL and ellipsoid heights can be found here and here (near the bottom from Kevin Ring).

18

Scott,

Thanks for the links. The explanation makes perfect sense…

In my case we are very airport-centric. So I’m thinking that I can probably get away with doing exactly what I suggested above. Since I know the reported MSL for the airports I should be able to add the difference in elevation between what Cesium reports and the airport’s MSL to the minimumHeights values to get an approximation of the surface elevation around the airport. For these WallGraphics that we use as curtains/trails behind the aircraft this will probably suffice and minimize the parallax effect.

I’ll give it a try and keep my fingers crossed…

Thanks again for the help!

Rob