Page MenuHome

Fix T73730: UDIM "Edit externally" is capable of opening ONLY the first tile
Needs RevisionPublic

Authored by Jeroen Bakker (jbakker) on May 19 2020, 2:51 PM.

Details

Summary

The active tile is not stored in the space, but in the image itself.
This results that the image user of the image space always points to
the first tile and many functionality do not work out of the box.

There are a few solutions:

  1. Sync the tile from the image to the space when the user switches the image or the tile.
  2. When the image user tile is invalid use the active tile number from the image.
  3. Do this on a per operator basis.

The best solution would one of the top two.
This patch is just provided as a work-a-round. and discussion for the actual solution.

Diff Detail

Repository
rB Blender
Branch
T73730 (branched from master)
Build Status
Buildable 8120
Build 8120: arc lint + arc unit

Event Timeline

Jeroen Bakker (jbakker) requested review of this revision.May 19 2020, 2:51 PM
Jeroen Bakker (jbakker) created this revision.
Jeroen Bakker (jbakker) edited the summary of this revision. (Show Details)May 19 2020, 2:52 PM
Jeroen Bakker (jbakker) edited the summary of this revision. (Show Details)
Jeroen Bakker (jbakker) edited the summary of this revision. (Show Details)
Campbell Barton (campbellbarton) requested changes to this revision.Feb 11 2021, 5:16 AM

In the case of an image space, it seems like we would always want to use the active images tile, as this seems to be run-time data that's used to avoid passing an extra argument to functions that already take an image user (ED_space_image_acquire_buffer does this at least).

There might be some situation (in the future even...) where other kinds of image users have a tile we want to respect though.


I'd rather not sync since it's a hassle if there are bugs where the values are outdated (when the image is changed in another view for e.g.).

Your second suggestion seems fine, seeing as the image spaces tile is reset to zero (testing P1958, it seems to work well).

This revision now requires changes to proceed.Feb 11 2021, 5:16 AM

I've been doing work in the UDIM area the past few months and wanted to know how best to proceed with this item here. The approach in this patch making use of the iuser field will work, as would the proposed P1958 (albeit with a tweak to account for changes since; can be provided on request) so it would be good to bottom out on which approach is preferable. There's another fix I'm working on that would require fetching the correct filename so it will also do whatever this change ultimately requires -- either it will fill in the correct iuser or it will take advantage of the P1958 change implicitly.

Personally I would like to pass the correct image user as automatic stuff can be annoying as you need to write workarounds for other behaviors.
In C-code we normally make a copy of the image user to set the tile so we don't alter the original image user. But that isn't easy to add as you will have
an image user that isn't owned by anyone. @Campbell Barton (campbellbarton) was working on a patch related to this. We should check if it would also
solve this case.

T94051: Saving single image of image sequence: image.save_render(): Could not acquire buffer from image. / D14003: Fix T94051: Add parameters to rna_Image_save_render() would add the tile as a parameter and not use the iuser at all.
So perhaps stick what has already been decided and use indivudual parameters to override the given iuser.

image.filepath_from_params(frame=, tile=, ...)

I tend to agree that it's better to be explicit and have the caller indicate which image to use. The other fix I was working on is in the C-code so I was able to create a default/empty image user just for the portion of code required.