GSOC 2016 - UV Tools

Hey everybody! :slight_smile:

I’ll be working on the UV Tools for Google Summer of Code, you can find my proposal here:

https://wiki.blender.org/index.php/User:SaphireS/gsoc2016/proposal

Besides adding smaller tools and improvements I’ll try to improve the UV packing algorithm (“Pack Islands”) to achieve a much better automatic usage of available UV space. Currently all the islands use a rectangular bounding box, which makes “interlocking” of parts not possible and wastes space.

I’m currently researching 2D bin-packing algorithms for this task, but haven’t found a really awesome algorithm yet, so if anybody happens to know a paper I should definitely take a look at, I’d be very thankful for that information! :slight_smile:

I’ll use this thread to post progress and gather feedback from testers.

Looking forward to working on this!

Maybe you can look at that :wink:

Thanks for the tipp, but I even mention IPackThat in my proposal. :wink:
Maybe I should just ask the creator if he could suggest some papers. :slight_smile:
I’ve read somewhere that he did extensive research in the fields of laser cutting/sewing etc. since these deal with bin-packing problems all the time.

Glad to see you start a thread here! I’ve read through your proposal and I like what I’m seeing.
Like Pitiwazou, I’m excited for the improved packing (although not that excited that I’d post before reading :P), and improved selection tools would be a godsent.

In addition to the ‘selected to active’ option in the Average Islands Scale, would it be possible to add the ability to set a texel size? In videogames, level artists often adhere to a set pixel/meter-ratio, like 'this 1mx1m plane will have 256x256 pixels mapped.

This video might prove useful to explain the concept more: https://www.youtube.com/watch?v=aJiKZhGK73s

If you make testbuilds, be sure to post them here and I’ll be glad to test them!

Are you also leaning towards a UDIM work flow? Or to deep for gsoc?
rock on brother (¤¿¤)

For udim in the uv’s editor we only need a grid with uv’s spaces.
And for Cycles a node.

EXCELLENT news! So glad to hear that the UV editor will be getting some love.

There would be quite a bit more involved with getting UDIM properly integrated. We would need a way for each (X, Y) tile of the UV layout to have its own resolution to properly integrate with the texture painting tools, which very much goes against the existing paradigm of Blender’s UV editor. We would also need a way to set the active UV space/UDIM tile for editing if you wanted to use any of the averaging/packing tools alongside it. Also, I haven’t looked into it, but I’d imagine that the tex painting code would have to be altered quite a bit as well to play nicely with drawing to several different textures of varying resolutions at once. On the plus side, this area of code would lend itself well to multi-texture PBR painting a-la Substance Painter. And on top of all that, there’s the (simpler) matter of creating a function to take all of the tile data and spit out meaningful maps from it.

On the render side, there needs to be some smarter methods for filtering across tiles of different resolution for it to be a “battle-ready” UDIM implementation.

That’s not to say that any of it is impossible, but it may be a bit much to chew on for a GSoC.

Thanks for the link lijenstina, added it to my list. But be aware that it’s an optional target for this gsoc project.

Are you also leaning towards a UDIM work flow? Or to deep for gsoc?

Initially I had UDIM evaluation and maybe initial code in my proposal, but I was adviced (by Campbell and a few others) to remove it, because it’s waaay beyond the scope of a gsoc project. As Matt already mentioned, it’s not only …

For udim in the uv’s editor we only need a grid with uv’s spaces.
And for Cycles a node.

…but way more complicated. “Only” adding the ability to edit UDIM with the UV editor is already quite a big task and then it has to be properly integrated with texture painting, baking, etc. as Matt elaborated. Not to mention, Cycles UDIM support is another big task.

Yes you’re right it’s not so easy.
For now, I use a grid map with “repeat coordinate” and a node in cycles and it’s ok, but all the blender tools need to be modified to work for UDIM.

Definitely, I’d love to see UDIM support in Blender/Cycles myself! And it definitely should be possible, just not during this gsoc project. :wink:

Very nice! I would like to put some ideas too :slight_smile:

  • unwrap without packing (kind of maya unfold)
  • unwrap selection (without packing)
  • unwrap in direction (horizontally, vertically)

Good luck and cross fingers you can make all your proposed changes.

Great news! Current packing algorithm waste too much space.

Islands Group feature would be awesome. When creating textures for games its good to have island grouped by material types. Possible way to achieve that is to threat multiple islands as one big island while packing. Proposed workflow:

  1. User make seams and Unwrap mesh to islands.
  2. Selected islands are mapped manually or by using new Packing algorithm. Then user assign them to new or existing group.
  3. User run packing with option “Use Islands Groups”. Group are threated as one big island while packing.

Some kind of convex-hull-like algorithm will be needed to compute bounds of those groups. Question is how to deal with islands that was merged from two different groups. If group data will be stored per vertex we can detect vertices counts and decide to which group it belong.

Thanks a lot for the workflow and mockup Monio! Some kind of grouping is planned but since it depends on the packing algorithm the details aren’t sure, so this is definitely helpful!

  • unwrap without packing (kind of maya unfold)
  • unwrap selection (without packing)
  • unwrap in direction (horizontally, vertically)

Just calling the unwrap operator without packing would be pretty easy to accomplish. Can you elaborate what “unwrap in direction” means?

Thanks. I offer my time to test early builds and give feedback. Your GSoC project is wonderful. I often found myself splitting my islands to rectangular shapes just to counterbalance current poor packing algorithm, that’s waste of mesh vertices and texture space.

Look at how headus UVLayout works. Things like being able to straighten uv sections, and most important the pelt tools. That would make me jump with joy if you could get these working in Blender.

Blenders LSCM unfolding method gives comparable or better results and is waaaaaay faster than Pelt Tool from Headus UVLayout. There is reason why most of programs adopted LSCM or similar algorithms. UVLayout utilize very old technology. LSCM can work in realtime on medium density meshes, this give us live unwrap. You can’t achieve that with Headus algorithm.

Hi.
Far from being an expert in UV map here. I just wanted to know if this project will improve in some way the Smart UV project in meshes with triangles, such as those obtained with Dyntopo sculpt.

I won’t be developing an alternative to the LSCM Unwrap algorithm blender uses for unwrapping. There’s a student from ETH Zurich who will be implementing a new unwrapping algorithm his department developed, you can read about it here: https://lists.blender.org/pipermail/bf-committers/2016-March/047144.html

Things like being able to straighten uv sections,…

There’s a straighten tool in Blender, how does the one from Headus behave differently?

I just wanted to know if this project will improve in some way the Smart UV project in meshes with triangles, such as those obtained with Dyntopo sculpt.

How exactly should they be improved? There’s not much any unwrapping algorithm can do if the topology is a mess. :wink:

Hi SaphireS,

This video should show what i mean. Headus maybe old but it’s what most of the devs ive worked with use just because it’s so fast and gives such great results.

The straighten tool, completely flattens then allows to reshape using the contours of the surface. Very cool.