Proposal for merging greasepencil-object branch to 2.8 #54426

New Issue

Joshua Leung · 2018-03-26T06:47:41+02:00

Joshua Leung commented

2018-03-26 06:47:41 +02:00

Proposed Merge Plan for GP Branch into 2.8 (in bite-sized pieces)

As discussed during the meeting on 20180319, I started investigating ways we can "split" the changes for easier review (and merging to 2.8). This is complicated by the fact that a lot of the changes are interdependent on other parts. We'll probably have to live with some degree of functionality breakage (i.e. large parts of GP tools won't be able to be tested in 2.8 yet while the merging proceeds) until most of the patches have been merged back.

These changes fall into two groups: 1) The messy inter-depedent jungle of related changes, and 2) Small independent/non-critical changes.

Disclaimer: There may still be other changes I've forgotten about still.

1) Core GP Object Support

This is the part that is really hard to split up (unless we live with not testing each part until it's all merged). All the stuff here depends on the other parts, since the changes here implement the main architectural changes this branch presents.

OB_GPENCIL stuff - Adding a new Object Type for GPencil objects
DNA/RNA/Lib-handling File-IO + Version Patching
Object Editing (Select/Add/Delete/Link/Join/etc.) Outliner Support
Properties Editor + Material Settings (Split from old "common" gpencil panels) GP Editing Modes (see mode changing stuff below too)
** Context tweaks(?)
Blender Palettes - All code was changed to use Blender's Palettes system (Palette and PaletteColor) so that colour sets can be reused between datablocks. This has the following sub-components:
Removal of all old bGPDpalette/bGPDpalettecolor code, except for the API's needed to load and convert data from old files. (Note: These changes need to happen in subversion .1 or .2 to avoid trashing Hero project files) Addition of bGPDpaletteref (i.e. "Palette Slots") - an analogue to the "Material Slots" used for materials, except here, we use this to tie multiple Palettes to a single bGPdata datablock
Changes to Palette/PaletteColor to support GP (mostly the addition of many fields, and settings like Texturing, Gradients, etc.) Make Palette datablock animateable. Although old Palettes were strictly a UI feature, when used for GP, we need to be able to animate PaletteColor color values (e.g. fading in/out strokes, changing/driving colours, etc.)
Depsgraph stuff - Depends on OB_GPENCIL and Palettes stuff (and those depend on this)
GP datablocks need to be tagged for "batch cache updates" Palettes need to be part of depsgraph, so that animation/drivers work, and GP datablocks get updated in response to these changing (e.g. UI editing)
GP Draw Engine (draw/engines/gpencil) - The draw engine can probably be reviewed on its own, but you can't test it without access to other parts (notably, OB_GPENCIL, Palettes, and Depsgraph stuff)
GP stroke shaders + VFX modifiers Draw engine - Core pipeline, shading groups, etc.
** Cache management - (Note: Extra care is needed when making changes here, as we spent weeks fixing Onion Skinning related crashes here)
Mode Switching Stuff (various places all over editors/object, editors/undo, and editors/space_outliner modules) - Although this would normally be part of "new object-type" support, there's a lot of "really hairy stuff" here (IMO) that needs careful attention and back and forth. Particularly as the design here does conflict a bit with workspace modes.

2) Small/Independent Changes (Can be easily separated without compromising core functionality)

Blender Brushes - (As with palettes), change from bGPDbrush to Brush-datablocks
Change/removal of all support code for old Brush tyes Brush behaviour changes (e.g. all stroke smoothing, hotkey, calculations) when drawing
** Brush icons
New Brushes (and stuff shoe-horned into brushes) - Actually, each of these is generally quite independent, so these can be 3 separate patches/commits if need be. But, I'll list them in one go here for easier management.
Interactive "Fill Brush" Erasers as brushes (for easier control over mode + radius + strength settings)
** Brush-palette link (e.g. default color for a brush)
GP Stroke Sculpting Changes (GP Brush)
Transform Changes (e.g. for Multiframe Editing) + Other MultiFrame related changes
GP Primitives (Rectangle/Circle) + Monkey (though this one is more a part of the OB_GPENCIL stuff)
Modal "Color Picker" operator. (Note: This could potentially be reworked as part of the UI toolkit even - or at least just the popup swatches drawing part).
Animation Editor support for GP Objects / Palettes
Vertex Groups for GP Objects
** (Modifiers depend on this)
** (Weight Paint mode uses this)
Modifiers Support - Note: We can probably get away with adding the typeinfo changes first (before anything else in the branch), to avoid conflicts when DerivedMesh removal takes place
Changes to ModifierTypeInfo to add dedicated callbacks to be used on GP data (instead of abusing existing DerivedMesh centric callbacks) GP Modifier definitions + hooks into GP draw engine to apply the modifiers at drawtime
Assorted general UI and API cleanups
Math library additions (for int/short variants of the copy/add/etc. functions)

