Grease Pencil scaling issues through multiple editors. #53633

Closed
opened 2017-12-25 21:46:32 +01:00 by ChristopherAnderssarian · 5 comments

System Information
Windows 7 Ultimate, 64-bit, 32GB DDR4, 5960x (8-core), Nvidia Quadro FX 1800 (Primary) & GeForce 9800 GTX+ (Secondary)
Graphics Tablet: Wacom Bamboo Model: CTF-430 Driver Version 5.2.4-5

Blender Version(s)
Inically saw problem in:
Broken: (2.79 2017-09-11 10:43 Hash: 5bd8ac9)
Then tested in:
Broken: (2.80 2017-11-11 15:23 Hash: f30a2a7 Branch blender2.8)
And then tested in:
Broken: (2.80 2017-12-22 21:18 Hash: fe1e2c2 Branch blender2.8) (blender-2.80-fe1e2c2-win64-vc14)
Worked: (N/A) I think this is throughout GP lifetime.

Short description of error

Grease Pencil is not the same/consistent scale through multiple editors (Movie Clip Editor & U/V Image Editor vs. Video Sequence Editor & Node Editor) on the same GP Layer.

End of Short description of error

I am not sure if the additional things I have in here in the videos below are relevant to this or are completely different issues.

Exact steps for others to reproduce the error

Video 1: https://www.youtube.com/watch?v=X7MnP3KLO2M&t=1m18s

Grease Pencil in diffrent editors 2.79 reloaded factory defaults.blend

Video 2: other observations https://www.youtube.com/watch?v=b61ziedh7dM

Grease Pencil in diffrent editors 2.79.blend

Another test in: 2.80 (2.80 2017-11-11 15:23 Hash: f30a2a7 Branch blender2.8)
And then: (2.80 2017-12-22 21:18 Hash: fe1e2c2 Branch blender2.8)

Grease Pencil in diffrent editors.blend

Just tested this with 2.76 so either this is not known or not a bug, oh well... I put all this effort in I might as well...

https://youtu.be/WXMQBF-mQ9I

Grease Pencil in diffrent editors 2.76.blend

P.S.

I am not to sure if the Grease Pencil is only intended to be used in 3D for animation or if you will be able to still (in 2.80) animate in 2D in 2D Editors.

