Changing vertical exaggeration

[wbfryan]

When changing the vertical exaggeration from the default of 1 to a higher value, such as 5, the tiles in the far distance of the viewport are not exaggerated, just those tiles in the foreground. This produces a tear in the scene along the tile boundaries.

Has anyone else experienced this problem? Is there a work-around?

[tag]

I don't experience this problem, and VE in the examples we have is applied uniformly over the terrain. Would you please post a screen shot of what you're seeing.

[jcoplan]

Attached are two examples of the tearing occuring as a result of the vertical exaggeration.

The first example is over Florida looking southeast. The tile in the foreground is cleary having VE applied to it and as a result is drawn lower than the background tiles which are not.
http://www.cs.rit.edu/~joc0225/tearing1.JPG

Zooming in a little stopped the tearing in this situation:
http://www.cs.rit.edu/~joc0225/nontearing1.JPG

The second example is to the west of the Gulf of California, looking south at a high zoom level. Zoomed out there is no tearing.
http://www.cs.rit.edu/~joc0225/notearing2.JPG

But as you zoom in the tiles that should be drawn in the background disapear. Their disapearance I suspect is due to the VE not being calculated and as a result the tiles being expected to be above the camera.
http://www.cs.rit.edu/~joc0225/tearing2.JPG

We are setting the VE with the method
WorldWindGLCanvas.getSceneController().s etVerticalExaggeration(slider.getValue() );

Thanks.

[tag]

The problem you are seeing is not due to VE, only exacerbated by it. The problem is that the elevation data for the tiles in the distance are not yet local, so those tiles are drawn with an elevation of 0. This is behavior as designed. Normally you would not notice this because the space between the tiles is filled in. But a bug in the surface tile rendering code sometimes drops the "fill-in" for certain edges. This will be fixed in the next release, and even today you won't see it when the elevation data is eventually retrieved and cashed locally by WWJ. That's why zooming in or out sometimes fixes it: the elevation for the particular resolution associated with that zoom level is local. Thanks for posting the problem.

[jcoplan]

While I might be wrong I think you have misdiagnosed the problem. My feeling is it is not a matter of missing elevation data.

Consider this third example taken from the ocean floor:

This first screenshot shows no tearing and the elevation data being loaded succefully.
http://www.cs.rit.edu/~joc0225/notearing3.JPG

This second screenshot shows the view being changed only by tilt and tearing starting to occur. This cant be a problem of missing elevation data no?
http://www.cs.rit.edu/~joc0225/tearing3.JPG

This third screenshot shows the same view as the previous screenshot being reduced to 1. Note that the corners of the tile here match the tiles that are being drawn in screenshot 2.
http://www.cs.rit.edu/~joc0225/notearing3_VE1.JPG

Finnally no amount of waiting solves the tearing issuse. It does not seem to be a matter of missing eleveation data, rather that WW does not recognize that there are more tiles to draw to the screen if there is a negative elevation being exagerated. This problem will only manifest itself at below sealevel elevations because otherwise the tiles take up more space instead of less.

[tag]

Yes, I could be wrong. We'll look into it. Thanks.

[patmurris]

jcoplan: BTW: nice dataset ;)