Tiles: Allow passing all loader options in tile content loading

[Avnerus]

Hi!
Following my discussion with @dryabinin-actionengine, we need a way to pass loader parameters (loader-specific such as 3d-tiles and gltf as well as top level such as maxConcurrency) in this segment. Currently only options for fetch are allowed.
I think the ideal solution would be to dismiss fetchOptions and override the default options with tileset.options (which would also include fetch).
Thank you!
cc: @ibgreen

[ibgreen]

Yes this makes sense.

I would need to look at the code, but should that be tileset.loadOptions or tileset.options.loadOptions?

I think it should be a pure loaders.gl options object, sounds like tileset.options can contain Tileset3D specific options.

[Avnerus]

Maybe tileset.loadOptions, separate to tileset.options makes the most sense.
loadOptions would have throttleRequsts (and i am adding in my PR maxRequests) and other 3d-tiles , gltf worker options etc.
options would have ellipsoid, modelMatrix, and the callbacks (?).
Then there is the question of where to put options such as
maximumMemoryUsage, maximumScreenSpaceError, because these options effectively impact the loading, as in which tiles are loaded and which are not. I may intuitively see them also as loadOptions in the 3d-tiles namespace (probably throttling should be in that namespace too), but I am open for either way.

[ibgreen]

Maybe tileset.loadOptions, separate to tileset.options makes the most sense.

Yes

loadOptions would haver 3d-tiles , gltf worker options etc.

Yes

loadOptions would have throttleRequests (and i am adding in my PR maxRequests)

While that does make sense from user perspective, let's double check where the requestScheduler is currently managed. It might not be part of standard loadOptions, but rather the Tileset3D.options. Basically, loadOptions should only be options handled by @loaders.gl/core or any sub objects for specific loaders.

maximumMemoryUsage, maximumScreenSpaceError, because these options effectively impact the loading, as in which tiles are loaded and which are not. I may intuitively see them also as loadOptions in the 3d-tiles namespace (probably throttling should be in that namespace too), but I am open for either way.

Yes, I agree in principle, but the Tileset3D class is the traversal engine, it kind of sits on top of the loader system, so I am a bit reluctant to add non-loader options at this time. I think the Tileset3D class is ripe for some refactoring, especially as we are adding more multistep loaders, but we won't be able to do that in time for 3.0, so let's keep as is for now. We can open a tracker task discussing how to refactor it for 4.0

[Avnerus]

Hi,
Yeah. if I understood you question correctly I guess the requestScheduler is managed internally by tile-3d and tileset-3d, and not not by the load function, as well as the other traversal related parameters.
I am fine with keeping it as you suggested for this version. I think then it should be something like this?

   const options = {
      [loader.id]: {
        isTileset: this.type === 'json',
        ...this._getLoaderSpecificOptions(loader.id)
      },
     ...this.tileset.loadOptions
    };

So to allow the user to override 3d-tiles options such as loadGLTF: false