The UDIM tile grid: Design and feedback thread

Feature & Design Feedback
1

This thread here is about changing certain aspects of the UV tile grid described below. It was requested that community feedback be gathered before moving forward with addressing some of the issues so that the decisions can better be documented and agreed upon first.

What I would like from this thread is artist and user feedback for each of the proposals and issues below. If something egregious has been forgotten or is not mentioned, please do so and I will try to compile/organize the feedback as best as possible.

Issue 1: Should the UV tile grid disappear as soon as an image is loaded in the UV editor space?
This behavior seems confusing and there’s been some feedback around it already which is noted below. However, addressing the issue has spawned further questions.

Motivation

Current patch

Artist feedback

Proposal: Move forward with D11860 as-is. It will do the following:

  • Allows the UDIM grid to be shown regardless of if images are loaded or not
  • Does not change any other aspect of the current design. See Issues 3 and 4 below for further considerations.

Issue 2: Should there be a way to disable the grid entirely? Should it be part of the Overlay settings and UI?
I believe this is a relatively straight-forward and uncontroversial issue to solve. The grid should be toggle-able on/off just like the 3D viewport grid AND it should respond to the overall Overlay toggle setting as well.

I believe it’s also a user expectation that the grid configuration live inside the Overlay popover instead of the N-panel; just like the 3D viewport grid controls.

Implementation and design considerations:

  • The grid has been drawn as an Overlay for some time now so it makes sense to have it better integrated with the Overlay settings and UI.

Current patch

Proposal: Move forward with D11862. It will do the following:

  • Move grid controls out from the N-Panel and into the Overlay popup menu
  • Adds ability to toggle just the grid on/off while keeping the other Overlays on
  • Adds ability for the grid to respond to the overall Overlay on/off toggle

Issue 3: The grid allows(requires) manual dimension adjustment, which can be annoying and unintuitive, after certain operations take place
How can the grid dimensions better serve the the user and artist? Does it need to change at all? Is there a better default like say 10x10 or 10x1 or something else? Should it just automatically adjust?

