[Bf-committers] About design on grease pencil object

[Ronan Ducluzeau]

I think that the main difference is 2D VIew / 3D View.

Contrary to Curve Object where user can switch object from 2D to 3D or 3D
to 2D, actual Grease Pencil datablock dimensions are defined at creation
without switching ability.
In GP branch, we can add 2D View strokes to a 3D GP object or assign a GP
datablock from a 2DView.
As a result, transformation of this GPobject in 3DView may make no sense on
2DView strokes.
At least, it is counter-intuitive at all to move an object on XY plane or
rotate it on Z to modify strokes in a different view plane.

I think that 2DView strokes for annotation can make sense in 3D view for
Camera Views or views locked to objects.
It looks like background images and Image drawing by empties.

I will prefer that 2DView strokes were considered as a different datablock
type to avoïd confusion.
But being able to convert 2DView strokes to a 3D GP object projected on XY
plane of object axis would be useful.

Thomas Beck is right. There are artistic uses of 2D Grease Pencil in Video
Sequencer Editor, Image Editor or Movie Clip Editor.
But It will make no sense to display brushes panels to annotate.
We could imagine that for 2DView strokes, basic brush would be used with a
basic UI to define thickness, stroke quality and color.
And at the moment, that an option will be enabled, advanced UI will be used
for artistic uses.

About GP branch, I have another problem to mention.
I tried to duplicate a set-up armature+GP Object.
Of course, secondly created GPobject was relative to wrong armature.
It looks like a 2.8 problem. Same kind of problem exists also for
Mesh+Armature set-up.
But does it make sense to keep parenting by GPlayers ?
It would be logical that parenting to an armature would assign layers to
bones with same names like for vertex groups.

I have glitch when I reload Startup file.
3D view regions are closed and Info editor header is empty. All is back to
normal if I resize Info Editor.

2017-04-07 21:18 GMT+02:00 Jason van Gumster <fweeb at monsterjavaguns.com>:

> 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
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>