This line from blender's wiki concerns me tho: "The new Object will be used only for 3D view, including new functionalities. For 2D modes (VSE, IMage Editor, Node Editor, etc) the current grease pencil code will be used and renamed as Annotations." wiki.blender.org
..."Restoration of simple GP "Annotation" functionality for 2D editors."... [Differential D2889 ](https://developer.blender.org/D2889) I hope I'm misunderstanding this.

I checked https://developer.blender.org/project/board/62/ to see if this (observation) is known or not. I hope this is correctly.
Hope I did everything right, as this is my first time reporting a bug.
Any feedback or questions are welcome.

**System Information** Windows 7 Ultimate, 64-bit, 32GB DDR4, 5960x (8-core), Nvidia Quadro FX 1800 (Primary) & GeForce 9800 GTX+ (Secondary) Graphics Tablet: Wacom Bamboo Model: CTF-430 Driver Version 5.2.4-5 **Blender Version(s)** Inically saw problem in: Broken: (2.79 2017-09-11 10:43 Hash: 5bd8ac9) Then tested in: Broken: (2.80 2017-11-11 15:23 Hash: f30a2a7 Branch blender2.8) And then tested in: Broken: (2.80 2017-12-22 21:18 Hash: fe1e2c2 Branch blender2.8) (blender-2.80-fe1e2c2-win64-vc14) Worked: (N/A) I think this is throughout GP lifetime. **Short description of error** Grease Pencil is not the same/consistent scale through multiple editors (Movie Clip Editor & U/V Image Editor vs. Video Sequence Editor & Node Editor) on the same GP Layer. **End of Short description of error** I am not sure if the additional things I have in here in the videos below are relevant to this or are completely different issues. **Exact steps for others to reproduce the error** Video 1: https://www.youtube.com/watch?v=X7MnP3KLO2M&t=1m18s [Grease Pencil in diffrent editors 2.79 reloaded factory defaults.blend](https://archive.blender.org/developer/F1524814/Grease_Pencil_in_diffrent_editors_2.79_reloaded_factory_defaults.blend) Video 2: other observations https://www.youtube.com/watch?v=b61ziedh7dM [Grease Pencil in diffrent editors 2.79.blend](https://archive.blender.org/developer/F1524589/Grease_Pencil_in_diffrent_editors_2.79.blend) Another test in: 2.80 (2.80 2017-11-11 15:23 Hash: f30a2a7 Branch blender2.8) And then: (2.80 2017-12-22 21:18 Hash: fe1e2c2 Branch blender2.8) [Grease Pencil in diffrent editors.blend](https://archive.blender.org/developer/F1524590/Grease_Pencil_in_diffrent_editors.blend) Just tested this with 2.76 so either this is not known or not a bug, oh well... I put all this effort in I might as well... https://youtu.be/WXMQBF-mQ9I [Grease Pencil in diffrent editors 2.76.blend](https://archive.blender.org/developer/F1525209/Grease_Pencil_in_diffrent_editors_2.76.blend) **P.S.** I am not to sure if the Grease Pencil is only intended to be used in 3D for animation or if you will be able to still (in 2.80) animate in 2D in 2D Editors. This line from blender's wiki concerns me tho: "The new Object will be used only for 3D view, including new functionalities. For 2D modes (VSE, IMage Editor, Node Editor, etc) the *current grease pencil code* will be used and renamed as Annotations." [wiki.blender.org ](https://wiki.blender.org/index.php/User:Antoniov/Grease_Pencil_as_Object#GPencil_Object) ...*"Restoration of simple GP "Annotation" functionality for 2D editors."*... [Differential [D2889](https://archive.blender.org/developer/D2889) ](https://developer.blender.org/D2889) I hope I'm misunderstanding this. I checked https://developer.blender.org/project/board/62/ to see if this (observation) is known or not. I hope this is correctly. Hope I did everything right, as this is my first time reporting a bug. Any feedback or questions are welcome.

Added subscriber: @ChristopherAnderssarian

Added subscriber: @ChristopherAnderssarian
Member

Added subscriber: @JoshuaLeung

Added subscriber: @JoshuaLeung
Joshua Leung self-assigned this 2017-12-27 04:00:07 +01:00
Member

Changed status from 'Open' to: 'Archived'

Changed status from 'Open' to: 'Archived'
Member

Thanks for your report. There are really 2 sets of issues here, so I'll deal with each one by one.

1) Different Scaling in Different Editor Types

It is not really a bug that the sizes of elements are different in different editor types. In fact, it is an unfortunate and unavoidable consequence of some fundamental differences between the ways that the different editors are set up.

For example:

  • The Image Editor's coordinates are strictly bounded to the 0.0 - 1.0 range. BUT, these values are interpreted as being relative to the dimensions of whatever image is currently loaded.
  • The Sequence Editor's Preview region coordinates are relative to the size of the rendered output (in absolute coordinates). So, changing the resolution of the render will cause some problems there. (Note: Fixing the behaviour so that changing the render resolution will not leave sketches the wrong sizes is a separate issue that we have an existing bug report for)
  • The Node Editor uses yet another coordinate system, best suited to rendering the widgets

However, in theory it shouldn't be a problem at all, since strokes from each of these three editor types shouldn't be showing up in the other editors at all, as each one should be taggng its strokes as being of a different type (so that they can get rendered correctly). Why exactly that fails is a topic for discussion, but the workaround is simple: Just don't use the same GP datablock across different editor types! (TBH, I really don't understand why people do anything otherwise :)

2) GP Support in 2.8 (3D vs 2D, etc.)

TBH, the situation here is still a bit of a mess and is very much WIP. First I'll go over what the current situation is, then I'll cover what the eventual plan is, and finally, why things are the way they are.

