Incorrect LOD with google 3d tiles when zooming into specific locations

[kfarr]

As a user I expect that the tiles become higher quality when I get close to them. However there are a few areas where we are able to reproduce the opposite behavior -- the tiles become fuzzier (lower LOD) as you approach them. This behavior is consistent from session to session and device to device for a given long / lat.

This has been reported by users in our application as an issue as their goal is to get maximum quality at small distances from the tiles.

We are using the a-frame loader but we have also been able to reproduce this issue in this three-loader-3dtiles repo:

Example1: https://nytimes.github.io/three-loader-3dtiles/dist/web/examples/demos/google-3dtiles/?lat=44.0426217&long=-123.0746543&height=100

Note the area on the left which is shown in very low LOD as you zoom in. The area on the right is correct.

Example2: https://nytimes.github.io/three-loader-3dtiles/dist/web/examples/demos/google-3dtiles/?lat=37.77427681973043&long=-122.42096496959144&height=0

At first I thought this was an issue with our A-Frame application and a mistake in the way that we pass our camera resulting in incorrect LOD calculations, but now I have been able to reproduce in this repo.

We're very motivated to help fix this, are there more ways that we can help diagnose or test?

[Avnerus]

Hi Kieran! This actually sounds like a bug that I recently fixed in @loaders.gl here, and then bumped it in our library to include the fix. The nytimes.github.io example page is most likely not yet updated, but the 1.2.6 npm should contain this fix. Are you using that version? If something went wrong with the patching, I will be able to check it only in August, but hopefully this gives you a lead.

[kfarr]

Hey Avner thanks for checking this out. Unfortunately a quick try to bump our [a-frame loader repo](in this repo to use three-loader-3dtiles 1.2.6 didn't change this behavior. When I have some more time later I'll try cloning this repo and trying directly with the new version.

[Avnerus]

It does look OK to me when I run your link locally (npm run dev)

[kfarr]

@Avnerus you're totally right this repo works as expected locally with this change. I'm not sure why it's not propagating to our a-frame repo but that's for me to investigate further...

[kfarr]

@Avnerus ok I got the library version updated as expected to reflect your recent changes, and now I see this error:

console: TypeError: Cannot read properties of undefined (reading 'elements')

and this is the offending line in our code: > this.runtime.update(dt, this.viewportSize, this.camera);

Which leads me to suspect that the runtime.update() method was updated in this version and we may need to change the parameters that are passed? I'm researching loaders.gl docs on what may have changed...

[Avnerus]

The runtime.update function was recently changed (it's from this library, not loaders.gl). Sorry that some of those breaking changed were introduced rather swiftly to support the draping functionality. update doesn't take a size anymore, instead you pass a Viewport object:

interface Viewport {
  width: number;
  height: number;
  devicePixelRatio: number;
}

first in LoaderProps on first load, and then call runtime.setViewport(viewport: Viewport) on window resize.

[kfarr]

@Avnerus excellent thanks so much! this hint helped me finish out the upgrade and I confirmed the trouble locations now render with high quality LOD as expected!

closed by https://github.com/3DStreet/aframe-loader-3dtiles-component/pull/11