update loader to support google maps 3d tiles

[kfarr]

Work in progress, remaining items before merging:

Pre-merge list:

• @Algorush modify readme docs to add info about new component properties
• for 3DStreet use case, research how to implement 'reduce draw distance' option -- currently way too many tiles are loaded in the distance that are not visible in this use case (workaround by setting distanceScale to 0.01, see comment below)
• @Avnerus to review
• consider adding warning and instructions to docs regarding google policy for default 3d tiles root json load quota Add warning to Readme regarding approval process for use of Google map tiles 3D API #40
• @Algorush test removing preserveDrawingBuffer

Not resolving for this PR (future):

• for 3DStreet use case, research how to switch to inspector camera and not pause the component when in inspector / editor mode. Not part of this ticket, track here (3dtiles visibility not affected by A-Frame inspector camera(s) #16 (comment)))
• Would it make sense to include depandabot version bumps from here? (No, not part of this ticket)
• add this to the /examples/ index file with a screen shot? later after this add support to google 3d tiles for query string #42
• test in VR mode and re-add teleport controls? try google 3d tiles in vr mode, ensure working or debug #44

[kfarr]

We had an issue where way too many tiles are loaded in the distance than are needed for this application. There are not visible as they are mostly occluded by buildings in the scene given the camera placement. For users, the issue can be both the draw area is too big and/or the amount of bandwidth transfer for these tiles is excessive for the use case.

Instead of a radius-based drawing limit, if we just focus on MB of data transferred the distanceScale option addresses this. Testing different values for distanceScale over the same use case of ~45 seconds of usage of the application resulted in the following:

• 0.01 = 10MB for 45-60 seconds of heavy usage;
• 0.1 = 20MB;
• 1.0 = 60MB

Therefore setting distanceScale: 0.01 (for our use case) will fix the throughput issue in the short-term and later we can research drawing only in a specified area.

[Avnerus]

Thank you for this work. Looks great!
I left some comments and questions in the review.

We had an issue where way too many tiles are loaded in the distance than are needed for this application. There are not visible as they are mostly occluded by buildings in the scene given the camera placement

I think the best bet here would be to implement occlusion culling as in the threedtiles project (service, usage).

This requires some modification to three-loader-3dtiles and also to loaders.gl, to allow a callback for an occlusion service. I might be able to get around to this in the near future, but if you need this now you are welcome to take on this task!

[Avnerus]

The example demo states that this and also lat/long/height are available parameters but there is no option to insert them via the query string.

[kfarr]

but there is no option to insert them via the query string.

Correct, the expected behavior in this example is only to place tiles with a long / lat / height specified in the index.html centered at scene origin 0 0 0. Supporting a dynamic, user-specified querystring with lat / long / height was not intended to be part of this example.

[Avnerus]

Got it.
It's maybe OK since the example is anyway not exposed in the demo showcase, but if it works well we should probably consider adding it in the future and also make the example usable without editing the code. Maybe after we have occlusion culling and teleport controls?

[kfarr]

Yes agreed. I've added these tickets to track:

• try google 3d tiles in vr mode, ensure working or debug #44
• prevent occluded tiles from rendering #43
• add support to google 3d tiles for query string #42

[Avnerus]

Why is this needed?

[kfarr]

I'll check with Alex, but I'm pretty sure this is not needed and was only included to improve generation of screenshots for our use case. We can remove this and add elsewhere in our application instead.

[kfarr]

Ok this has been removed. Just to make sure I tested with and without and didn't notice any effect.

[Avnerus]

Thank you!