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