Blender currently assumes, and hardcodes in various places, that UDIM
tiles start at 1001. This is not required and is problematic when
working with assets produced by other software where the artist laid out
tiles differently. Blender is already capable of handling sparse tile
sets (non-contiguous tiles) so the restriction around starting at 1001
is unnecessary in general.
The primary set of changes here is to remove the assumption and
restriction that 1001 is special and must always be present. These were
mostly straightforward changes until trying to update the Python API
support…
The Python API allows scripts to update a tile's tile_number field
directly, with no other processing taking place. This is very efficient
and allows the Python's view of the tiles list to remain unchanged
during the course of the operator or while iterating over the list for
example.
But this API is actually broken in 2 ways currently. 1) When a tile
changes its tile_number it will lose the ability to lookup its cached
ibuf entry. It will show as magenta in the editor space AND the cached
entry will be orphaned as no cleanup occurs. 2) BKE_image_add_tile and
gpu_texture_create_tile_mapping both assume a sorted list of tiles to
prevent duplicate tiles from being added and in order to display them
properly. This is something that's not accounted for after python
manipulation… oops.
This patch fixes the issues above:
- Removes assumptions on 1001 always being present and is no longer mandatory
- Makes the Python API re-assign the cached ibuf entry in order to prevent orphans and to correctly show the image
- Sorts the tile list before each operation that requires it. Such operations are only called infrequently and shouldn't interfere with scripting in surprising ways.
Examples using a slightly modified UDIM Monster demo file
Non-1001 starting tile in master:
This patch:
