Grease Pencil scaling issues through multiple editors.
Closed, ArchivedPublic

Description

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

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

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)

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

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 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.

Details

Type
Bug
Joshua Leung (aligorith) closed this task as Archived.

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).