[Bf-committers] UI/RNA question

[Jason Wilkins]

I think you'll have to drill down more because I'm not sure I see the problem.

If the brush is enabled for both vpaint and sculpt modes then
direction is supported for sculpting.

Currently I do not think any brushes should be enabled for multiple
modes because we do not support that.  If a brush has both bits set
then it shouldn't be usable in any mode.

If/When we enable brushes for multiple modes simultaneously we might
need to split the direction field into multiple fields for each mode.

It has been a while since I've been in the code, so maybe I'm seeing this wrong.

On Fri, Feb 17, 2012 at 7:06 PM, Nicholas Bishop
<nicholasbishop at gmail.com> wrote:
> Bit flags is indeed what brushes currently have (via the ob_mode field.)
>
> To give an example of how this causes trouble, let's say I want to
> check in RNA whether the direction (add/subtract) property is
> supported. The brush's ob_mode flag indicates it's enabled in both
> sculpt and vpaint. The sculpt tool is draw brush, but the vertexpaint
> tool is the blur brush. The former supports direction, the latter does
> not, so there's no way to get the correct answer without examining
> context (specifically, the active object.)
>
> -Nicholas
>
> On Fri, Feb 17, 2012 at 7:52 PM, Jason Wilkins
> <jason.a.wilkins at gmail.com> wrote:
>> In the future I'd like to be able to paint and sculpt at the same
>> time.  Maybe it would be better if you made paint_mode into a set of
>> bit flags?  Right now the brushes could be exclusive to one mode, but
>> in the future they could be combinations.  Am I thinking too far
>> ahead?  It would effect how you check the paind_mode, using & along
>> with ==, which may be extra trouble if we decide in the future to
>> combine capabilities in a different way.  Also, a lot of combinations
>> make no sense, like sculpting and weight paint...
>>
>> Perhaps better to go with something simple until this is worked out.
>>
>>
>>
>> On Fri, Feb 17, 2012 at 3:51 PM, Nicholas Bishop
>> <nicholasbishop at gmail.com> wrote:
>>> While looking into this, I ran into the issue that currently you can't
>>> tell which brush tool is in use with only a brush pointer -- it could
>>> be the sculpt_tool, vertexpaint_tool, or imagepaint_tool.
>>>
>>> I can see a couple possible solutions:
>>> 1) Simplest change is to have separate capability properties for the
>>> different modes. Maybe have three nested structures in Brush RNA --
>>> SculptCapabilities, VertexPaintCapabilities, ImagePaintCapabilities.
>>> Each of these then gets boolean properties indicating support for
>>> direction, stroke methods, etc.
>>> 2) As an alternative, we could change brushes to only be active in one
>>> paint mode at a time. I've posted a patch
>>> (http://codereview.appspot.com/5671088/) that does this. This feels
>>> simpler to me, don't see that much value right now in having brushes
>>> be accessible from different paint modes.
>>>
>>> Thoughts?
>>> -Nicholas
>>>
>>> On Thu, Feb 16, 2012 at 11:35 PM, Jason Wilkins
>>> <jason.a.wilkins at gmail.com> wrote:
>>>> I agree and this was the direction I wanted to go.  My name for it was
>>>> going to be "brush semantics."
>>>>
>>>> Rather than have complex checks scattered throughout the code it would
>>>> be better to have something like, for example:
>>>>
>>>> isBrushTypeMove()
>>>> isBrushIgnoresStrength()
>>>> isBrushTypeClay()
>>>> isBrushCanLayer()
>>>>
>>>> Basically figure out what the name of the set X is when you say "brush
>>>> element of set X"
>>>>
>>>> I called it semantics because I had some vague idea of some other
>>>> things that fit the same idea besides Boolean predicates.
>>>>
>>>>
>>>>
>>>> On Thu, Feb 16, 2012 at 3:31 PM, Campbell Barton <ideasman42 at gmail.com> wrote:
>>>>> +1 for adding readonly, boolean properties (as proposed) rather than
>>>>> checking brush type all over.
>>>>>
>>>>> when there are many similar checks: if some.mode in {'A', 'B', 'C'} ...
>>>>> these kinds of checks tend to get out of sync (devs modify in one
>>>>> place but not others), if they can be generalized into bool props this
>>>>> should be less error prone and more readable too.
>>>>>
>>>>> On Fri, Feb 17, 2012 at 5:09 AM, Sergey Sharybin <sergey.vfx at gmail.com> wrote:
>>>>>> Hi.
>>>>>>
>>>>>> You can define RNA prop which isn't "connected" to any DNA property and
>>>>>> just write your own get/set function for it. Think it'll be much easier to
>>>>>> just point into sources rather than telling the same here.
>>>>>> So, you can open rna_tracking.c file and near line 963 you'll see a
>>>>>> definition of "select" property. It doesn't have DNA
>>>>>> analog.Functions rna_trackingTrack_select_get
>>>>>> and rna_trackingTrack_select_set are used to get/set vallue of this prop.
>>>>>> Think you shall just set NULL instead of set function and clear
>>>>>> PROP_EDITABLE flag for you prop. And in get function it'll be just
>>>>>> something like return ELEM(brush->type, CLAY, etcetcetc)
>>>>>>
>>>>>> Thinks it'll be easiest way for you and will help keeping py code clear and
>>>>>> easy to follow.
>>>>>>
>>>>>> On Thu, Feb 16, 2012 at 11:46 PM, Nicholas Bishop
>>>>>> <nicholasbishop at gmail.com>wrote:
>>>>>>
>>>>>>> I was looking today at updating the menus in sculpt/paint modes,
>>>>>>> currently they are incomplete.
>>>>>>>
>>>>>>> In sculpt especially right now, the toolbar UI has a lot of code like
>>>>>>> this: "if tool in {'CLAY', 'FLATTEN', 'FILL', ...}". I'd rather not
>>>>>>> duplicate such code for menus. One option is to add more functions to
>>>>>>> properties_paint_common.py, but I was wondering if it would be better
>>>>>>> to make this information available through RNA? E.g. add read-only
>>>>>>> boolean properties like "has_direction", "has_stroke_method", etc,
>>>>>>> with a get function to check current tool and such.
>>>>>>>
>>>>>>> Would appreciate guidance as to whether that's appropriate RNA usage,
>>>>>>> or other options.
>>>>>>>
>>>>>>> -Nicholas
>>>>>>> _______________________________________________
>>>>>>> Bf-committers mailing list
>>>>>>> Bf-committers at blender.org
>>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> With best regards, Sergey Sharybin
>>>>>> _______________________________________________
>>>>>> Bf-committers mailing list
>>>>>> Bf-committers at blender.org
>>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> - Campbell
>>>>> _______________________________________________
>>>>> Bf-committers mailing list
>>>>> Bf-committers at blender.org
>>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>> _______________________________________________
>>>> Bf-committers mailing list
>>>> Bf-committers at blender.org
>>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers