[Bf-committers] Texture painting considerations (preparations for bratwurst merge)

[Antony Riakiotakis]

Hi, time is near when I will have to clean up my GSOC code before
hopefully inclusion to trunk.

Part of my work was to port rake style brushes to texpture paint and
unification of cursor display for sculpt texture paint.

In fact, I think it is a good chance to address the issue of unifying
the brush related code more. For instance sculpt paint uses texture
sample functions very similar to texture paint. Some code may be
deduplicated there, and this will make it easier to support more new
brush functionality across every paint mode as it becomes available.

Furthermore, there's also the matter of the one paint structure for
two texture paint functionalities (2D and 3D). This becomes an issue
because we currently check the mapping mode of the brush to decide
whether it is valid to set rake mode. However, 3D mappings do not hold
in 2D and vice versa. This can be either solved by having separate
structures for 2D/3D paint, or enforcing the right modes for the 3D
case if rake for the 2D case is chosen. Another solution is to make
rake a new mapping of its own.

Yet another issue with texture paint is the quasi interleaved code
between 2D/3D paint. It can make code a bit difficult to undestand at
times. There are functions where the same variable can hold
coordinates in different spaces depending on 2D/3D and i don't think
this is very good.

Finally there's the very important issue of projective texture paint
performance. I was thinking of maybe integrating PBVH to texture paint
(needed for a few more features, such as proper lock brush support,
and mirrored textured paint) and I wanted some opinions on whether
this would help or not.