Paul Connelly

Thanks. Can you clarify what you mean by "on startup"? I assume it can't be observed until you open an iModel. Does it only ever occur with the first iModel...

> The .Tiles files are cleaned up and freshly generated every time the model loads By whom, and why? > Strangely, the generated "{modelName}.bim.Tiles" file starts out at about 60kb,...

The broken .Tiles file contains 2 tiles; the working one contains 3 more tiles in addition to those 2. That's the only difference I can see. I suspect that when...

Does this ever occur outside of the context of force-killing the process in the debugger? Does it ever occur outside of debugger?

Do you intend to simultaneously enhance the tileset publisher to output this extension, so you can test both sets of changes against one another? Or will you do that later...

You've added a fair amount of new logic, but no new unit tests. Please add some to ensure your logic for dynamically updating the texture works as expected. Ideally also...

> A new helper method isAffectedByScheduleScript() is added to the IModelTile class. It checks whether the tile is affected by a ScheduleScript, based on matching the model ID and element...

> If I understand correctly then, while a potential gain in performance when zoomed in, would there be visual difference to flickering (loading tiles) while refreshing those tiles? It could...

> Everything is working as intended, including both transform and non-transform changes. Looking for feedback on how to refactor the code better Number one priority: add unit tests to **prove**...

Please make the builds pass so we can verify tests etc.