I think as part of that , it seems you would be working on unifying the Texture UI for both Cycles, Internal and the access to the Image as Texture for painting on and painting with. I’d like to help with input if I can.
More for blender internal currently, and more on the painting on part (the painting with part has been largely tackled in recent svn versions with a great patch by Bastien Montagne).
And yes, feedback is very welcome.
However, to keep the feedback constructive, some pointers on the feedback from now on:
-
Keep it focused: Say how you think the workflow for a certain tool would ideally work for you. Present constructive use cases for a tool. Situations where a tool could become cumbersome to use or conflicts with use of other tools are also very welcome feedback.
-
On feature requests: It’s OK to comment on workflow, and how a feature would work with a specific tool if it is to be implemented in the future (so that can be taken into consideration), but understand that the feature set that will be implemented is difficult to change from what has been proposed unless really convincing arguments and ease of implementation are guaranteed
Minor to medium scale alterations on the proposed set are more likely of course.
Layers, for instance would take too long to implement.
there is already some work put into layers for texture painting:
However the project looks slightly abandoned. The dev started working on other things. It’s currently too laggy (needs to be optimised) and cant export. Maybe if we donate he will work on it some more?
needs 800 euros more to get it funded to export.
Having this code merged with trunk is questionable. I certainly hope it does, but there have been so many other great things that never made it or took them years to get in.
About auto UV:
This is one of my crazy idea to make UV fast for painting.
Mark all seam, unwrap everything, paint.
The current problem that I face are
a. there is no way to tighten the UV to save space, islands are too spread
b. islands are usually stretched to either direction if square image is used.
I have seen very nice implementation of the same concept done in Sculptris.
Islands are packed into groups of verts, they are rotated to fill minimum space.
Instead of individual face like above, there must be a way to auto UV to group of islands.
@BWK, what is smart-uv-project not doing for you?
Light BWK, what your describing sounds exactly what PTex is for. A PTex implementation that can bake to another set of UVs would be a great and compatible workflow (PTex support accross the whole system, cycles included would be even better). Unfortunately that’s likely WAY too big in scope for this summer, I’d imagine.
This may be out-of-scope, but I thought I would bring it up anyway, just in case. 
A very popular (in film) workflow for texture painting is to set up your UVs into tiles. One UV set, but the UV set has the UVs spread out across UV space to populate several 1:1 tiles (see the example image I’m attaching).
Once you have these tiles set up, the texture painting system (mudbox, mari and I think zbrush all support this) will assign an individual texture to each tile. You paint, then export the maps to your cg package (like maya, for example).
Once in maya, a shader is set up that uses one shader, but splits the texture assignment to match each texture tile with it’s mathcing UV tile (usually automated with a script). The textures are non-repeating and only fill the UV space they are assigned to.
This allows for HUGE texture sets that it broken up into smaller chunks and is a great workflow if the tools support it.
Blender Internal is already technically cabable of doing this, I believe. You can layer textures onto a single material and isolate each texture to only its designated UV space. Not sure about Cycles yet, I haven’t tried it.
But while Blender is capable, the workflow is too cumbersome and manual. Not to mention I’m not sure the blender viewport would support such a painting workflow.
Thoughts?
This would be a nice-to-have in my book, but not essential.
It used to be pretty important in the olden days because you just couldn’t comfortably work with large images in 2d image editors like Photoshop.
Nowadays most workstations don’t even hiccup when you throw 16k textures at them.
It’s true though that often UV maps just don’t seem to fit well into squares. In such cases I just use rectangular maps. AFAIK GPU hardware doesn’t actually care if the textures are square, just as long as both sides are PoT, and if you’re texturing for offline CPU it doesn’t matter at all.
My workstation would choke at 16k textures, and it’s middle-of-the-road in terms of performance. Blender certainly can’t comfortably paint at that res. Maybe I’m doing it wrong, but blender’s painting performance nose-dives even at 4k.
And unless GPUs have changed radically over the last few years, GPUs care massively about power of 2 textures. Non square is fine if you are rendering on CPU, but not if your painting on the GPU (again, I could be wrong, I haven’t researched it lately).
But yes, I agree, this would be “nice to have”. It’s a very established and preferred painting workflow for most studios (with good reason), and it would be great if Blender’s paint tools could fit into that workflow.
Oh, I meant 16k in 2d editors (like Photoshop), not in Blender. Yeah, painting at that res in the viewport would probably be impossible, I never really tried.
And yes, GPUs care about PoT, but work just as well with, say, 4096x512.
I was under the impression that power of 2 textures just mean the sides need to be a power of two, not necessarily square. For example, 512 x 256 is fine; 500 x 250 is not. Is that not the case?
Yes, non-squared textures are fine, there’s no problem with 1024x512 by example as both side are power of two
1000x512 is not good, 1000 is not power of two, while Blender can display them some game engines may even crash when non power of two is used.
The main reason why I tried the ptex like per face workflow is mainly because of this problem I found.
UV unwrapping with smart UV, when painted, always leaves a gap that seem to be unfix-able.
The mark all seams, ptex like workflow is the only way to do it without those gaps, AFAIK.
Sorry guys, brain dumping. XD
Does this mean we’ll finally be able to paint symmetrically without the fear of the Undo command corrupting the paint? I opened a bug report for that a while ago and it was closed because apparently it’s too tough to fix…
Also, any chance of additional work being done to the Paint Layers addon? Like the ability to merge layers or OpenRaster (to compensate for the lack of PSD) support?
A few quick answers here:
As I said before no layers will be done for this GSOC. The feature set is…well…set for now. No ptex and UV stuff either though I do have a few uv projects on the side and I do actually have a copy of the ptex patch in my hard drive waiting for love and attention. Not for GSOC though. This project is huge already.
On the matter of tools:
There are currently two feature commits in the branch already:
One is for having a secondary colour in the colour palette, which can be used with Ctrl-LClick. X button swaps between the two colours and Shift-S samples for the background colour (this last one is bound to change though because it conflicts with smooth stroke shortcuts). I was thinking using this for gradient effects, but then I thought that it might be better to use a colour ramp for those, which will be quite more powerful, and also that it may be nice for artists to have a full colour palette maybe? How would you envision the use of colour palettes?
Feature two, a minor refactor: set a “material” draw mode in blender internal, similar to how cycles works, which is actually the same as GLSL textured mode. Not important or new but done as part of streamlining texture setup.
I’m a big fan of color palettes that are just small images in the corner of your screen you can paint on, save or load from your hdd.
I am already satisfied by Paint Palettes add-on to create and use colour palettes.
http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Paint/Palettes
Maybe you can add some stuff like ability to load palette from other software and shortcuts to sample color.
Bleh, took me like 3 hours to figure out how to get Blender to build on Windows, and I still only managed 32-bit without Cycles. One day hopefully Windows will become as user friendly as Linux. (I’m kidding, Windows users) 
Anyway, dual colors work really nice for bump painting. Basically can work like sculpt, with paint = add, ctrl+paint = subtract. Blend file setup if anyone wants to try it out (need a GSoC Paint build).
Some feature requests disguised as feedback:
- Right now each brush preset has it’s own colors. So if I’m using one brush, set my colors, then switch to a soft brush, I have to reset the colors. I think the colors should be a global setting that is just shared between the brush presets.
- Another nice to have would be more blend modes. In particular color or hue. They can be used to recolor things without destroying detail. Example
- When color picking with small brushes it’s really easy to color pick the actual brush circle. I don’t really know what to suggest on how to fix that.
I’m not really sure what the best way to handle a color palette would be. Maybe just a button next to the colors, that “save color to swatch” and just have a panel with color swatches?
Even with the palette addon, the ui is not so easy to use because of the location in the shelf. Color palette should be right there under the color picking area, so you can see it and pick quickly.
xrg, that picture is already cool enough to use as document for the feature 
Color palette, do it like artrage
Maybe this is too big and tall for comfort.
But the PLUS button is a big welcome.