Current Situation (GP Branch):

  • In the 3D view, Grease Pencil becomes a new Object type (just like Meshes, Curves, Armatures, etc.), with edit modes/object data/etc. The intention here is that if you want to do any freehand sketching in the 3d viewport, those strokes need to get managed using a GP object, making it easier to do things like reposition/group clusters of strokes easier. Also, it lets us have proper modes for GP editing, instead of having that be taked on top of everything else. These changes make it easier for creating hand-drawn art with Grease Pencil
    • GP data for old files (3d view) will get converted to new GP objects
    • For "annotation" workflows, we designate one GP object per scene to be the "default" GP object. So, whenever you start sketching with another object selected, the strokes you draw get sent to that default GP object instead. (TBH, this part of the workflow is a bit rough, and probably needs to be revised as it's still a bit of a step-down from what we used to have. But, it's better that what I initially found when trying to get the branch into a usable shape :)
  • Support for Grease Pencil in all other editor types (i.e. basically all the 2D editors) is not yet working. I'm not entirely sure why, as the drawing code was theoretically ported over to the new GL wrappers, but more investigation is needed. (Note: This is not just exclusive the the GP branch, but to 2.8 in general. So, it's not like we deliberately broke it for everything else)

Eventual Plans:

  • As mentioned in a few other places, GP-like support will be returning to all other (2D) editors eventually. However, to avoid confusion, we will be calling that functionality 'Annotations' instead.

    • The current plan is that these Annotation features for 2D editors will have a similar level of functionality to the 2D GPencil in 2.7x (which admittedly, was already lagging behind the 3D implementation anyway).
    • There will still be some basic editing tools (transform - grab/rotate/scale + proportional editing, delete, copy/paste) and a few simple sculpt brushes (e.g. push, smooth).
    • However, stuff like the new palettes stuff, modifiers, and probably the more advanced parts of the sculpt brushes will not be available. (I'm particularly keen to take the functionality here back to before the 2.77/8 palette changes, so that we have just 1 colour + thickness per layer; IMO, it was a mistake to use all that extra stuff for the 2D views, as it just bloated the UI's for little benefit in an area where it's not so critical to have full control like this)
  • Non-3d-art use cases in the 3D view need to be reviewed.

    • Admittedly, what we've got in the branch now isn't so ideal for scripts/addons that use GP for freehand sketch input. The forced mode+selection switch that occurs (since stroke drawing in 3D view now only happens in "draw mode" for GP objects) is admittedly a problematic limitation that we really should try to improve. We may even need to move towards having some kind of dedicated modal-api (e.g. like for borderselect/circle select stuff) that addons can use for getting freehand sketch input from users (but without creating GP objects / dealing with all the object configuration stuff).
    • Note; There's nothing concrete about what we'll do in this space yet. But, certainly, something needs to happen here, as one of my own pet projects is directly impacted by this ;)

