loader.gl load 3dtile very slow（large data ,about 70G）

[ruofeng618]

Hi, I'm facing an issue with using deck.gl load a very large 3dtile data(OSGB to 3dtile) . when change the camera position (Very far from the current camera position),the current viewport of data need take a long time to load data . So What should I do? I think change the loader.gl source code,Please give me some advice.

[ibgreen]

You would need to help us pin down the problem (converted tiles are too big, the converted tileset has issues, perf issue in loaders.gl, perf issue in deck.gl etc):

• What do you mean by long time? Couple of seconds, minutes, ...
• Have you loaded the model in other tools (like CesiumJS) and it performs better there?
• It may not be possible but it helps if you can you make a URL converted tileset available for us to test...

[ruofeng618]

You would need to help us pin down the problem (converted tiles are too big, the converted tileset has issues, perf issue in loaders.gl, perf issue in deck.gl etc):

• What do you mean by long time? Couple of seconds, minutes, ...
• Have you loaded the model in other tools (like CesiumJS) and it performs better there?
• It may not be possible but it helps if you can you make a URL converted tileset available for us to test... Thank you for your reply！

1. I am using cesium.js to load the same data, and loading data at the same camera position（up and direction is same） is smoother and basically without delay.
2. Similarly, I am using loader.gl to load data. Rendering data using cesium.js is similar to using deck.gl to load 3dtile (it takes a long time to render).
3. I am very sorry that I cannot provide the data url due to data confidentiality.
4. However, I see that the skipLevelOfDetail parameter in TilesetTraverser.js is false by default, and the leaked interface does not provide the input of skipLevelOfDetail. I want to know whether loader.gl supports skipLevelOfDetail. I think the skipLevelOfDetail parameter may affect the loading of big data.

[ibgreen]

@Avnerus has been looking at skipLevelOfDetail. It is not supported now. Last we looked it didn't look fully supported in Cesium either, but I may be wrong about that.

[ruofeng618]

@Avnerus has been looking at skipLevelOfDetail. It is not supported now. Last we looked it didn't look fully supported in Cesium either, but I may be wrong about that.

All right！ I tested that Cesium.js turned on skipLevelOfDetail better than turned off skipLevelOfDetail. skipLevelOfDetail skips the request of the parent tile. I found that the 3dtile loaded by loader.gl loads the parent tile first.Will skipLevelOfDetail be supported in the future?

[Avnerus]

Hi! Are you loading Point Clouds or Meshes or other? I do plan for skipLevelOfDetail to be supported in the future but there is no designated date as of yet. Also in CesiumJS it is experimental and may cause gaps to appear.

I would first try to raise maximumScreenSpaceError if you feel it is loading too many tiles. I also added a new option called viewDistanceScale which you can set for example to 0.5 to load half the tiles as it would have in the same distance.

[ruofeng618]

Hi! Are you loading Point Clouds or Meshes or other? I do plan for skipLevelOfDetail to be supported in the future but there is no designated date as of yet. Also in CesiumJS it is experimental and may cause gaps to appear.

I would first try to raise maximumScreenSpaceError if you feel it is loading too many tiles. I also added a new option called viewDistanceScale which you can set for example to 0.5 to load half the tiles as it would have in the same distance.

Hi!

The data is b3dm(OSGB to 3dtile). hope this day will come soon. thanks for your advices，I try to set the viewDistanceScale

[Avnerus]

@hpugis let me know also if you are interested to beta-test our Three.js-based viewer. Would be interesting to see if it gets better result.

[ruofeng618]

@Avnerus
1、three.js does perform better. 2、I found a problem regarding the request. If there are two points A and B (the distance between A and B is relatively long), after the camera flies from A to B, you should request a slice of the current viewport (the camera is very close to the building at this time, theoretically requested There should be few tiles, but in fact a lot of tiles are requested), I wonder whether RequestScheduler considers canceling requests that are not in the current view cone. I saw this piece of code in request-scheduler.ts, where the getPriority method should call the _getPriority method of TileHeader, but I didn’t see any slicing logic other than the cancellation of the cone in _getPriority.

`

_updateRequest(request) {

request.priority = request.getPriority(request.handle); 
// by returning a negative priority, the callback cancels the request
if (request.priority < 0) {
  request.resolve(null);
  return false;
}
return true;

}

`

[Avnerus]

@hpugis

1、three.js does perform better.

Ah nice! Have you implemented yourself or used an existing implementation?

I wonder whether RequestScheduler considers canceling requests that are not in the current view cone.

Yeah this is a bit tricky because in b3dm's ("REFINE" type) using "Base traversal" (not skip) tiles that are outside of the camera frustum often need to be loaded so that parent tiles can be hidden. Currently the scheduler moves far-away tiles to the end of the queue so theoretically they shouldn't be loaded until all the ties in the viewport have finished. Also worth noting that the scheduler does not abort requests that have already started, so any request that was sent will need to finish. This is something I also meant to revisit but will not be able to work on soon (now traveling). If you are interested in taking a shot at a PR please do! I think the key to fix would be here (CesiumJS):

 var outOfView = frameState.frameNumber - tile._touchedFrame >= 1;

We do have the touchTile implementation, so it might even be as simple as checking a similar condition in a tiles getPriority and returning -1 if it is not 'touched'. Let me know if you want to take a stab at it!

[ruofeng618]

@Avnerus

Ah nice! Have you implemented yourself or used an existing implementation? used an existing implementation。

If you are interested in taking a shot at a PR please do!？ I plan to try it first, if the effect is better, I will take a shot at a PR I have another question about tileset-cache. Memory release is based on tileset.gpuMemoryUsageInBytes. Does gpuMemoryUsageInBytes consider texturesByteLength here? I think the MemoryUsageInBytes of a tile is calculated like this: tile.memoryUsageInByteLength=geometryByteLength+texturesByteLength Because the memory gap between the memory displayed by Stats.js and the memory detected by the browser is large

[ibgreen]

tileset.gpuMemoryUsageInBytes

Memory tracking should be improved. This could be a good first PR, as it should not be too complicated.

One wrinkle is compressed textures, where

1. the compressed texture size should be counted (rather than the decompressed size for normal images)
2. a number of mip levels may be supplied, and the sum of all the mip level texture sized should be accounted for.

It may be useful to have a getTextureMemorySize function in the textures module?

[ibgreen]

I wonder whether RequestScheduler considers canceling requests that are not in the current view cone.

At the moment we don't actually cancel the HTTP requests. We mainly delay issuing requests and drop them if no longer needed before issuing the request.

I believe that the TileLayer in deck.gl implemented request cancelling, so there is an implementation there to look at for inspiration.

[ruofeng618]

@ibgreen Thanks, i try this method

[Avnerus]

It may be useful to have a getTextureMemorySize function in the textures module?

Hi! Are you referring the the code here? Seems it's just taking the raw size of the glTF? Or is there another calculation happenning somewhere? If it's the raw size, wouldn't already it count the correct (GPU) compressed texture size? One issue might be if the user opted to not process the glTF. In that case the decompressed size should be counted rater than Draco compressed.

[ibgreen]

The current estimate is probably not too far off, but if textures are not compressed, they expand quite a bit, as does draco encoded geometries. Also there may be alternate representations in the glTF, non-draco decoded geometries etc that are not used. glTFs can refer to external resources that are separately loaded, they would not get counted. etc.

[ruofeng618]

@ibgreen Are**'image/ktx'** and**'image/crn'** not supported? Will it be supported in the future?

[Avnerus]

@hpugis I can say at least that if you use Three.js to load the glTFs, or only the embedded textures, then KTX2 with Basis Universal is supported. In our soon to be released Three.js loader implementation it will be supported.

[ibgreen]

@hugis

• image/crn should be trivial to support. We already have a CrunchLoader, so it is just a matter of
  • [x] recognizing the mime type https://github.com/visgl/loaders.gl/pull/1678
  • [ ] making sure the CrunchLoader is registered during 3D tile loading @belom88
• image/ktx
  • We currently have separate basis loaders and KTX loaders, which complicates the MIME type resolution for KTX encoded basis files.
  • Fixing this is indeed a top priority, and is expected to be addressed within the relatively near future.

[ruofeng618]

@ibgreen @Avnerus That's really great！ The texture of my b3dm data is compressed (crn or ktx). B3dm is parsed into gltf. I see that parseGLTF (loaders.gl\modules\gltf\src\lib\parsers\parse-gltf.ts) is only processed by ImageLoader Texture.

Here I can add a simple logic to determine whether to choose ImageLoader or CompressedTextureLoader to process textures

[ibgreen]

You are welcome to try. Note that you can provide an array of loaders, and it will autoselect the right one.

Though I believe that the KTX files are specified using an extension object so you may need to check for that, see https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/Khronos/KHR_texture_basisu

[ruofeng618]

@ibgreen All right! Thank you for your suggestion, I will try.

[ibgreen]

Closing due to inactivity

[idanlo]

I'm still experiencing the same issue. Zooming into a tileset with this library sends a lot of requests than doing the same thing with the same tileset on Cesium.

Is there any detail on skipLevelOfDetail?

@ibgreen