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

[Fredrik hansson]

speaking of improving the texture paint and the rake style brushes.
i tried out bratwurst branch and noticed one slightly annoying thing with it.
round brushes, basically if you have a texture brush that isn't round in the image you will never get the data from the edges so if you actually want it to be square for some reason (paint wear brushes work great with square edges for example) you would have to make the image ~40% larger (+brush size).

now this isn't an unique issue to the texture paint since i think the sculpt mode works the same but i can't confirm that right now.
other than that alpha masked brushes have been probably my main reason why i haven't used blender for texture painting so can't wait until the bratwurst branch is merged to trunk :D

oh yeah i think i noticed one other thing brush masking textures didn't show up in the texture browser like the material/world/brush textures did but i could just have not been paying attention enough.



________________________________
 From: Antony Riakiotakis <kalast at gmail.com>
To: bf-blender developers <bf-committers at blender.org> 
Sent: Sunday, October 28, 2012 10:09 PM
Subject: [Bf-committers] Texture painting considerations (preparations for bratwurst merge)
 
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.
_______________________________________________
Bf-committers mailing list
Bf-committers at blender.org
http://lists.blender.org/mailman/listinfo/bf-committers