iTwin
Cancel tile magnification in children if they no longer meet the magnification criterion
Proposition to fix issue 1094
Prior to this change, a tile was candidate for magnification if the number of elements was lower than 100, however in certain cases, the number of elements does not reflect the actual complexity of the geometries contained inside a tile.
This could result in the production of overly large tiles, if the tile contains line style symbols that were not stroked initially if the tolerance was too high.
We propose to cancel the tile magnification if symbols start appearing in magificied child tiles and if the number of symbols exceed the maximum geometry count (100).
/*****/
Below is the evolution of the magnification for the model linked with issue 1094, and although it may not be the case for other models, here it would have been reasonable to "revert" the magnification decision as soon as the symbols were added. A alternative solution would be to disallow magnification if a tile contains stroke line styles, but this is perhaps a bit too conservative as it could restrict magnification for tiles that would have actually been valid candidates
-b-5-0-0-0-1:2199023256120, primitive count:77, quantized:1, allow magnification: 1, num included elements:28, num excluded elements: 0, info: estimated triangle count: 0, geometry count: 28,
-b-5-0-0-0-2:2199023256120, primitive count:67201, quantized:1, allow magnification: 0, num included elements:28, num excluded elements: 0, info: estimated triangle count: 0, geometry count: 4605, // Here some elements start appearing, but since the primitive count is not yet too high, we can still mitigate the issue by opting for subdivision instead of magnification
-b-5-0-0-0-4:2199023256120, primitive count:125856, quantized:1, allow magnification: 0, num included elements:28, num excluded elements: 0, info: estimated triangle count: 0, geometry count: 8157,
-b-5-0-0-0-400:2199023256120, primitive count:3662729, quantized:0, allow magnification: 0, num included elements:28, num excluded elements: 0, info: estimated triangle count: 0, geometry count: 18482,
@pmconne what do you think of this approach, is it viable? If yes, am I supposed to flush previous tile children / requests that I am replacing somehow?
A alternative solution would be to disallow magnification if a tile contains stroke line styles, but this is perhaps a bit too conservative as it could restrict magnification for tiles that would have actually been valid candidates
You would only need to disallow magnification until we reach a tile whose LOD is sufficient to cause us to actually stroke the line style, in which case your normal logic for determining refinement strategy based on number of primitives would kick in. This would prevent you from having to revert a previous decision to magnify a parent tile and reload all of its descendants.
