Proposal for merging greasepencil-object branch to 2.8 #54426

Closed
opened 2018-03-26 06:47:41 +02:00 by Joshua Leung · 5 comments
Member

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.
## 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.
Author
Member
Added subscribers: @JoshuaLeung, @ideasman42, @dfelinto, @Sergey, @antoniov, @pepe-school-land, @mendio, @pablovazquez

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.

Added subscriber: @RyanJEC

Added subscriber: @RyanJEC

Removed subscriber: @RyanJEC

Removed subscriber: @RyanJEC

Changed status from 'Open' to: 'Archived'

Changed status from 'Open' to: 'Archived'
Brecht Van Lommel self-assigned this 2018-12-12 15:42:38 +01:00
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#54426
No description provided.