[Bf-committers] Using Blender Palettes vs bGPDpalettes for Grease Pencil

Wed Jan 11 09:58:40 CET 2017

Hi Antonio,

Aside of the discussed details; it's a good starting point to regard GP as a core Blender tool. 
Just as for all tools, we aim at building a unified well integrated environment, with unified methods and conventions.

That means that most of the design decisions can be solved by simply following how other parts in Blender do it. This sometimes might feel limiting or less efficient, but it's a real core value that benefits everyone. It makes painting tools consistent as well.

Obviously there are exceptions, but for re-use of Palette data it's a no-brainer trslly. If existing Palettes are limited, just fix Palettes for the other tools? That would be a real win-win.

Thanks,

-Ton-

--------------------------------------------------------
Ton Roosendaal  -  ton at blender.org   -   www.blender.org
Chairman Blender Foundation, Director Blender Institute
Entrepotdok 57A, 1018 AD, Amsterdam, the Netherlands

> On 10 Jan 2017, at 22:58, Bastien Montagne <montagne29 at wanadoo.fr> wrote:
> 
> 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