fix(textureatlas): Allocate texture space more incrementally on resize

[donmccurdy]

Description

Texture coordinates are currently compressed to 12-bit precision, effectively on a 4096x4096 grid. Perhaps that could be revisited at some point, but in the meantime billboard-related code must be very careful with texture coordinates in large atlases. This PR makes two changes, intended to improve texture atlases along those lines:

1. Atlases are now constrained to power-of-two dimensions on resize. By doing so we guarantee that the pixel grid aligns cleanly with the 4096x4096 grid used when quantizing texture coordinates.
2. When resizing atlases, TextureAtlas.js now considers more candidate sizes, and in most cases should not allocate space in the atlas >>2x the requirement of the input images. Packing density, of course, is less predictable... but I haven't found egregious cases remaining after applying this fix.

Previously as current candidate atlas size became larger, the resize algorithm would use a larger multiplier to select the next candidate size, (2x, 4x, 8x, 16x, ...). In the particular case of #5154 this created a 2K-by-8K atlas, which required 16x more memory than required and (more visibly) flew past the 4096px limit at which Cesium's texture compression can precisely address pixels in the atlas.

Preview:

before	after

This PR should fully fix the cause of the clipped dots (•••) at the top of the icon. The unwanted vertical line visible on the left side of the icon happens to be somewhat improved by this PR, but that also has additional causes left for an upcoming PR.

Issue number and link

• Partial fix for Billboard clipped on right side #5154

Testing plan

I'm looking through existing examples with one or more billboards. For each relevant example, compare computed texture atlas size before vs. after. Check that atlas size is "reasonable", i.e. not >> 2x the total area of the input images.

• iTwin Feature Service
  • Before: 768 x 3072
  • After: 1024 x 1024
• Billboards
  • Before: 236 x 120
  • After: 128 x 32
• Clustering
  • Before: 264 x 1040, 752 x 220, 768 x 192, 256 x 256
  • After: 512 x 512, 256 x 128, 256 x 256
• Map Pins
  • Before: 192 x 192
  • After: 128 x 128
• GeoJSON simplestyle
  • Before: 768 x 3072
  • After: 1024 x 512
• Particle System Tails
  • Before: 320 x 1280
  • After: 256 x 256
• LocalToFixedFrame
  • Before: 264 x 912
  • After: 512 x 256
• Moon
  • Before: 848 x 232
  • After: 256 x 256
• Mars
  • Before: 1072 x 268, 768 x 192
  • After: 512 x 512, 256 x 256
• Particle System Fireworks
  • Before: 10240 x 1280
  • After: 1024 x 1024

Author checklist

• I have submitted a Contributor License Agreement
• I have added my name to CONTRIBUTORS.md
• I have updated CHANGES.md with a short summary of my change
• I have added or updated unit tests to ensure consistent code coverage
• I have updated the inline documentation, and included code examples where relevant
• I have performed a self-review of my code

PR Dependency Tree

• PR fix(textureatlas): Allocate texture space more incrementally on resize #13042 👈
  • PR refactor(BillboardCollection): Require instancing, remove batch mode #13049
    • PR fix(BillboardCollection): Fix precision loss in billboard image texcoords #13050

This tree was auto-generated by Charcoal

[github-actions]

Thank you for the pull request, @donmccurdy!

✅ We can confirm we have a CLA on file for you.

[donmccurdy]

Since we'll have ... er, other challenges ... if the texture atlas size exceeds 16K x 16K, in practice this loop can't spend more than 28 iterations for the largest supportable atlas size. No need to use a sliding scale factor (which may cause us to miss more optimal atlas sizes) to save a small number of iterations.