Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong assessment of terrain tile visibility #9033

Closed
dennisadams opened this issue Jul 16, 2020 · 4 comments · Fixed by #9034
Closed

Wrong assessment of terrain tile visibility #9033

dennisadams opened this issue Jul 16, 2020 · 4 comments · Fixed by #9034

Comments

@dennisadams
Copy link
Contributor

Bumped into this piece of code while dealing with #9032 :

// Terrain state changed. If:
// a) The tile is visible, and
// b) The bounding volume is accurate (updated as a side effect of computing visibility)
// Then we'll load imagery, too.
if (
this.computeTileVisibility(tile, frameState, this.quadtree.occluders) &&
surfaceTile.boundingVolumeSourceTile === tile
) {

This seems like a simple oversight, expecting computeTileVisibility to return a boolean. But computeTileVisibility actually returns a Visibility value where Visibility == {NONE: -1, PARTIAL: 0, FULL: 1}. This leads to cases where partially visible tiles pass as non-visible (since 0 evaluates as false), and where non-visible tiles pass as visible (since -1 evaluates as true).

I assume it's supposed to check if the Visibility return value is not Visibility.NONE, just like here:

if (
tileProvider.computeTileVisibility(tile, frameState, occluders) !==
Visibility.NONE
) {

On a sidenote, although the Visibility.js and Intersect.js objects are quite equivalent, it may be clearer to always return a Visibility value from computeTileVisibility and not an Intersect value like here for instance:

return Intersect.INTERSECTING;

@mramato
Copy link
Contributor

mramato commented Jul 16, 2020

Thanks @dennisadams this looks like a pretty obvious bug. I wonder how long it's been there (git blame is a little useless because of format-only changes that went in a while ago).

@lilleyse are we missing something here or is this just an oversite?

@lilleyse
Copy link
Contributor

It looks like it's been there since #7061. Sorry to keep passing this along, but @kring could you check this?

@kring
Copy link
Member

kring commented Jul 16, 2020

Good catch @dennisadams! This is definitely a bug, and it will cause a one-frame delay in loading imagery sometimes, and load imagery that isn't needed at all other times. The cases where either occur should be relatively rare (which is why we didn't notice before), but they'll happen. Are you up for opening a pull request to fix this?

@dennisadams
Copy link
Contributor Author

Sure

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants