I find this name a little confusing. I would have called this prop tilesetOptions. Not sure if it is worth renaming it now.

Why do you need to manually transform the positions? The layer’s modelMatrix should propagate in meter offsets mode.

positions are Float64, can I construct a geometry with Float64Array?

Casting it to Float32Array is fine. Why do you need to apply the modelMatrix?

The layer will attempt to download data and parse with registered loaders. Use a different prop name if that is not the intention.

data of Tile3DLayer is the url to fetch entry point tileset file.

I am proposing the following change:

    const layer = new Tile3DLayer({
      id: 'tile-3d-layer',	      id: 'tile-3d-layer',
      data: '<path-to-your-tileset json file>',	      data: 'https://api.cesium.com/v1/assets/49378',
      loader: Tiles3DLoader,
      // https://cesium.com/docs/rest-api/
      loadOptions: {
        headers: {Authentication: `Bearer <your_ion_access_token>`} 
      },
      ...
    })

Tile3DLayer will do load(data, loader, options) in updateState call. So do you mean data prop will be processed in the base layer.js first?

To get the ion-access-token suitable for use as Bearer, isn't it necessary to first do a couple of ping-pongs with the Cesium API? We had a function for that...

If this works with the tokens users normally use then things are fine.

But if it requires calling a separate function to get the required Authentication header token, then it will no longer be possible to show 3D tilesets in the playground.

I checked the code, also Cesium website, to access the tiles, it only needs the auth header.

it only needs the auth header.

Yes, I believe that is correct, as long as you have the auth header you can access the tiles. My question is how does the application get the auth header in the first place. I seem to recall having to do a ping-pong with the Cesium server to get that header, feeding the ion tokens and ultimately getting the auth header back.

See https://github.com/uber-web/loaders.gl/blob/9c0a8c74dba44e393eb671113b5f3e96768327a8/modules/3d-tiles/src/lib/ion/ion.js

• If the user provides both the assetId and access token, then only needs pass in header.
• If user only provides access token, then the ion util function will try to fetch the all the assets associated with that token and find one asset id.

The current API can cover case 1, for case 2, I am thinking I could provide doc/example of using ion utils to get the asset url pass in Tile3DLayer.

The rest of ion util is for getting ion dataset metadata. I feel that is an application level of detail. I staged my changes and tested with examples, it didn't have auth issues to request the tiles.

am thinking I could provide doc/example of using ion utils to get the asset url pass in Tile3DLayer. I feel that is an application level of detail.

@xintongxia Thanks for explaining. I am not disagreeing with the logic of providing the ion utils separately.

My only real concern is what happens to the JSON playground examples. They will no longer be able to reference ION tokens, right? Is your plan to list headers: {Authentication: "... accessToken"}` in the JSON?

I don't think we are supposed to store the access tokens returned from Cesium ION directly in our github repo, and also I assume those tokens can be rotated by Cesium at any time so even it works during testing it may fail a week later.

One approach could be that you include any required changes to the playground apps this PR:

• either make sure the playground examples still work without ionAccessToken prop,
• or conversely, you could delete those examples, if your decision is that we now require apps to call the ion utility functions to use Tile3DLayer with Cesium ION.

Making sure that we agree that this PR may leave the 3D tiles playground examples broken is really my only concern. I am fine with however you decide to resolve that.

Casting it to Float32Array is fine. Why do you need to apply the modelMatrix?