[Bf-taskforce25] Grease Pencil - Review of UI for 2.5

Ton Roosendaal ton at blender.org
Fri Apr 17 15:23:36 CEST 2009


Hi,

1)

Using the current area/region context for every GP instance would make 
it very hard to control and store. When we looked at the topic on 
wintercamp, the obvious solution was to connect it to real data in 
Blender (objects, nodes, actions, etc). The system then can still get 
projected as usual, with optional full-region-align, but also with 
zooming (attach it to camera, and camzoom/shift works) or rotation 
possibilities (motion paths in custom plane).

Best part of this approach is that context will work, and sharing GP 
among multiple 3d windows will work naturally, split or not split. 
Enabling/disabling view of GP can still be per region somehow though...

GP can be a relinkable ID block. Why it didn't work I dunno, probably 
just a missing bit somewhere. Note that the MAKE_ID for this has to 
give a unique code. I can help fixing the issue though. :)

2)

If you implement painting as has been done with other paint tools now 
(= operator, converting itself to 'modal' while input happens), you can 
re-use this for both systems.

The main issue with "Draw Mode On" is is that you want to override 
existing keymaps in every editor then, but there's already a "priority 
handler" which inserts itself in the beginning of a handler queue.
A Notifier can detect such actions, and invoke a refresh() to 
add/remove handlers.

I don't grasp the third method really... as if you have a single 
operator running continiously? That seems to me not a desired 
situation. Every stroke best can be a single operator registry + undo.

-Ton-

------------------------------------------------------------------------
Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
Blender Institute BV  Entrepotdok 57A  1018AD Amsterdam The Netherlands

On 17 Apr, 2009, at 14:28, Joshua Leung wrote:

> Hi all,
>
> While 2.5 presents many new possibilities, it is also a good time to 
> have a second look at some existing tools. It has come to my attention 
> that there are several issues that would be worthwhile to review 
> before any porting work commences.
>
> 1) Storage of Grease Pencil Data -> Per region? Per Area? Per 
> Screen/Window? Attached to data? Library Data?
> In 2.4x, Grease Pencil data is stored per Area. This was based on the 
> idea that Grease Pencil sketches are meant to be used as temporary 
> annotations, that are really only valid for the context/view in which 
> they were created for. Following this logic, in 2.5, Grease Pencil 
> data should be moved down to per-region level in some cases (notably 
> 4-split 3D-View), though this does make context issues much more 
> complex to define.
>
> However, several critical issues have popped up regarding storage on 
> per-area instance level. The most critical of these it seems, is that 
> there seems to be a bit of user-interest in being able to have Grease 
> Pencil sketches that are able to be loaded up in difference instances 
> of some area. For example, when changing back and forth between two 
> screen layouts, it may be useful to be able to have some annotations 
> made while viewing one of these layouts (i.e. 3D-View in screen 1) to 
> be available for the other (i.e. another 3D-View in screen 2).
>
> Another issue is the limitation of not being able to annotate 
> screen-level items such as headers, etc. for potential uses in making 
> tutorials... The other critical issue, is the lack of undo support, 
> since data stored on screen level is very difficult to get undo 
> working for. 
>
> Therefore, my personal preference was (and still is) to make Grease 
> Pencil data library data (i.e. linkable datablocks). I should note 
> here that this would have happened already, had I not encountered a 
> nasty problem where the new datablock would just not show up in any 
> list of datablocks, despite having added most if not all of the 
> necessary code in the right places. (Perhaps it was just the choice of 
> ID code to be 'GP', right beside the existing 'GR' for groups?)
>
>
> 2) Method of Drawing
> Currently in 2.4x, there are two methods of drawing with Grease 
> Pencil: click-drag + modifier key, or by enabling 'Draw Mode On' (in 
> panel) and simply click-dragging, where (shift-)LMB-click-drag draws a 
> stroke regardless of mouse-selection preference, and 
> (alt-)RMB-click-drag being the eraser.
>
> A few notes about these methods.
> - The method using modifier keys is really quite problematic with many 
> of our existing keymaps, and is bound to keep causing problems, since 
> clicks are very easily misinterpreted resulting in Grease Pencil 
> either being skipped or overriding the intended action.
>  - The more modal method ('Draw Mode On', which takes priority access 
> to click events) is less ideal from our non-modal/non-blocking UI 
> paradigms. However, in practice, this is often more practical, since 
> when users start sketching, they're less likely to be drawing a single 
> isolated stroke, but rather a series of them. Using the first method, 
> they'd need to keep a finger depressing some key while they should be 
> concentrating on what to draw instead.
>  Personally, I prefer the 'Draw Mode On' method.
>
> However, with 2.5, this may prove a bit trickier to hack successfully. 
> It may be worthwhile to consider a third option. Headers/regions(?) 
> would get operator buttons which would activate the Grease Pencil 
> modal operator. Once this is activated, the user can draw multiple 
> strokes as per 'Draw Mode On', but the modal state keeps running at 
> the end of each stroke until the user explicitly cancels drawing with 
> Esc. We'd need some for of indicators (header prints?) that this was 
> running in a semi-mode, but normal view manipulation should still be 
> possible (though selection may be a bit difficult).
>
>
> Anyone have any thoughts regarding the presented ideas, or any 
> potentially better suggestions?
>
> Regards,
> Aligorith
> _______________________________________________
> Bf-taskforce25 mailing list
> Bf-taskforce25 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-taskforce25



More information about the Bf-taskforce25 mailing list