[Bf-committers] Using Blender Palettes vs bGPDpalettes for GreasePencil

[blendergit at gmail.com]

Thanks for your comments, I totally agree with you.

I decided to use Blender Palettes because use palettes for GP only was not the best solution for future. Make new tools consistent with all others areas is very important in any software design. I really hate the “particular” cases, these areas are always a source of problems, it's always better use a more general solution.

After I published the wiki, I had received some concerns about using Blender palettes, and as I don't know some areas of Blender code, I wanted to share with all of you these topics to get a decision with maximum consensus.

Cheers,
Antonio

De: Bastien Montagne
Enviado: martes, 10 de enero de 2017 22:58
Para: bf-committers at blender.org
Asunto: Re: [Bf-committers] Using Blender Palettes vs bGPDpalettes for GreasePencil

First of all, there is a big, absolute pro to reuse existing Palette ID: 
adding another Palette datablock is an absolute and definitive no-go 
from my side. Am already not really happy to see IDs for things like 
brushes and palettes (those are more tool settings than data), though I 
do understand the reasons for this, but we won’t have two different 
datablocks for the same thing. Never ever. :)

That said, I’m not convinced by any of the 'cons' points here:

1) More fancy options that are GP-only: why? There’s absolutely nothing 
preventing other drawing tools to support gradients, linestyles, 
patterns, whatever. I don’t mean they have to, of course, but that kind 
of option is potentially universal to any kind of painting (even sculpt 
could use it!).

2) Bloating. Serioulsy? A few more tens (or even hundreds) of bytes per 
struct, and maybe in worst case a few hundreds of structs in a file? 
i.e. at worst a few tens of kilobytes more? Come on… Regarding RNA/API, 
*if* we really consider it a problem to expose whole GP stuff for all 
palettes, there is always the possibility to define a generic, basic 
Palette RNA struct, and derive from it a more complete version for GP 
(and then use RNA refine system to properly generate GP version for 
GP-used palettes), I think? But I don’t see this as a real issue…

3) Forward compat: Well, yes, but 2.8 is kind of the right time to do 
it, really. And forward compat is not sacred anyway, even if we should 
try to avoid breaking it, it’s not as crucial as backward compat.

So my final word: please, please, please, no two different Palette ID 
types! :P

Cheers,
Bastien

Le 10/01/2017 à 19:16, blendergit at gmail.com a écrit :
> Hi All,
>   
> As you probably know,  We are working in new improvements for grease pencil in 2.8 release. One of the main points of these new changes is create a new GP object and this brings the palette question.
>   
> In 2.78, the palettes are defined as bGPDpalettes and bGPDpalettecolor inside GP datablock, so each datablock has his own palette. This is not practical if we want to have several GP objects on screen and we need a way to share the palettes with several GP datablocks.
>   
> During last November 2.8 workshop, the palette subject was reviewed and the idea was to move to Blender Palettes in order to have one system only for all Blender. You can see more details here: https://wiki.blender.org/index.php/User:Antoniov/Convert_bGPDpalettes_to_BlenderPalettes
>   
> Since them I have been working in a private branch and I got a version running using the Blender Palettes (pending animation topic), but at this moment arises a concern about the use of Blender Palettes instead  of separated GP only palettes.
>   
> Here I made a summary of the private mails we had about using Blender Palettes or not :
>   
> Cons:
>   
> A lot more new fancy linestyle and fill options will be added in there in the future. For example, stuff like gradients, linestyle (solid vs dotted/dashes, etc.) texturing support, etc.
>   
> If we move to Blender Palettes, this will mean bloating up the general case with a lot of GP only stuff. However, if we keep it the current bGPDpalette stuff, we have lot more freedom to do stuff like this.  (Also, keep in mind that bloating up Blender Palettes means that, 1) There's more filesize wastage, 2) Any scripter going through the PyAPI or RNA listings is going to have a harder time figuring out which properties can be used normally, and which are GP only)
>   
> We're going to break forward compatibility *again*. Sure, if we're moving palettes to datablocks, there's going to be some breakage anyway, but at the very least, old Blender versions will still have a chance of reading the colors out of the palettes (ignoring the ID datablock stuff) since the pointers would still be present and working.
>   
> Pros:
>   
> We have one system for all Palettes in Blender and we use only a ID block.
>   
> After reviewing the API of Blender Palettes in 2.78, I have seen the API is very limited, almost inexistent (https://www.blender.org/api/blender_python_api_2_78_0/bpy.types.PaletteColor.html#bpy.types.PaletteColor).
>   
> The current use of the Blender 2.78 Palettes is very limited and I had to add a lot of new API to this ID in order to support GP. I don’t think we are going to break important scripts and if we talk about GP, I have replicated all old API methods, so the conversion would be very easy. If we use Blender Palettes or move the bGPDpalette outside GP, both options will require an update of the scripts, and must be updated to use Paint or Scene instead of GP as parent.
>   
> About the concern of having part of the API for GP only, we could solve this adding a "pencil" prefix or suffix to all related API functions, but I’m not sure we really need this because the current API is “create” and “remove” only, so all API would be GP.
>   
> For the Palettes used in Vertex Paint, weight paint, etc. I have kept the same UI, so the users will not see any difference and at API level, as old methods (create/remove) remain equal, there aren’t changes at script level.
>   
> I have added new context methods too and changed the old methods of bGPDpalettes and bGPDpalettecolors (active_gpencil_palette, etc.)  to use Blender palettes internally, so this part of the scripts remain untouched. The support of context methods in the Blender Palettes was non-existent, so I had to add all from scratch.
>   
> As the current use of the 2.78 palettes is very limited, if we add things to the struct we are not breaking anything and we can add what we need today and in the future (we are free to implement anything here). The size of the file only will be bigger if we add data for GP and the original size of the struct is small.
>   
> For conversion, I have developed the corresponding code in versioning file, and we could provide a script  (add-on) for more complex conversion of old files.
>   
> Of course, use an existing ID will be better for others developers and keeps the list of IDs shorter.
>   
> I would like to take a final decision in the next meeting and decide if I follow developing animation support of Blender Palettes  or undo all changes I did and take a new direction.
>   
> Waiting for your comments!
>   
> Best Regards,
> Antonio Vazquez
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers

_______________________________________________
Bf-committers mailing list
Bf-committers at blender.org
https://lists.blender.org/mailman/listinfo/bf-committers