[Bf-committers] About design on grease pencil object

[Jason van Gumster]

It appears that there are two somewhat diverging use cases for the same basic
code core: drawn animation in the 3D view and annotation in other editors. Both
require the same basic tools (drawing and keyable changes), but how those tools
are applied can be quite different.

All that said, I have a perhaps stupid question: From an interface and design
perspective, does it make sense to refer to both of these as "Grease Pencil"?
Perhaps it's worth it to consider using the Grease Pencil moniker for
animating in the 3D View and a different name for annotation uses (or vice
versa).

This could help avoid the confusion that some folks may run into when trying to
decide which Grease Pencil someone it talking about.

Just an idea.

  -Jason

/me slinks back off to the lurker booth

<blendergit at gmail.com> wrote:

> Hi Joshua,
> 
> After Reading your complete explanation mail and Tom and Thomas comments, I
> think we must keep scene GP.  
> 
> About mixing scene and object data in the UI panel, the solution we used was
> to move from properties panel to the corresponding scene panel (scene gp)
> and object data panel (object gp) similar to empties. With this approach the
> artist does not need to keep properties panel open and get more drawing space
> (colors was moved to tools panel). You can see an example data panel in this
> document: https://drive.google.com/drive/folders/0B7anLZKLJn4SWnFpenFMbHFUdEU
> 
> Main concern is if the 2D drawing can make too complex the system and if is
> it really necessary all the new stuff in these modes. If we add new shaders,
> batch drawing, etc, really we need all these in 2D? Maybe as you comment, for
> 2D we must back to old system with simple colors and brushes, but this will
> need a code rework.
> 
> For 3D mode, the idea is to move all code from drawpencil.c to the draw
> manager folder as a new engine, making all using new shaders and batch mode,
> using caches to improve speed where possible. Maybe, in the future the gp
> tool will be used to create big animations, so we need a robust design to
> manage these big scenes. 
> 
> Talking yesterday on IRC with Severin and Hypersomniac we evaluate the
> possibility to keep 2D drawing using imm mode and move to drawing manager
> only 3D stuff, but it was only an initial idea and need further analysis.
> 
> Thanks for all the comments.
> Antonio
> 
> 
> De: Joshua Leung
> Enviado: viernes, 7 de abril de 2017 6:02
> Para: bf-blender developers
> Asunto: Re: [Bf-committers] About design on grease pencil object
> 
> Hi Antonio,
> 
> First, I agree that it's a good idea to be moving towards haivng a
> dedicated "Grease Pencil Object" type. For "full hand-drawn animation" in
> 3D, that is useful and necessary. The biggest benefits are:
> i) *We can have a dedicated "Draw Mode"* - Instead of having to hold down
> any modifier keys, clicking/tapping with a mouse or pen will just draw
> (i.e. think "Sculpt Mode", "Texture Paint Mode", etc.). For artists doing a
> lot of dedicated drawing, that is a HUGE productivity boost (and more
> ergonomic). Plus, we don't need to worry about things like adding ways to
> disable/remap the 3D cursor positioning, to avoid accidentally moving it
> and runing drawings.
> ii) *Easier Instancing of Drawings* - With a Grease Pencil object, we can
> use all the well-established techniques for duplicating and repeating
> objects in different places (e.g. duplicate/link duplicate objects,
> dupliverts, particles?, etc.).  As Mattias demonstrated the other day, this
> is useful for things ranging from having an army of hand-drawn warriors
> marching around, to placing trees and foliage on a hillside.
> iii) *More Natural Handling of Parenting/Transforms* - With the layering
> parenting, it's become a bit of a mess with transforms having to be
> calculated, applied/unapplied per layer in many places, to replicate
> functionality that's available with Objects + Object Data naturally for all
> the other geometry types.
> iv) *Use of the Object System to Manage Data* - Finally, we can take
> advantage of the object system to manage characters vs props vs
> backgrounds, instead of trying to use the GP layers to take care of all of
> it. Maybe if they could be hierarchical instead (i.e. a big can of worms;
> for starters, the list widgets would be need to become trees :) the layers
> might still work, but it's simpler just to rely on some existing mechanisms
> instead of adding more complexity.
> v) *A natural approach for *"*Drawing Planes"*?
> 
> All this is fine and good. It's a natural evolutionary step towards
> integrating this type of asset (i.e. hand-drawn animated assets) into 3D
> scenes as a first-class citizen. :)
> 
> ------------
> 
> However, I'm still very much on the fence about whether we should abandon
> Scene-level annotations. You're right that in terms of mental models,
> keeping it around *might* (and that's a big might) be one to many
> conceptual hurdles for people to get their heads around. That said, I'm
> currently not convinced yet that removing it is 1) necessary, 2)
> beneficial, and 3) the best course of action.
> 
> It's somewhat ironic that we're talking about going from having
> Scene-anchored GP to object-anchored GP *again*, as just 2-3 years ago, we
> were making the opposite switch after years of using object-anchored GP
> since the early 2.5 days ;). Sure, last time we also had the additional
> problem of only showing the GP data attached to the active object being
> visible. However, I think some of the arguments we made last time still
> hold about scene-anchored being simpler to manage (for some use cases).
> 
> *Pros of Keeping Scene GP*:
> 1) *Scene GP works better for the Annotation/Drafting Workflow*s - Right
> now, it is possible to use Grease Pencil to annotate the workspace while in
> any mode, with any object selected. With what you're proposing (i.e. with
> no GP object set, if you hold down D and start drawing, it will create a GP
> object in the scene and add your strokes to it), there are a few issues:
>     a) What happens if you suddenly add an extra GP object to the scene?
> Which one of the two will it add strokes to if the active object is not a
> GP object?
>     b) If you decide which datablock should recieve the strokes based on
> the name of the datablock, IMO, it's really not that great to have
> hardcoded hidden/implicit conventions in places to make things work. (It
> was one of the issues I had with some of the stride follow stuff)
>     c) This breaks the UI principle that you're always operating on data
> from the active OR selected object(s) only. For example, when you're in
> editmode on a mesh, and want to add/remove annotations, it's fine when
> Scene GP is used (i.e. not an object, scene/world-level stuff is getting
> modified), but with Object-GP you end up editing an arbitrary object's data
> while actively work on another.
> 
> 2) *Less Workflow Overhead* - With Scene GP, you can keep everything
> together in the same datablock until you figure out how you want/need to
> partition the data to better manage it. In other words, creative freedom
> and flexibility. With Scene GP present, you can still later decide to
> assign your scene GP datablock to a GP object (much like you can change
> which mesh datablock an object uses), and then carry on as if you'd started
> that way from the beginning.
> 
> However, Object-GP gives off a different vibe - that of being a much
> stricter/more structured way of working, where you're forced to figure out
> up front how you want to manage your data.
> 
> 3) *Continued Testing of Annotation Workflows* -  This point probably goes
> both ways, but by keeping Scene GP around, it is more likely that stuff
> that doesn't work well with non-object GP workflows (i.e .stuff that won't
> work well in the other editors) is less likely to go unnoticed. Even now,
> we already have that problem -- the workflow for colour palettes and brush
> types stuff works pretty terribly for all the 2D editors, and is in many
> ways overkill  (TBH, I'm increasingly thinking that for those places, we
> should just roll back to using the old layer-bound color + thickness
> options, though there are problems with doing that from a drawing-code
> perspective).
> 
> 4) *Sketched-Based Input for Tools/Addons* - For stuff like modelling tools
> or posing tools which use sketched lines as input, again, it's not that
> nice that we have to go around digging for some other object in the scene
> that has the sketch data we need (and/or having that manage that object).
> Keeping thing scene-level makes it easier to manage (i.e. you can just do a
> "C.scene.grease_pencil" to get the data, if "C.active_gpencil_data" isn't
> giving you want you need).
> 
> 
> *Cons of Keeping Scene GP*:
> 1) *Potentially Confusing UI (Properties Editor vs View Properties Region)*
> - With Object GP, the properties editor will show GP settings under one of
> its tabs. This could get confusing when Scene GP setting still get shown
> via the viewport properties region(s). The "obvious" fix is therefore to
> simply get rid of Scene GP so that this conflict doesn't show up. Which is
> probably how we got here :)
> 
> However, this ignores that all the other editors where GP annotations may
> occur (e.g. Sequencer, Image/UV Edit, Masks/Tracking, Nodes, and soon
> Animation Editors) will still need to have panels showing the options for
> the GP datablock being used there for annotations. You're still going to
> get a bit of that confusion happening in some cases. But, keeping Scene GP
> just means that there is still a clear + consistent workflow for annotating
> stuff across editors.
> 
> 2) *Code/Keymap Overheads* - It means we have to keep one more codepath
> viable and functioning. Given the trouble we have so far with no
> clobbering/crippling the 2D editor GP workflows with 3D-art centric stuff,
> maybe this is a legitimate concern :(
> 
> 
> ---------
> 
> Regards,
> Joshua
> 
> 
> On Fri, Apr 7, 2017 at 6:41 AM, <blendergit at gmail.com> wrote:
> 
> > Hi,
> >
> > As you probably know, we are working to implement new grease pencil object
> > and the use of new draw manager and more new gp stuff.
> >
> > Recently, I uploaded a new branch “greasepencil-object” base on
> > “blender2.8” branch to blender.org git server with the code we are
> > working on.
> >
> > Daniel M. Lara (pepeland), Matias Mendiola and I have been thinking in a
> > better workflow and we have found some topics that need a decision. I had
> > some conversation on IRC about them, but I want to share them in the
> > mailing list and get more feedback before take any action:
> >
> >
> > 1) Currently, in 3D view you can create GP strokes at scene or object
> > level. With the new grease pencil object, it not makes sense to have GP at
> > scene level and we can remove it.
> >
> > To have GP at scene level only adds complexity to design and make more
> > confuse the use of grease pencil for artists. There is only a concern about
> > add-ons that are using grease pencil at scene level, but as Blender 2.8
> > will require a review of current add-ons, we think this is not a big issue.
> >
> > Of course, the old files with grease pencil at scene level will be
> > converted to new grease pencil object when they are opened in Blender 2.8.
> >
> > 2) Grease pencil has two uses, animation and annotations. Annotations in
> > 3D can be supported by the automatic creation of a GP object (this is the
> > approach of other 3D programs of the market). Besides, the use of GP object
> > for annotations adds functionalities as hide, move, scale, rotate,
> > organize, etc.
> >
> > For 2D annotations (Node Editor, VSE, etc.) we can keep a basic
> > functionality, but we will not support new drawing features, only basic
> > support to add notes.
> >
> > The availability to draw animations in different context is a source of
> > misunderstanding for new users. We think to keep the animation workflow in
> > the 3D viewport is the way to follow.
> >
> >
> > We would like to hear your opinions and ideas.
> >
> >
> > Best Regards,
> > Antonio Vazquez (antonioya)
> >
> >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > https://lists.blender.org/mailman/listinfo/bf-committers
> >  
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers