Rendering elements that are outside "expanded project extents" range

[anmolshres98]

I have a question regarding iTwin JS rendering system, specifically the tile tree and what tiles backend returns. My knowledge in the matter is probably incomplete so feel free to correct my assumptions.

For context, I am working on an app that allows users to locate individual models in the viewport. The specific question I have is about models that might be very far away from the project extents (this might be because of other underlying issue like incorrectly geolocated when synced but let's ignore that for now). I know that previously the tiles loaded into the viewer were tightly coupled with the project extents and Paul made some changes a year ago to allow some buffer beyond the extents to have tiles loaded in this PR. If a user has anything beyond this extended extents range the tiles are not loaded.

We do provide visual cues to the user to indicate where the is but again this is not the best solution since the user might want to see the rendered model and not just empty space. I was trying to possibly find a way to force the backend to possibly override the buffer range and force the tiles to be fetched anyways even if it is outside the extended extents range but didn't have much luck in that regard. I tried using setting the useProjectExtents flag to false since that would mean the union of the model ranges are used but it seems that these model ranges still have to intersect with project extents for those tiles to be returned. I did find the requestElementGeometry method and readElementGraphics functions but it seems if we want to use this we would have to fetch geoms from each element in a model one at a time and with 100s of thousands of elements this would be extremely slow and not a viable option at all.

Given all this, my question is, is there a good way to force the render system to request tiles from the backend that are very far away from the project extents, way beyond the expanded project extents buffer range Paul added? or is there a different route we can use to solve this issue? Can we request the needed tiles from the backend and render them on the viewport in a performant manner?

For now I have decided to use tools and decorators already in the core repo for our usecase so this is not a necessary feature request but still wanted to get some clarity on what might be the design decisions in terms of why elements very far outside of extents are not returned? Is there a way to fetch geometries of a arbitrary list of elements from backend with a single call without having to do it one at a time? If not would adding a feature like that be prohibitively costly or a bad idea?

Thanks in advance :)

[pmconne]

Paul made some changes a year ago to allow some buffer beyond the extents to have tiles loaded

The purpose of that PR was not to make stuff outside of the project extents become visible. It was to prevent every single change to the project extents from invalidating the tile cache.

The project extents define the volume of space relevant to the project. All geometry you want to visualize should be inside those extents.

Why do you have geometry outside the extents and why do you want to visualize it without fixing the extents?

[anmolshres98]

Gotcha, thanks for that added info.

Why do you have geometry outside the extents and why do you want to visualize it without fixing the extents?

Yes, the app I am working on would allow a user to move their models back into the project's extents when they are incorrectly located outside during sync. If a model is outside the expanded extents range then the user cannot see the models before moving and saving. There can be a case when you sync that the project extents could be correct and desired values but one or several of the models just happened to be synced very far outside that range by the connector.

[pmconne]

Fixing in source application is not an option?

[bbastings]

Fixing in source application is not an option?

@anmolshres98 If you don't fix the source, how are you "moving the models" so that the next sync applies the correction to changed elements?

[ben-polinsky]

Fixing in source application is not an option?

This is the main impetus for the app. Time and time again we've heard from users in cases where it is "not possible" (i.e. too expensive or too time consuming) to go back to the source data and fix the issue. They want to be able to move things in place post-synchronization.

how are you "moving the models" so that the next sync applies the correction to changed elements?

We use hints in jsonProperties (the transform applied) on the job subject to ensure the next sync is correct.