Plan/Approach

Merge all general (non-gp object specific) changes - e.g. Math library additions, ModifierTypeInfo changes, make Palettes animatable, animation editor changes (?), - IMO, most of these are relatively straightforward and should not require much fuss/debate.
Then we tackle the "core" stuff. Either we dump all of that into a single new temporary branch, or we take the unified diff and just extract the necessary hunks to make review easier (in particular, for things like depsgraph, draw engine, and mode switching support). I'd recommend tackling them in the order listed (as that would simplify compiling/access to types). I personally suspect it'd still be easier to manage by doing any necessary refactoring in the existing branch and re-extracting patches manually.
Finally, we tackle each of the smaller independent changes. These can easily be handled in a more "conventional" way.

## Proposed Merge Plan for GP Branch into 2.8 (in bite-sized pieces) As discussed during the meeting on 20180319, I started investigating ways we can "split" the changes for easier review (and merging to 2.8). This is complicated by the fact that a lot of the changes are interdependent on other parts. We'll probably have to live with some degree of functionality breakage (i.e. large parts of GP tools won't be able to be tested in 2.8 yet while the merging proceeds) until most of the patches have been merged back. These changes fall into two groups: 1) The messy **inter**-depedent jungle of related changes, and 2) Small independent/non-critical changes. Disclaimer: There may still be other changes I've forgotten about still. ### 1) **Core GP Object Support** This is the part that is really hard to split up (unless we live with not testing each part until it's all merged). All the stuff here depends on the other parts, since the changes here implement the main architectural changes this branch presents. * **OB_GPENCIL** stuff - Adding a new Object Type for GPencil objects **DNA/RNA/Lib-handling** File-IO + Version Patching **Object Editing (Select/Add/Delete/Link/Join/etc.)** Outliner Support **Properties Editor + Material Settings (Split from old "common" gpencil panels)** GP Editing Modes (see mode changing stuff below too) ** Context tweaks(?) * **Blender Palettes** - All code was changed to use Blender's Palettes system (`Palette` and `PaletteColor`) so that colour sets can be reused between datablocks. This has the following sub-components: **Removal of all old `bGPDpalette`/`bGPDpalettecolor` code, except for the API's needed to load and convert data from old files. (Note: These changes need to happen in subversion .1 or .2 to avoid trashing Hero project files)** Addition of `bGPDpaletteref` (i.e. "Palette Slots") - an analogue to the "Material Slots" used for materials, except here, we use this to tie multiple `Palettes` to a single `bGPdata` datablock **Changes to Palette/PaletteColor to support GP (mostly the addition of many fields, and settings like Texturing, Gradients, etc.)** Make `Palette` datablock animateable. Although old Palettes were strictly a UI feature, when used for GP, we need to be able to animate `PaletteColor` color values (e.g. fading in/out strokes, changing/driving colours, etc.) * **Depsgraph** stuff - Depends on OB_GPENCIL and Palettes stuff (and those depend on this) **GP datablocks need to be tagged for "batch cache updates"** Palettes need to be part of depsgraph, so that animation/drivers work, and GP datablocks get updated in response to these changing (e.g. UI editing) * **GP Draw Engine** (`draw/engines/gpencil`) - The draw engine can probably be reviewed on its own, but you can't test it without access to other parts (notably, OB_GPENCIL, Palettes, and Depsgraph stuff) **GP stroke shaders + VFX modifiers** Draw engine - Core pipeline, shading groups, etc. ** Cache management - (Note: Extra care is needed when making changes here, as we spent weeks fixing Onion Skinning related crashes here) * **Mode Switching Stuff** (various places all over `editors/object`, `editors/undo`, and `editors/space_outliner` modules) - Although this would normally be part of "new object-type" support, there's a lot of "really hairy stuff" here (IMO) that needs careful attention and back and forth. Particularly as the design here does conflict a bit with workspace modes. ### 2) **Small/Independent Changes** (Can be easily separated without compromising core functionality) * Blender Brushes - (As with palettes), change from `bGPDbrush` to `Brush`-datablocks **Change/removal of all support code for old Brush tyes** Brush behaviour changes (e.g. all stroke smoothing, hotkey, calculations) when drawing ** Brush icons * New Brushes (and stuff shoe-horned into brushes) - Actually, each of these is generally quite independent, so these can be 3 separate patches/commits if need be. But, I'll list them in one go here for easier management. **Interactive "Fill Brush"** Erasers as brushes (for easier control over mode + radius + strength settings) ** Brush-palette link (e.g. default color for a brush) * GP Stroke Sculpting Changes (GP Brush) * Transform Changes (e.g. for Multiframe Editing) + Other MultiFrame related changes * GP Primitives (Rectangle/Circle) + Monkey (though this one is more a part of the OB_GPENCIL stuff) * Modal "Color Picker" operator. (Note: This could potentially be reworked as part of the UI toolkit even - or at least just the popup swatches drawing part). * Animation Editor support for GP Objects / Palettes * Vertex Groups for GP Objects ** (Modifiers depend on this) ** (Weight Paint mode uses this) * Modifiers Support - Note: We can probably get away with adding the typeinfo changes first (before anything else in the branch), to avoid conflicts when DerivedMesh removal takes place **Changes to `ModifierTypeInfo` to add dedicated callbacks to be used on GP data (instead of abusing existing DerivedMesh centric callbacks)** GP Modifier definitions + hooks into GP draw engine to apply the modifiers at drawtime * Assorted general UI and API cleanups * Math library additions (for int/short variants of the copy/add/etc. functions) ## Plan/Approach 1) Merge all general (non-gp object specific) changes - e.g. Math library additions, ModifierTypeInfo changes, make Palettes animatable, animation editor changes (?), - IMO, most of these are relatively straightforward and should not require much fuss/debate. 2) Then we tackle the "core" stuff. Either we dump all of that into a single new temporary branch, or we take the unified diff and just extract the necessary hunks to make review easier (in particular, for things like depsgraph, draw engine, and mode switching support). I'd recommend tackling them in the order listed (as that would simplify compiling/access to types). I personally suspect it'd still be easier to manage by doing any necessary refactoring in the existing branch and re-extracting patches manually. 3) Finally, we tackle each of the smaller independent changes. These can easily be handled in a more "conventional" way.