Motivation

  • If the user moves a UV island to some place where the grid is not drawn, the grid is not expanded to account for it (and vice versa). Requires user action to adjust the grid dimensions if desired (Julien’s feedback: https://developer.blender.org/D11860#319041)
  • If the user creates an Image tile outside of the current grid dimensions, it will “look” disconnected. Requires user action to adjust the grid dimensions if desired. (Jeroen’s feedback: https://developer.blender.org/D11860#318892)

On the one hand, some users appreciate the ability to define the grid dimensions however they see fit. On the other, some users may appreciate one less item to manage in their workflow.

There’s 4 primary options:

  • Do nothing. The grid remains as-is today. Users can move UV islands or add Image tiles outside the current grid dimensions. Manual adjustment is required if desired.
  • Toggle-able “automatic”. The grid’s dimensions will automatically expand/contract to account for newly added/moved/removed Image tiles or UV islands when enabled. Users can disable the toggle and manually configure themselves if required.
  • Always “automatic”. The grid’s dimensions will automatically expand/contract to account for newly added/moved/removed Image tiles or UV islands. No user manipulation is implemented.
  • Always draw the “full” grid.

Notes:

  • Non-tiled images are by definition a single grid cell. Automatic would do the right thing here and not draw the other grid cells etc.
  • The UDIM grid, per-spec, will never be more than 10 cells wide nor will it be negative in the X or Y dimensions. The implementation would continue to follow this convention even if the “automatic” options are built.

Implementation and design considerations:

  • If an “automatic” option is created, should the UDIM grid adjust during UV island movement; i.e. while the interactive modal operation is ongoing?
  • The decision here can be additive on top of Issue 1 but will require a way for the Overlay system to access the extents of all displayed UVs and image tiles.
  • The decision here will impact Issues 4 and 5 below

Feedback:

  • A full automatic implementation would interfere with folks purposely moving UVs outside the primary tile but not using UDIMs. Would like to keep it optional if this Issue is decided to be addressed.

Proposal: Currently no opinion. Need artist input and feedback.

Issue 4: Feedback required: Should the grid be shown in Paint/Mask/Viewer modes?
Right now the grid is restricted to UV Edit mode. That feels somewhat artificial. Technically the grid works “fine” in the other modes already. In fact, the grid will be shown in these modes when there are no images loaded (now and after Issue 1 is addressed). It does this so that the editor canvas is not completely blank on first use.

There’s a variety of things to consider here:

  • Is the Grid too distracting when painting?
    • Consider what it might look like if the decision for Issue 3 is to just draw the “full” grid all the time…
    • In any case, if the user can quickly toggle the grid on/off does this make a difference?
  • Should the grid be toggled on/off automatically when switching modes? Prior art: The Shading workspace has all its overlays disabled for example.

Implementation and design considerations:

  • Decision here can be additive after Issue 1 is addressed

Proposal: After Issue 2 is addressed, show the UDIM grid (as configured) in Paint mode as well. Do not show it inside the Mask/Viewer/Render result modes. No opinion around automatically toggling the grid display.

Example of what the grid looks like in Paint mode - I’ve scribbled a light-blue stroke between both tiles in 1 stroke below as an example:

example-paint
example-paint973Ă—842 206 KB

Issue 5: Feedback required: Should anything special be done when displaying non-square images?
Technically the grid also works “fine” for this as well. It just looks very, very weird of course.

There’s only 2 options really I think:

  • Do nothing. Continue to draw non-square grid tiles
  • Disable the grid when showing non-square grid tiles. That would mean the feature disappears when the user ends up in this state. Even if we become really good about placing a marker or other indicator in the UI that the grid is disabled because of this reason, is that for the best?

Considerations:

  • How annoying is it to look at such a grid in general?
  • How annoying would it be for a user to have to disable the grid when working with non-square images if they don’t like it?
  • If an “automatic” grid is built for Issue 3, would this eliminate the oddness? This assumes that non-square images are not very likely to be UDIMs which is probably correct.

Proposal: Currently no opinion. Need artist input and feedback.

13 Likes
2

Paging @JulienKaspar and @DanielBystedt for feedback and general FYI on this topic in case they have further thoughts and feedback.

3

Thanks for creating this thread! Much easier to talk about this on here.
I fully agree on issue 1 & 2. For issue 3 I only have one thing to add:
Not everyone is using a UDIM workflow. If you are creating UV maps for procedural workflows and purely use UV maps for raw vector coordinates, you don’t care about 1:1 UDIM grids.
So it does make sense to make this an optional feature. So users can choose to either use an automatically scaling UDIM grid overlay or the default 1:1 grid,
maybe even a truly endless grid that continues in all directions like the 3D viewport overlay.

On issue 4: I think the grid is too distracting when images are already displayed. Right now I don’t see a reason for the grid and images to be shown on top of each other.
This must also not be left to the user to decide by constantly toggling the overlays on/off between modes and editors. The overlay should be smart enough to be most useful in any context for the user.

5 Likes
4
  1. No. I want it to be visible.
  2. Yes. Overlay options for UDIM grid are a good idea.

Extending UDIM grid infinitely is not a bad idea also.

Solving UDIM grid visibility (issue 2) could be done with opacity slider inside overlays. It can give much granular control over the visibility than on/off switch.

3 Likes
5

As an overall feedback I’d prefer to have the UDIM grid always visible in any situation where we’re dealing with image textures (paint mode and image viewer too), no matter if there’s images loaded or not, with the option to enable/disable it just as with the overlays on the viewport, an opacity slider would be a nice thing to have too.

Another thing I find slow to work with is having to manually “fill” the UDIM tiles when I load a texture, just so that Blender can load the rest of the images. It feels counterintuitive and it doesn’t make sense if the “Detect UDIMS” option is enabled when loading textures.
I’d expect that checkbox to actually “detect” or find how many images I’m using and setup the UDIM grid accordingly.

2 Likes
6

Yes, that makes sense. I’ll make note of this scenario in the original post.

It sounds like there’s a point of contention here. I’ll provide an example above of what Paint mode looks like with a modified version of the Monster demo file so you both can see the grid in that context. Nothing too surprising.

I’m hesitant to add it to the normal image viewer. The overlay settings are shared across the modes which means if you have a 10x5 grid configured while UV editing, if you display a “normal” image, that same 10x5 grid will still be used. And because that normal image is most likely going to be a non-square aspect ratio, that leads to Issue 5. If you were a typical user, and this happens, would you file a bug?

1 Like
7

Hey folks, a quick update here.

Item 1 has been addressed but item 2 is still outstanding and needs a bit more feedback now that some pieces of GSoC 2021 have landed and from some feedback I’ve received on the review.

  • What do folks think about having another option which provides additional control over the background? It allows seeing the general tile outlines, but not the grid lines.
  • Does the following layout make sense?

Here’s a practical example of what’s being discussed:

4 Likes
8

As someone who work on texture department and exclusively use Blender for two plus years, for me the important part of it is the visibility of UDIM borders and the UV map on the texture editor. I don’t see any case of texturing that require the UDIM grid so far, i don’t know i will need it in the future either. Maybe useful for someone who work on Pixel art? Or just simply OCD? I don’t know… For me it would be way too distracting to see. So the option to disable or manipulate the grid’s visual is a must. Deadpin’s proposal is great, however i think without the “custom” grid option is fine, because we can always change the visual when “grid” enabled.

For the record Maya has it, and it’s annoying. And the only way to disable it is also disabled the UDIM borders.

9

I do have issues with Blender not saving all the UDIM tiles in the .blend file when using “Pack Resources” to contain all the images. Is this supported with the UDIM tiles?

10

Right now UDIMs do not support packing. It is a separate TODO that’s unrelated to the grid topic here but I do plan on looking into it after I land a few other UDIM related items first.

2 Likes