Grease Pencil Dev - FAQ's, Current Status, etc.

In response to a bug report in the tracker, I ended up posting a long-ish reply that I thought would be good for more people to see, since it probably gives a bit more insight into some of the work that's going on "behind the scenes" atm. So, without further ado, here's a copy of my reply.

(For more of a user-orientated look at what functionality we've been adding, check out Antonio's code.blender.org post)


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 (e.g. any 3d-specific simplifcation/etc.) 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 a significant part of every day 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 few 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, there are probably too *many* changes in this branch already. I've probably said it before, but will emphasize this again here, that IMO 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 with our own changes, I'm sure we're going to keep running into these issues going forward).
  • It's hard for the tools to manage (even the online diff viewer complains how big that patch is!). For example, "arcanist" almost always hangs and/or gives up here whenever I try to update the patch, so I have to manually diff the branch and then upload that diff to the tracker... that however, doesn't seem to completely work that well, as now you get leftover comments and other weirdness in places.
  • 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)

----------------------------------

Additional Notes:
* Some of you may be wondering when we'll be merging the GP branch into 2.8 - TBH, I'd like to know the answer to that question myself!  Originally we hoped to have this done in October, but the first round of code review identified quite a few major problems that needed to be resolved. Those problems have now been resolved, but between us constantly fixing things and adding new important features, and some "VIP's" pushing away full steam on other projects, we're still waiting on go-ahead for merging the functionality over

* As for the availability of builds - Since buildbot is only configured to do master/2.8 branches, there are currently no daily/nightly builds of the branch. However, when I get back to work in the coming weeks, I'll look into setting up a one-off custom build through the "experimental builds" infrastructure.  Unfortuantely it's a bit of a manual process that I'll need to look up the instructions for, hence why we can't currently offer this on a regular basis :(       Hopefully though, you'll soon be able to use this functionality in the 2.8 builds without waiting for a custom build to appear (fingers crossed! ;)