Joshua Leung commented

2018-03-26 06:47:41 +02:00

Added subscribers: @JoshuaLeung, @ideasman42, @dfelinto, @Sergey, @antoniov, @pepe-school-land, @mendio, @pablovazquez

Antonio Vazquez commented

2018-04-04 10:28:18 +02:00

As a note, the main areas that need more review are:

Mode switching.
Improve merge grease pencil render result with Eevee/Cycles render result (F12).
Low quality Depth of Field effect.
Antialiasing between 3D objects and in Opengl/F12 render.
2D editors support.
Simple annotations.

As a note, the main areas that need more review are: - Mode switching. - Improve merge grease pencil render result with Eevee/Cycles render result (F12). - Low quality Depth of Field effect. - Antialiasing between 3D objects and in Opengl/F12 render. - 2D editors support. - Simple annotations.

Ryan commented

2018-04-17 20:42:31 +02:00

Added subscriber: @RyanJEC

Ryan commented

2018-04-17 20:43:17 +02:00

Removed subscriber: @RyanJEC

Brecht Van Lommel commented

2018-12-12 15:42:38 +01:00

Changed status from 'Open' to: 'Archived'

Brecht Van Lommel closed this issue

2018-12-12 15:42:38 +01:00

Brecht Van Lommel self-assigned this 2018-12-12 15:42:38 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Proposal for merging greasepencil-object branch to 2.8 #54426

Proposed Merge Plan for GP Branch into 2.8 (in bite-sized pieces)

1) Core GP Object Support

2) Small/Independent Changes (Can be easily separated without compromising core functionality)

Plan/Approach