利用者:SaphireS/gsoc2016/proposal

Blender GSOC Proposal "UV Tools"

Possible mentors: Bastien Montagne, Campbell Barton, Howard Trickey

Synopsis

As someone who uses Blender as his main tool on a daily basis I know just how cabable Blenders UV Editor is ...But I also know about its shortcomings and areas for improvement regarding the current tool­set. In this project I aim to improve the UV Editing workflow by improving the current tools as well as adding new ones. Improvements to a UV tool could mean enhancing its features, working on usability or both of course.

This project consists of a few smaller and encapsulated goals and because of that has a higher chance of success, since an unexpected problem during development of one feature doesn’t affect the other goals. For a detailed list of goals of this project see Project Details.

Benefits

Blender users would be presented with an improved UV unwrapping/editing workflow, which makes tedious tasks easier to accomplish. Users would be presented with a more consistent toolset since some tools that exist in 3D View would also be available in the UV/Image editor.

Improvements to existing tools would save artists lots of manual reworking, which is often necessary with the results of the current Pack Islands and Unwrap algorithms. Tools that exist as Python scripts could be integrated natively and sped up a significant amount.

Deliverables

This project would include multiple smaller improvements to existing tools as well as some new features:

Original Goals:

• Improvements to packing
  done
   
• Ability to separate UVs with a UV­rip tool
  on hold
    (update-> exists as a python script, so will be done after gsoc)
• Shortest Path selection (matching the mesh tool)
  done
   
• Copy/Paste between UV layers
  on hold
    (update-> Turns out there's a python addon for that, moved to post-gsoc period)
• Enable hiding of elements in the UV editor
  done
   
• UI/UX improvements for UV editor
  done
   
• Possible conversion of useful python addons into native tools
  done
   

New Goals:

• Optional packing after unwrapping
  done
   
• Scale to bounds/Normalize UVs operator
  done
   
• Improve incremental snapping
  done
   
• Detect overlapping UVs
  done
   
• Calculate used space (in %)
  done
   

Of course the deliverables would not only consist of the implementation of these features alone, but also to provide documentation both on end­user level (how to use the tools?) as well as developer documentation (how does the tool work and how is it implemented?).

Project Details

• Improvements to packing: Improve Blenders packing algorithm(UVs ­> Pack Islands), which currently doesnt work well in many cases. Often referred to under the term “geometric bin­packing problem”, this research area focuses on generating an efficient UV layout with as little wasted UV space as possible. Since deterministic solutions to this problem tend to be NP­hard (meaning exponential computation time) an approximation using heuristics (eg simulated annealing, genetic algorithms) would be the best way to go for finding a near optimal solution. The ideal algorithm/implementation should have support for the following features:
  • Make sure the whole UV space is used efficiently, the algorithm should ideally be aware of holes and place smaller UV islands inside them, work well with interlocking uv islands. For this subtask the algorithm should work with the exact outlines of the UV islands and not with the bounding rectangle, as is currently the case. User should be able to set Bleed/Gutter/Margin size.
  • Add the ability to group existing islands so they are packed together, support pinning (pinning > grouping > packing > Average Islands Scale)
  • Overlapping UV islands should stay overlapping/grouped (for sharing part of a texture)
  • Detection of circle­like islands and not rotating them (could pose trouble for artists) ­> This could be solved with pinning, but better usability would be if the algorithm takes care of this.

For this deliverable it would make sense to expand research to the sheet metal/laser cutting and sewing industry since these deal with packing problems all the time. As an example for features to target the software IPackThat (standalone UV packer) could serve as inspiration. Since the LSCM Unwrap operater internally also uses the packing operator the user would get an improved UV layout without explicitly calling Pack Islands operator. Further reading:

• • Two­dimensional Packing utilising Evolutionary Algorithms and other Meta­Heuristic Methods
  • A SCANLINE­BASED ALGORITHM FOR THE 2D FREE­FORM BIN PACKING PROBLEM
  • An effective heuristic for the two­dimensional irregular bin packing problem
  • Least Squares Conformal Maps for Automatic Texture Atlas Generation (This paper has a great chapter about bin­packing)
  • Campbell: SaphireS, so worth checking on some fast bitmap method too. Fill in used areas as a 1bit image, then store mipmaps for fast detection if enough cells are free... since for UV's your typically working with pixel data so calculating overlap with pixels could be OK

• Ability to separate UVs with a UV­Rip tool: Implement a tool that works similar to the Rip tool already present for meshes in 3D View (Edit Mode, “V”), only in Image Editor, operating on UVs. While one could argue that this is what seams are for, this tool would operate on UV islands after they’ve been unwrapped, while seams require a new unwrap.

• Path selection: Implement a selection tool for UV Editor that works similar to Select ­> Shortest Path in 3D View.

• Copy/Paste UV Layers: Enable Copy/Paste of UV Layouts between Meshes with similar topology. There are some Python scripts out there which could be used as a guide:
  • Scripts/UV/Copy_Paste_UVs
  • Scripts/Mesh/Copy_Paste_UVs

• Average Island Scale: Add “selected to active” functionality, support pinning.

• Enable hiding of elements in the UV editor without altering the mesh selection state/3D view visibility.

• UI/UX improvements: Various smaller improvements to user interface and usability of the UV/Image Editor and its tools. Paweł Łyczkowski pointed me to some mockups/proposals regarding this: First, Second Since these are just UI changes I’d implement them in my branch and then do lots of user testing and comparing them to trunk, evaluating if these are feasible to be included in trunk.

• Convert useful addons to native tools: This is more of a bonus task if everything works out fine and there’s still time left. I’ll look at popular UV editor python addons and convert them to C code. It’s still possible for the community to suggest addons for this task, feel free to let me know on IRC or via mailing list. Possible ideas can be found here: Extensions:2.6/Py/Scripts/UV

Project Schedule

• 25. March: I’m already reading relevant parts of the code and getting familiar with it, planning on how to best implement the features which don’t require extensive research (like Path select or the Rip UVs tool). Already talking with mentors about/reading relevant papers/articles and how to design new features/tools.
• 22. April: If accepted I’d immediately start with researching unwrapping/packing algorithms by reading whitepapers and scientific articles. Start doing prototype implementations of new tools, create wiki pages for documentation.
• 23. May: Official start of the working period. Since I’d start research/coding way sooner it doesn’t make that big of a difference for me, however design and research for new tools should be mostly done by now so I can work on the actual implementation.
• 15. June: Start preparing midterm evaluation.
• 20. ­- 27. June: Submit Midterm evaluation.
• 28. June: Second working period, finishing the implementation of new tools and new features to existing tools. Start writing documentation.
• 1. -­ 15. August: Time buffer to fix unexpected problems, deal with scope changes that were created during research or implementation of certain features. Get power users to test new tools and work on bugs.
• 15. -­ 23. August: Tidy code, improve/finalize documentation and submit code to Google.

Bio

My name is Phil Gosch, I'm a student of Graz University of Technology (Austria) and I'm a long time Blender user and active member of the Blender community. Besides university I'm working as a 3D/Technical Artist freelancer, where I'm mostly doing illustrations, visualizations including custom tool development and gameart/gamedev. You can have a look at my 3D art portfolio at my homepage , Artstation or at my Blender Network profile.

Areas I’m interested in is pretty much everything related to 3D graphics, ranging from realtime 3D (OpenGL, etc.) to “offline” raytracing and all the tools associated with it. My bachelors project was writing a software to load and display 3D meshes of (knee) cartilage and perform thickness analysis calculations on it to find areas of degenerate tissue, using C++/OpenGL/Qt/Cmake. Of course I have a few projects I’m working on in my free time like a simple raytracer in C++. Currently I’m developing AI systems for a local gamedev company in Unity/C#.

Since Blender is my main tool and I use it on a daily basis I know the UV Editor (and its shortcomings) and because of that fact I not only think I'm fitting for this project but I also have a great personal interest in improving these tools. I'm no complete stranger to Blender core coding, I already had some of my patches applied to trunk a few years ago, mostly bugfixes and smaller features.

I regularly compile the newest Blender version, I’ve been reading the Blender mailing lists for many years and I’m generally very interested in new Blender developments, both from a users and coders perspective.

Because of my connection to the Blender community and my general interest in Blender coding I’d stay around after GSOC has ended, not only for bugfixing and maintenance but to keep on working in that area (UV tools + related).