search

iTwin / itwinjs-core

Monorepo for iTwin.js Library
https://www.itwinjs.org
MIT License
583 stars 211 forks source link

Fit view tool makes iTwin viewer download thousands of background map tiles until it freezes/crashes #5139

Closed mdastous-bentley closed 1 year ago

mdastous-bentley commented 1 year ago

This was first reported in the Design Review application and can be reproduced in production deployment : image

After chose all models from the 3d models tab, you must click on the 'Fit view' tool.

iTwin.js version used: 3.5.5

pmconne commented 1 year ago

Provide repro steps in your issue description please.

I followed your link, chose all models from the 3d models tab, and was presented with a view of the globe displaying 72 tiles.

mdastous-bentley commented 1 year ago

Following BIM was extracted exton1.zip

After opening it in display-test-app, we can see the 'ellipsoid' globe mode is causing the issue. Switching to 'planar' globe mode, problem disappear.

Further investigations shown that tile selection mechanism fails to compute a valid pixel size, as a result, a large amount level 20 tiles (last available LOD) are downloaded.

In TileDrawArgs.getPixelSizeFromProjection() world coordinates tile corners get transformed to what appear to be invalid view coordinates, such as: -18065963.37771991, 54691207.63877826, -928203.68

Call stack:

getPixelSizeFromProjection (TileDrawArgs.ts:157)
getPixelSize (TileDrawArgs.ts:125)
computeVisibilityFactor (RealityTile.ts:374)
selectRealityTiles (RealityTile.ts:290)
selectRealityChildren (RealityTile.ts:232)
selectRealityTiles (RealityTile.ts:319)
selectRealityTiles (RealityTileTree.ts:420)
draw (RealityTileTree.ts:221)
addToScene (MapTileTree.ts:999)
(anonymous) (TiledGraphicsProvider.ts:44)
forEachTileTreeRef (MapTiledGraphicsProvider.ts:39)
addToScene (TiledGraphicsProvider.ts:44)
createScene (Viewport.ts:2319)
renderFrame (Viewport.ts:2417)
renderLoop (ViewManager.ts:404)
mdastous-bentley commented 1 year ago

A second imodel (exton1_fixed.zip) was published using a slightly modified DGN file, and problem suddenly disappeared.

mdastous-bentley commented 1 year ago

@pmconne repro steps updated, can you reproduce now?

pmconne commented 1 year ago

A second imodel (exton1_fixed.zip) was published using a slightly modified DGN file

Do you know, or can you find out, how specifically the DGN file was modified? I see that the ecef location and project extents differ between the two iModels.

repro steps updated, can you reproduce now?

Yes - thanks.

mdastous-bentley commented 1 year ago

Do you know, or can you find out, how specifically the DGN file was modified? I see that the ecef location and project extents differ between the two iModels.

@pmconne Here are the details:

  1. I opened it in MicroStation (10.17.01.58) with no workspace.
  2. I fit the view. I noticed a polygon surrounding the area.
  3. I deleted the polygon.
  4. I key-in a “compress design”.
  5. Save
  6. Save Settings
pmconne commented 1 year ago

The original project extents are pretty silly. My inclination is to not investigate further. image

mdastous-bentley commented 1 year ago

So basically you're saying the Mstn connector has created an invalid iModel ?

pmconne commented 1 year ago

More likely, the user submitted to the connector a DGN with some junk floating out in the middle of the ocean and the connector didn't complain about it, instead expanding the project extents to encompass it. Did the DGN file come from a user?

pmconne commented 1 year ago

A rogue reality mesh blew out the project extents. Ideally something earlier in the pipeline would have identified the error and prevented it from manifesting as a display issue.