Is uv tools branch needed/wanted in trunk?

Hi everyone, in today’s developer meeting there has been a discussion on the uv-tools branch from this GSOC. I am reminding the features that the branch includes:

-Support for high bit depth float textures in the viewport (useful to get more detail when painting bump maps or more precision in GLSL color operations)
-Subsurf Unwrapping (Unwrap the mesh as if it was subsurfed)
-Smart Stitch operator. (stitch now has a preview and automatic snapping/rotation of islands)
-mark seams in uv editor
-seams from islands operator in uv menu of the uv editor
-uv sculpting which allows you to relax and pinch uvs locally (activate through the uv sculpt checkbox in uv menu). This is especially controversial and reviewers are against it.
-there were some weight exporting operators too but they got rejected because they were not implemented as bake operations.

I was asked 2 things to get the tools included:
1st) Do artists really need them?
2nd) Can artists test them?

If you are interested in getting the tools to trunk, please post here and test the tools. Thanks!

Documentation: (Not completely up to date right now but will fix asap)


build for windows:

(Will post for linux too soon)

Uploading version 43223 right now, if link is older please wait for a while efore testing. Thanks again!

i dont know if its part of of “uv tools” but vpaint needs to get some attention
and some work done on it.

I haven’t tested the tools yet, but they all seem really useful to me. I’m actually surprised there’s a discussion on this (especially the UV sculpting; why the negative reviews?). I’ll be giving the build a test spin soon if I can find the time, but you have my vote to get it in!


This would be absolutely useful. Even if later needs refining by hand painting, would help the workflow greatly.

Subsurfed mesh uv mapping tools, smart stitch, whatever tool to relax uvs, would be great, too…

I think the new tools give blender a great benefit. Please merge it into trunk :-

there’s only one thought repeating in my mind right about now:

This is my first post here so i say, sure we do!

Definitely needed!

I can see everything in this list being very useful!

Why are the reviewers against it? I’m really curious… anyone who works frequently with UVs can clearly see how useful these features are.

Absolutely, yes! Of course!

I second that question, why was there a gsoc project to begin with if this wasn’t clear?

Again, Yes please! And thank you for all your work on it Psy-Fi. I imagine you might be feeling gutted with the situation… :\

Do we need them?!?!?!

Of course we do! UV Editor is the most abandoned part of Blender… :expressionless:

This must be a joke. Hidden camera anywhere in cyber space? :confused:

Definitely needed, of course.

I need this! Blender needs this! I have been following the project since summer so please get this into trunk!

Actually, I think texture paint is :slight_smile:

But yeah, it’s incredible they’re even asking. Your tools are awesome, Psy-Fi. Many thanks for your hard work!

The whole story is a bit complicated: As many of you remember, the branch was part of this GSOC. My original proposals for GSOC were GPU based texture painting and automatic seams (the project coded by Shuvro Sarker). Before being accepted into GSOC, my mentor LetterRip asked me if I wanted to do community requested features instead. He mailed me a list with features requested (I think there was even a thread here about that), I saw them, thought about if/how I could do them and I accepted. So far so good. However…it turns out that the list had not been discussed with the core developers (Ton, Campbell, Brecht and Sergey). So after GSOC had finished and after the torrent of high priority merges ended (cycles, camera tracking etc) the developers finally found time to do a review on the code which can be found here:

Quoting brecht’s comment on uv scultping: “I’m not convinced UV sculpt is a feature we should have in trunk, it seems overkill… Grab is like proportional editing, and instead of Pinch/Relax minimize stretch is more useful. The sculpt falloff curve is also too much, UV editing isn’t really an artistic thing, it’s a matter of getting the textures mapped with minimal stretching. This seems a step too far to me.”

And of course he has a point. The thing is, do artists prefer to use a brush, or select and use operator? This thread was made to get feedback on these issues too. So far i have deleted the grab tool from the brushes (I think it was the least useful).

After seeing remarks on the usefulness of the features, I sent some emails to brecht and LetterRip because obviously there was some miscommunication going on. I was asked to code features whose usefulness was debated. I think the main issue is that blender is becoming too large to manage codewise and understandably developers want to avoid cluttering the code with unused stuff. Today there were also objections on the basis that the tools were untested. And they are as far as I know. Only a couple of people have given feedback so far(And I found some really evil bugs this way). By the way I’d like to stress that though I did code the tools I have no feelings of indignation or anything, nor did this thread start with a “Put my code in blender” attitude. There are valid considerations to satisfy both artistic and programmartistic :).

The state of the tools can be considered final*. The smart stitch tool needs a few more adjustments, especially for rotation of islands when snapping but it’s mostly ready. I will update the documentation now to reflect the latest changes.

I have one more request to make. Can someone post a build on graphicall? My internet upload speed sucks and I’ve been repeatedly trying unsuccessfully to upload a build for about 4 hours.

<Edit> *final if there are no problems found, that is :slight_smile:

Also a big THANK YOU for your kind words!

I have no idea on how the code work, but couldn’t those gsoc proposals be made as addons you can enable/disable, or is there a need for them to be merged in the main code ?
If they were addon, their usage or not would then be left to the user and it would then not bloat and clutter the code if they could be disabled too ? as i have read in another thread some of the developer fearing that it was starting to be the case for the current development.

Anyways, there’s always the saying that every options and feature can be usefull to at least 1 person in the world, so they’re never a waste of time, we simple users are always glad and thankfull for your time when we use those special builds :wink:

I think that threads like this are a good idea, i can see it’s getting too big. someone who doesn’t understand than; look at any source file, and think of the ammount of files like that one exist.

but i realy think this would be an improvement as uv unwrapping is realy tedious.

And of course he has a point. The thing is, do artists prefer to use a brush, or select and use operator? This thread was made to get feedback on these issues too. So far i have deleted the grab tool from the brushes (I think it was the least useful).

Your sculpt implementation is way more versatile and pleaseant to work with. Why can’t both ways coexist? Imho, it doesn’t really seem like an overkill… what it looks like it, is that Bretch doesn’t work with UV maps too often…

Well, I don’t see how they would detract from the Blender experience. FOSS is all about choice and customizability, and Blender is certainly no exception. I say throw them in there. If people want to use them, they’ll use them, and if they want to stick with the current UV tools, then let them.

In essence, it reminds me a little bit of an Ortega Taco commercial, frequently quoted as “Why not both?”

So, yes. Throw them in. It certainly won’t hurt anything, and it could do a great deal toward improving Blender.