Page MenuHome

UDIM: Show the UV grid even when images are loaded
ClosedPublic

Authored by Jesse Yurkovich (deadpin) on Jul 9 2021, 6:06 AM.
Tags
  • Restricted Project
Subscribers
None
Tokens
"Burninate" token, awarded by AlexeyAdamitsky."Love" token, awarded by silex."Love" token, awarded by hitrpr."Love" token, awarded by gilberto_rodrigues."Love" token, awarded by riouxr.

Details

Summary

Allow the UDIM grid to be shown and adjusted when there are images
loaded in UV edit mode. Right now the grid feature disappears once an
image is loaded and many have found this to be confusing.

Based on community and artist feedback, there was support to change this
behavior[1]

This patch does the following:

  • Allows the grid to be shown even when images are present
  • The max allowable dimensions for the grid has been increased from 10x10 to 10x100 to match the underlying maximum UDIM range that blender supports

Note: This should not affect other Image editor modes like Paint/Mask or
the Render Result viewer etc. Future work in this area is currently
documented in a dedicated design task[2]

[1] https://devtalk.blender.org/t/the-udim-tile-grid-design-and-feedback-thread/20136
[2] https://developer.blender.org/T90913

No images - master:

Loading images - master:

Loading images - this patch:

Diff Detail

Repository
rB Blender

Event Timeline

Jesse Yurkovich (deadpin) requested review of this revision.Jul 9 2021, 6:06 AM
Jesse Yurkovich (deadpin) created this revision.
Jesse Yurkovich (deadpin) added a project: Restricted Project.
Jeroen Bakker (jbakker) requested changes to this revision.Aug 9 2021, 11:20 AM

Coloring of the background is different than in master. This is also the case for other images.

release/scripts/startup/bl_ui/space_image.py
1456

This always evaluates to True, no need to have a poll method.

This revision now requires changes to proceed.Aug 9 2021, 11:20 AM

@Jeroen Bakker (jbakker) Ah, that's from the section that I removed from OVERLAY_grid_cache_init; I didn't realize it was used for the background like that. I may need some help/hints now then.

That opaque background quad draws over the images, defeating the purpose of this patch. I have not been able to get it not to do that. I'm a first-time RenderDoc user here and all I've been able to determine is that these overlays are drawn after the pass that draws all the images - which makes sense - but this particular background quad shader doesn't have any configurable parameters to do a proper depth test(?) and so isn't very nice as an "overlay".

Is there are set of opengl draw states I can use or does the background need to be split into a separate pass/shader that occurs before image drawing?

Attempt to fix the grid background by adding using a new shader; an odd
render window outlines remains.

I added back in the removed code but I could not get any of the existing fragment shaders to do what I needed so I had to make another one. This seems to work but now leaves a weird 1 pixel border around the render window's output:

Not really sure why that might be the case.

Addressed other piece of feedback

Jeroen Bakker (jbakker) requested changes to this revision.Aug 16 2021, 11:16 AM
Jeroen Bakker (jbakker) added inline comments.
source/blender/draw/engines/overlay/overlay_grid.c
225

Optional passes should be set to NULL when not used.

226

I don't see the need to add a new shader or attach the depth buffer. Use DRW_STATE_DEPTH_* and OVERLAY_shader_grid_image.

Perhaps the matrix should be modified so the depth of the quad would be correct.

This revision now requires changes to proceed.Aug 16 2021, 11:16 AM
source/blender/draw/engines/overlay/overlay_grid.c
226

Ignore previous comment. it uses the same approach as overlay_background/overlay_grid.

Alright, I needed to backtrack a bit after further testing but this should work better and it changes fewer things from the current design

  • The separate pass I added is not needed since it won't be using different draw states now
  • Added the UDIM grid poll method back as I think the best thing is to keep the grid control and display exclusive to UV edit mode for now. Showing the grid in the other modes (paint/mask/view) becomes weird when there are non-square images being shown (typical) and it may be too cumbersome if the user needs to continually adjust the grid when inside those views in general. It can easily be added to these modes, and limited to just tiled images perhaps, in the future if required.
  • Ensure grid is drawn with correct dimensions in all the modes now

Although this works, it seems that the functionality isn't clear to the end user.
An image can have a UDIM Grid, but can add tiles outside this grid (this was always the case, but at that point the grid wasn't shown anymore). I do think that showing the UDIM grid would need more design

  • When does the user want to see the grid?
  • What happens when the user adds a tile outside the grid?

Best way to move forward is to collect feedback from users and steer the patch in that direction.
Think it is good to involve @Julien Kaspar (JulienKaspar) to give a well thought out idea.

I think as a quick fix for the overlay this goes in the right direction. This is useful for:

  • Showing and using the Grid on UDIM tiles that are still missing or not using any images. This also highlights the disconnect between the UV Grids and UDIM image tiles.
  • Showing the boundary of each UDIM tile even when images are used. This can also be really useful when when "Repeat Image" is toggled on

For that alone I think this is worth committing.

This goes a bit out of topic but I think in the long-term it would be best if the Grid is less static but automatically extends whenever a UV island exceeds the original 1:1 space and moves to another tile.
This would make it visually obvious when the UVs are (intentional or unintentionally) going out of bounds.
It would also make the Grid automatically correct itself for every individual UV map instead of having it as a global setting. Each UV map can have a different UDIM count after all.

Based on the feedback I've received so far on the DevTalk thread, there seems like good consensus for following through with this current patch as-is right now. The design task will track the other issues we've come up with so far(no strong consensus for some of the other topics yet). Is there anything else you'd like me to do or check?

I will go over it one more time. Would be good to update the description of this change as that is normally the base for the commit message.

This revision is now accepted and ready to land.Sep 3 2021, 10:17 AM