This is not a code issue, just a request to help better understand the code. Please accept my apologies if this is not the appropriate place for such a request.
Let's look at this repo as an important example on how to use loaders.gl's 3DTileset loader outside of deck.gl and with another framework (such as threejs). Unfortunately, loaders.gl's own threejs integration example is only a sketch and currently not functional.
The documented approach to the loader is to use 3DTileset.update() or .selectTiles() which takes a deck.gl viewport as parameter. These then invoke onTileLoaded callbacks, and others, at the appropriate time. Internally, a frameState which describes the camera view is then computed from the viewport and used for actual tile selection based on SSE.
This repo made the decision to bypass viewport and instead construct frameState directly. And then to also directly traverse the tileset.
Could you please touch on the thinking behind that decision ? Was it too difficult derive a viewport from the threejs camera ? Or just an attempt to avoid another dependency (deck.gl) ?
Any feedback or ideas very welcome.
This is not a code issue, just a request to help better understand the code. Please accept my apologies if this is not the appropriate place for such a request.
Let's look at this repo as an important example on how to use loaders.gl's 3DTileset loader outside of deck.gl and with another framework (such as threejs). Unfortunately, loaders.gl's own threejs integration example is only a sketch and currently not functional.
The documented approach to the loader is to use 3DTileset.update() or .selectTiles() which takes a deck.gl viewport as parameter. These then invoke onTileLoaded callbacks, and others, at the appropriate time. Internally, a frameState which describes the camera view is then computed from the viewport and used for actual tile selection based on SSE.
This repo made the decision to bypass viewport and instead construct frameState directly. And then to also directly traverse the tileset.
Could you please touch on the thinking behind that decision ? Was it too difficult derive a viewport from the threejs camera ? Or just an attempt to avoid another dependency (deck.gl) ?
Any feedback or ideas very welcome.