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 <kal...@gmail.com> To: bf-blender developers <bf-committers@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@blender.org http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers