[Bf-committers] UI/RNA question

Nicholas Bishop nicholasbishop at gmail.com
Sat Feb 18 02:06:29 CET 2012


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


More information about the Bf-committers mailing list