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

Antony Riakiotakis kalast at gmail.com
Mon Mar 4 03:17:44 CET 2013


Hi all, an update on this thread.

Currently I am in the process of reusing paint stroke code in texture
painting. The experiment is being a success but to unify the code
better I will need to tweak code across other paint systems too and
gather feedback.

Considerations and things that I personally want to refactor are:

Texture painting
===============
* Disentangle projective and 2D painting completely.
The only shared code is the stroke calculation code parts of which are
duplicated in paint_stroke.c and indeed should be written once and
reused on all our paint systems.

 This would be easier if we get rid of 3D (non-projective) mode
texture painting in 3D viewport. In this mode you paint on model but
result gets written in image space and will be horribly distorted in
3D view. In my opinion this is useless since we now have projective
texturing for all tools (blur, smudge, clone, draw) and view mapping
mode is exposed. There has been one user complaint about using pixel
size of brush in 3D space which is possible in this mode but I think
3D viewport is not the editor for working in image space. On the
contrary, painting on image editor is recommended and produces better
feedback.

* Reuse paint stroke code. This is possible currently but we do some
pressure manipulation in the paint code that needs to move to the
generic stroke code. Doing this in the stroke system will require
reviewing all our paint systems and modifying them not to do extra
conversions on the pressure. We need to define better what state the
pressure values are during stroke/initialization etc.

Other modes
=============
* On almost all modes I checked (texture painting included), we use
mouse coordinates in region space (the update_step functions all
subtract the region coordinates from the mouse coordinates). Paint
stroke code operates in screen space. I think this is only used for
sculpting? Are there any objections to tweaking the code to use region
space?

* Pressure manipulation code should move to paint_stroke (any
objections/special cases here?)

* Brush texture sampling: Currently there are many methods to do this.
Some are used in texture painting, 2 methods, one each for projective
and 2D case and one is used for sculpting (where we convert the result
to intensity). Ideally the way this should ideally operate is that we
pass screen coordinate or 3D position for some brush modes to the
brush texture sampling function and the function should return the
corresponding texel value based on the brush settings. This should
ideally be a global interface in BKE_brush. I think I could probably
refactor the sculpt sampling function to something more global. I
won't be able to unify the 2D paint code to use that (because input
coordinates are in uv, not screen space) but this will allow us to
expose texture sampling for all 3D paint modes see vertex paint, even
weight paint too. Also it will allow me to implement a stencil mapping
mode (like the one done by Nicholas Bishop in his ptex branch) and
expose it to all 3D paint modes at once.

* Almost every paint mode uses variables like "first", to do first
time initializations, be it tool or mode specific and "last_mouse".
paint stroke stores these too. Maybe they could be reused?


I am waiting feedback on these from all paint system maintainers. If
this is to be undertaken I could possibly do most of the code work but
I'd like some good testing for corner cases that may break, which is
bound to happen for certain in this kind of refactoring.


More information about the Bf-committers mailing list