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

[Morten Mikkelsen]

Perhaps you could also look into why the default brush looks so bad for
bump painting yet  when air-brush is checked it looks perfect.

Just a though :)

Cheers,

Morten.






On Sun, Mar 3, 2013 at 6:17 PM, Antony Riakiotakis <kalast at gmail.com> wrote:

> 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.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>