loaders.gl icon indicating copy to clipboard operation
loaders.gl copied to clipboard

TerrainLoader performance improvements

Open kylebarron opened this issue 5 years ago • 0 comments

I've been testing out the new TerrainLoader, and it's great and exciting to work with. I wanted to bring up two points of discussion for potentially improving performance:

  • Reusing Martini instance.

    (Edit: I just realized that I had accidentally turned off the web worker, so maybe this is a moot point. I can't tell if a new worker is created on each load call, or it looks like it reuses workers in a thread pool?)

    When profiling, the single largest function call inside getMartiniTileMesh is to Martini here:

    https://github.com/visgl/loaders.gl/blob/a9fe9c6932da580823320f97a0542c30167d194f/modules/terrain/src/lib/parse-terrain.js#L75

    image

    new Martini just sets up the martini instance to later generate the RTIN hierarchy and then extract a mesh. Note that its only argument is the image's gridSize/tileSize. Assuming that all source tiles have the same number of pixels, it would be faster to do

    onst martini = new Martini(gridSize)
    onst tile1 = martini.createTile(terrain1)
    onst tile2 = martini.createTile(terrain2)
    

    Since TerrainLoader is in its own worker, I'm not sure if it's feasible to reuse Martini? Possibly an array of terrain data could be provided, to iterate over, but I'd have to think more about how to integrate that with TileLayer.

    Edit: It looks like the new initializeWorkers could be well suited to this?

  • Gradual mesh refinement. In the Martini announcement, it's noted:

    The algorithm generates a hierarchy of all approximations of varying precisions — after running it once, you can quickly retrieve a mesh for any given level of detail.

    I.e. once you finish

    https://github.com/visgl/loaders.gl/blob/a9fe9c6932da580823320f97a0542c30167d194f/modules/terrain/src/lib/parse-terrain.js#L75-L76

    the last step of

    https://github.com/visgl/loaders.gl/blob/a9fe9c6932da580823320f97a0542c30167d194f/modules/terrain/src/lib/parse-terrain.js#L77

    is really fast. So theoretically it could be nice to initially provide a high meshMaxError, say 50 meters, to quickly display the rough terrain on the screen, and once all the tiles have loaded, then run getMesh with progressively lower meshMaxErrors for more terrain clarity.

kylebarron avatar Mar 15 '20 01:03 kylebarron