Why - How did we end up in this state, etc.:

  • The biggest issue here is simply that there are only so many things that we can work on at once.
    • The current priorities are to polish the "GP for Art" tools that are essential for the success of the Hero open movie project. There are quite a few outstanding "big ticket items" still outstanding on this front that we just have to prioritise first to make the production feasible. So, all efforts need to go to sorting out just that one thing first. Furthermore, given that this is one of the upcoming "big unique selling-points" for Blender (since no other major 3d platforms have something like this built in), we're dedicating effort to getting this right first and foremost, even if other cases have to suffer in the short term.

  • For an example of the current manpower limitations, over the past few weeks, we've basically been spending everyday basically tracking down and fixing a neverending stream of crashes and bugs arising from 1) the new functionality and integration with previously unintegrated systems, and 2) have to fix/update our code several times a day, 5 days a week, in response to a constant stream of code churn due to the big depsgraph-related cleanups (atm, barely a day goes by without at least another 2 things breaking there and needing attention)

  • Second, we're currently working in a branch (based off 2.8), that already has a large number of non-trivial changes in it.

    • In many ways, I'd probably go as a far as to say that there are probably too many changes in this branch already, and we should really just merge it all into 2.8 now and then slowly fix whatever carnage that may cause. (It'd probably be better than what we're doing now, as there'd be less stress on us to keep fixing stuff that keeps breaking from under our feet).
    • It's hard enough for us to keep on top of merge conflicts, but it's also harder for everyone in the long run keeping version-patching stuff from causing data loss for the production (we've had 2-3 subversion bumps for files already, with some of those having happened in parallel, and I'm sure we're going to keep running into these issues going forward).
    • It's also harder for everyone involved to review large branches, as there's just so much more code to go through, making code review an even more daunting chore than it is already.
    • Given that we're already operating in a rather big branch (that all the standard code review tools are already having trouble managing), it really doesn't make sense to begin any futher sets of major refactors on top of that (but which are kind of complementary / independent yet dependent), to further compound our problems. As a result, there are 2 other major refactors to GP-related stuff that are actually still pending until we can get the main bulk of changes mainlined into 2.8 (as originally planned at the start of the Hero project). (Note: Those two other refactors are, 1) "Annotations" for 2D editors, 2) The ability to edit GP keyframes and normal keyframes in the same Dopesheet views)
