Re: [Bf-committers] Texture painting considerations (preparations for bratwurst merge)
This is supposed to happen. Internally texture paint uses stroke masking to avoid repainting on the same region. Solution: use air brush ;). ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Texture painting considerations (preparations for bratwurst merge)
My previous answer is wrong it seems. It looks like when using the space stroke option, the two modes (projective/2D) operate slightly differently. Spacing is done on image/uv space for image editor and screen space for projective texturing. That means that most of the time, the 2D code will generate many more strokes per pixel than the projective case (because generally texture is zoomed out in viewport). This has the effect of getting a more intense result when painting in the 2D view. I wouldn't count this as a bug though, it is intended behaviour. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Texture painting considerations (preparations for bratwurst merge)
That's ok, as long as you admit that you were wrong :) (kidding) On Mon, Mar 4, 2013 at 7:02 AM, Antony Riakiotakis kal...@gmail.com wrote: My previous answer is wrong it seems. It looks like when using the space stroke option, the two modes (projective/2D) operate slightly differently. Spacing is done on image/uv space for image editor and screen space for projective texturing. That means that most of the time, the 2D code will generate many more strokes per pixel than the projective case (because generally texture is zoomed out in viewport). This has the effect of getting a more intense result when painting in the 2D view. I wouldn't count this as a bug though, it is intended behaviour. ___ 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
Re: [Bf-committers] Texture painting considerations (preparations for bratwurst merge)
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
Re: [Bf-committers] Texture painting considerations (preparations for bratwurst merge)
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
Re: [Bf-committers] Texture painting considerations (preparations for bratwurst merge)
I take it you are referring to the way texture masks are applied? Then yes, it doesn't work that well without ticking airbrush. This has the effect of disabling the paint mask to cull previous strokes, but I agree it should be done automatically. Yes, alpha masks do not appear in the GUI, the reason being I couldn't find the place in the code where they are being displayed during GSOC. But that simply means I didn't persevere enough. They'll definitely be there before merge though. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Texture painting considerations (preparations for bratwurst merge)
Hi, There's others who know more about the sculpt and painting tools, but here's my opinion. On Sun, Oct 28, 2012 at 10:09 PM, Antony Riakiotakis kal...@gmail.com wrote: 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. Definitely agree here, could be unified a lot more. 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. I think from a user point of view it's nice if you can share settings between 2D and 3D paint, painting a bit in the 3D view and a bit in the image editor. If the mode is set to 3D it can just fall back to a mode that works for 2D. 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. Don't have a general opinion here, 2D is like 3D with Z coordinate always 0. It's a balance between sharing code and keeping this easy to understand, if there's not many special exception for the 2D case I don't really see much reason to not share them. 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. I think PBVH would help painting high poly meshes, since it allows you to quickly cull groups of faces instead of testing them all. It's only part of the performance problem, but I guess it's mostly orthogonal to other performance improvements. Brecht. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Texture painting considerations (preparations for bratwurst merge)
Hi Brecht, thanks for the comments. I have nothing to add here short of some comments about 2D vs 3D painting. 3D aka projective painting is much more involved than adding another dimension, however there could be shared code between the two especially when it comes to application of brush stroke (airbrush, space, etc). Apart from that though the internals of the two paint modes are vastly different. Also currently a lot of 2D painting functionality is inside BKE_brush.c which is supposed to be the Brush API implementation file. On bratwurst I have separated the 2D paint relevant functions into paint_2D.c. I hope this is OK with other developers. ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
