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

Brecht Van Lommel brechtvanlommel at pandora.be
Mon Oct 29 16:10:12 CET 2012


There's others who know more about the sculpt and painting tools, but
here's my opinion.

On Sun, Oct 28, 2012 at 10:09 PM, Antony Riakiotakis <kalast at gmail.com> wrote:
> 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.

Definitely agree here, could be unified a lot more.

> 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.

I think from a user point of view it's nice if you can share settings
between 2D and 3D paint, painting a bit in the 3D view and a bit in
the image editor. If the mode is set to 3D it can just fall back to a
mode that works for 2D.

> 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.

Don't have a general opinion here, 2D is like 3D with Z coordinate
always 0. It's a balance between sharing code and keeping this easy to
understand, if there's not many special exception for the 2D case I
don't really see much reason to not share them.

> 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.

I think PBVH would help painting high poly meshes, since it allows you
to quickly cull groups of faces instead of testing them all. It's only
part of the performance problem, but I guess it's mostly orthogonal to
other performance improvements.


More information about the Bf-committers mailing list