Thanks for your report. There are really 2 sets of issues here, so I'll deal with each one by one. ## 1) Different Scaling in Different Editor Types It is not really a bug that the sizes of elements are different in different editor types. In fact, it is an unfortunate and unavoidable consequence of some fundamental differences between the ways that the different editors are set up. For example: * The Image Editor's coordinates are strictly bounded to the 0.0 - 1.0 range. BUT, these values are interpreted as being relative to the dimensions of whatever image is currently loaded. * The Sequence Editor's Preview region coordinates are relative to the size of the rendered output (in absolute coordinates). So, changing the resolution of the render will cause some problems there. (Note: Fixing the behaviour so that changing the render resolution will not leave sketches the wrong sizes is a separate issue that we have an existing bug report for) * The Node Editor uses yet another coordinate system, best suited to rendering the widgets However, in theory it shouldn't be a problem at all, since strokes from each of these three editor types shouldn't be showing up in the other editors at all, as each one should be taggng its strokes as being of a different type (so that they can get rendered correctly). Why exactly that fails is a topic for discussion, but the workaround is simple: **Just don't use the same GP datablock across different editor types!** (TBH, I really don't understand why people do anything otherwise :) ## 2) GP Support in 2.8 (3D vs 2D, etc.) TBH, the situation here is still a bit of a mess and is very much WIP. First I'll go over what the current situation is, then I'll cover what the eventual plan is, and finally, why things are the way they are. **Current Situation (GP Branch)**: * In the 3D view, Grease Pencil becomes a new Object type (just like Meshes, Curves, Armatures, etc.), with edit modes/object data/etc. The intention here is that if you want to do any freehand sketching in the 3d viewport, those strokes need to get managed using a GP object, making it easier to do things like reposition/group clusters of strokes easier. Also, it lets us have proper modes for GP editing, instead of having that be taked on top of everything else. These changes make it easier for creating hand-drawn art with Grease Pencil * GP data for old files (3d view) will get converted to new GP objects * For "annotation" workflows, we designate one GP object per scene to be the "default" GP object. So, whenever you start sketching with another object selected, the strokes you draw get sent to that default GP object instead. (TBH, this part of the workflow is a bit rough, and probably needs to be revised as it's still a bit of a step-down from what we used to have. But, it's better that what I initially found when trying to get the branch into a usable shape :) * Support for Grease Pencil in all other editor types (i.e. basically all the 2D editors) is not yet working. I'm not entirely sure why, as the drawing code was theoretically ported over to the new GL wrappers, but more investigation is needed. (Note: This is not just exclusive the the GP branch, but to 2.8 in general. So, it's not like we deliberately broke it for everything else) **Eventual Plans**: * As mentioned in a few other places, GP-like support will be returning to all other (2D) editors eventually. However, to avoid confusion, we will be calling that functionality 'Annotations' instead. * The current plan is that these Annotation features for 2D editors will have a similar level of functionality to the 2D GPencil in 2.7x (which admittedly, was already lagging behind the 3D implementation anyway). * There will still be some basic editing tools (transform - grab/rotate/scale + proportional editing, delete, copy/paste) and a few simple sculpt brushes (e.g. push, smooth). * However, stuff like the new palettes stuff, modifiers, and probably the more advanced parts of the sculpt brushes will not be available. (I'm particularly keen to take the functionality here back to before the 2.77/8 palette changes, so that we have just 1 colour + thickness per layer; IMO, it was a mistake to use all that extra stuff for the 2D views, as it just bloated the UI's for little benefit in an area where it's not so critical to have full control like this) * Non-3d-art use cases in the 3D view need to be reviewed. * Admittedly, what we've got in the branch now isn't so ideal for scripts/addons that use GP for freehand sketch input. The forced mode+selection switch that occurs (since stroke drawing in 3D view now only happens in "draw mode" for GP objects) is admittedly a problematic limitation that we really should try to improve. We may even need to move towards having some kind of dedicated modal-api (e.g. like for borderselect/circle select stuff) that addons can use for getting freehand sketch input from users (but without creating GP objects / dealing with all the object configuration stuff). * Note; There's nothing concrete about what we'll do in this space yet. But, certainly, something needs to happen here, as one of my own pet projects is directly impacted by this ;) **Why - How did we end up in this state, etc.:** * The biggest issue here is simply that there are only so many things that we can work on at once. * The current priorities are to polish the "GP for Art" tools that are essential for the success of the Hero open movie project. There are quite a few outstanding "big ticket items" still outstanding on this front that we just have to prioritise first to make the production feasible. So, all efforts need to go to sorting out just that one thing first. Furthermore, given that this is one of the upcoming "big unique selling-points" for Blender (since no other major 3d platforms have something like this built in), we're dedicating effort to getting this right first and foremost, even if other cases have to suffer in the short term. ``` ``` * For an example of the current manpower limitations, over the past few weeks, we've basically been spending everyday basically tracking down and fixing a neverending stream of crashes and bugs arising from 1) the new functionality and integration with previously unintegrated systems, and 2) have to fix/update our code several times a day, 5 days a week, in response to a constant stream of code churn due to the big depsgraph-related cleanups (atm, barely a day goes by without at least another 2 things breaking there and needing attention) * Second, we're currently working in a branch (based off 2.8), that already has a large number of non-trivial changes in it. * In many ways, I'd probably go as a far as to say that there are probably too *many* changes in this branch already, and we should really just merge it all into 2.8 now and then slowly fix whatever carnage that may cause. (It'd probably be better than what we're doing now, as there'd be less stress on us to keep fixing stuff that keeps breaking from under our feet). * It's hard enough for us to keep on top of merge conflicts, but it's also harder for everyone in the long run keeping version-patching stuff from causing data loss for the production (we've had 2-3 subversion bumps for files already, with some of those having happened in parallel, and I'm sure we're going to keep running into these issues going forward). * It's also harder for everyone involved to review large branches, as there's just so much more code to go through, making code review an even more daunting chore than it is already. * Given that we're already operating in a rather big branch (that all the standard code review tools are already having trouble managing), it really doesn't make sense to begin any futher sets of major refactors on top of that (but which are kind of complementary / independent yet dependent), to further compound our problems. As a result, there are 2 other major refactors to GP-related stuff that are actually still pending until we can get the main bulk of changes mainlined into 2.8 (as originally planned at the start of the Hero project). (Note: Those two other refactors are, 1) "Annotations" for 2D editors, 2) The ability to edit GP keyframes and normal keyframes in the same Dopesheet views)

Thank you for your (very well documented) response, you answered all my concerns and I look forward to using the new GP (once it gets merged).

Thank you for your (very well documented) response, you answered all my concerns and I look forward to using the new GP (once it gets merged).
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Code Documentation
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
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
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
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
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
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
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
2 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#53633
No description provided.