Page MenuHome

Annotations don't move with the Canvas in UV editor or Image editor
Closed, ResolvedPublic

Description

System Information
Operating system: Windows-10-10.0.17134 64 Bits
Graphics card: GeForce GTX 1060 6GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 417.71

Blender Version
Broken: version: 2.80 (sub 53), branch: blender2.7, commit date: 2019-04-02 19:53, hash: rBa813e259d630
Worked: 2.79

Short description of error
In 2.79 the greasepencil annotations in the UV/Image editor would move with the image as you pan across the 2d canvas. They don't in 2.8. In 2.79 you could replicate that behaviour by changing Stroke Placement in the greasepencil options in the toolbar, but it's not the default. In 2.8, the annotation tool in either the UV or the Image editor doesn't have this option, not in the topbar nor the tool properties. I guess the bug is more about surfacing that option back, and making the same default.

Exact steps for others to reproduce the error
From a new file, go to the UV or Image editor and draw with the Annotation tool, either by selecting the tool in the toolbar or by holding D. Use middle mouse click to move pan the 2d view, and the annotations don't move

Details

Type
Bug

Event Timeline

Sebastian Parborg (zeddb) triaged this task as Needs Information from User priority.

This works for me the same way as it does in the latest 2.79:

With picture:

Without picture first:

Anyhow, I'm guessing that this is about it not locking when you draw without a picture present first and no ability to change this setting yourself?

@Sebastian Parborg (zeddb) I have checked again and the trick is to create the image before do the annotation.

Works:

  1. Create Image
  2. Do annotation
  3. Move

Don't Work:

  1. Do annotation
  2. Create Image
  3. Move

As this is working as it was in 2.79, we can't consider it as bug, no?

@Antonio Vazquez (antoniov) it depends on if this is how it is supposed to work or not. If this is how it was designed to function, then this is not a bug.

@Sebastian Parborg (zeddb) We can consider that it was designed in this way, because this code was ported from 2.79 (not using the same code of grease pencil).

Sebastian Parborg (zeddb) claimed this task.

Sure.

@Wo!262 (wo262) if this does not work the same way as described here, feel free to reopen.

What seems to be truly happening is this;

-If you start with an image, great! It locks!

-But If you don't start with an image, or start with an image but then switch to a 2d view without an image and then annotate, every subsequent stroke, even when you open a new Image in a different 2d editor, doesn't lock the strokes in any 2d view for the entire blendfile ever again.

In 2.79 you at least can change it after in the toolbar, what kind of stroke you want (It's called Stroke placement, view/cursor) in 2.8 you can't. You can only make a new blend file and make sure you accidentally never anotate in a 2d view without an image

I propose to bring the option back, to appear in the topbar, the same way that the Annotation tool in the 3D view already does with the Placement option. And for the default behavior of a new 3d view to be locked to the canvas

Wo!262 (wo262) reopened this task as Open.Apr 9 2019, 10:09 PM
Sebastian Parborg (zeddb) raised the priority of this task from Needs Information from User to Confirmed, Medium.

@Antonio Vazquez (antoniov) I'll let you decide what to do with this.

That's right, It's because you can't draw (in 2.79) on an empty image, so it reverts to the View. I'm not sure if there are technical reasons to this, the strokes are still visible after removing the image.

You can see this with 2.79:

  • Open U/V Image Editor
  • Open Toolbar (Stroke placement should be on cursor)
  • Start drawing and watch it switch to view.

The same thing is happening in 2.80, it's just that we can't see the options...

And for the default behavior of a new 3d view 2D editor to be locked to the canvas

Did you mean 2D editor?

IMHO the best solution would be check if there is an image, and if empty, show a warning and cancel annotation.

Ideally I think it should just always stick to the canvas. If you are making notes for UVs that's what you'd want too.

I can't think of any use-case for the current behavior where annotations are relative to the view and not the canvass - we don't do this in the 3D View either.

In the 3D view at least it's not the default behavior. Can't really think why one would ever stick annotation lines to the view.

For the UV Editor we could just mirror what we do in the 3D View: By default always attach to canvas/UV space, and have an option to use View.

I agree. Even without an image I make annotations on the positions of UV islands, which needs canvas lock. So the idea of the warning is not ideal either, Annotations definitely have use without an Image open.

In the 3D view at least it's not the default behavior.

Sorry, I saw an opportunity and I seized it. But it is default behaviour as I explained in T63402#657727

Can't really think why one would ever stick annotation lines to the view.

There are a few reasons why View Placement is important:

  • Stroke will stay the same when switching images with different resolutions. Strokes warp/distort on the curser.
  • Cursor (Canvis) stroke can't move editor. It's handy having your notes/doodles follow you around from editor to editor.
  • View Placed (2D) Annotations don't suffer from the same issues as Cursor (3D) strokes:

Different execution but the same Idea...
https://cloud.blender.org/p/gallery/5beeaec4527ba54c2fe6fbf8

For the UV Editor we could just mirror what we do in the 3D View: By default always attach to canvas/UV space, and have an option to use View.

This is the most rational thing I've heard.

But goal should be to give Annotations (across editors) the same set of tools.

I have been looking at the code (I did not created this area) and I have seen there was an hacky special case for image editor when the image was NULL. The rest of 2D editors always set the annotation locked to canvas (affected by zoom) and never to Screen.

My opinion is to do the same for all 2D annotations and always set to Canvas and never to View. Actually in 2.79 you can select if lock to screen or Canvas, but this is something that came from old grease pencil. I don't think is very user friendly to have two options.... really we want add complexity to UI for a corner case?

How are you making the UX more complicated? I'd argue it's more complicated now because there's no consistency in the Annotations Tool.
The topbar is Empty and we're talking about removing an option we already don't have...

always set to Canvas and never to View.

So what would you intend to do with all the View Placement GPencil data in 2.80's Annotations?

What I want to do is keep all 2D editors equal. Today we have a "special" case for Image editor and the rest of 2D editors working differently. The logic, it's to set all 2D editor equal and remove the screen option. It's very weird that you draw an annotation and when you move/zoom the annotation does not move.

If we add a button to define the type of placement, you can add strokes to Screen and to View and it's very confusing to have strokes that moves and others don't. The idea is to make annotations simple.

@Christopher Anderssarian (Christopher_Anderssarian) We cannot use the Topbar because we have only one for screen. If you have a 3D view and a UV editor, you cannot detect what annotation datablock are you using.

What I want to do is keep all 2D editors equal.

Yes, that's what I'm saying.

Today we have a "special" case for the Image editor and the rest of 2D editors working differently.

Ah, this is where the confusion may be:

There shouldn't be a distinction between the Image editor and the rest of 2D editors. This is wrong.

Currently All editors implement Annotations differently:

Name3D ViewportU/V Image Editor (View)U/V Image Editor (Paint)U/V Image Editor (Mask)Video sequence EditorMovie Clip EditorNode editor
Image
NotesMost worked on most completeThere's no mention on any todo list...on todo list
Topbar works?YesShows, doesn't workNoNoNo, N/A, No toolbarShows, doesn't workNo
Toolbar?Yes, NewYesYesDoesn't existDoesn't existOld GPencil Implementation (on todo list)Yes, New
Onion SkinYesNoNoNoYesNoNo
Can draw on viewYesYesYesYesNoYesYes

Requisite blend file:


It's very weird that you draw an annotation and when you move/zoom the annotation does not move.

How is this weird?

Different execution but the same Idea...
https://cloud.blender.org/p/gallery/5beeaec4527ba54c2fe6fbf8


If we add a button to define the type of placement, you can add strokes to Screen and to View and it's very confusing to have strokes that moves and others don't.

But this is up to the user, with clearly labeled tooltips as to what's going to happen.

The idea is to make annotations simple.

Yes, what I'm saying is that right now it's not simple. Look at the blend file and all the issues listed.


@Christopher Anderssarian (Christopher_Anderssarian) We cannot use the Topbar because we have only one for screen. If you have a 3D view and a UV editor, you cannot detect what annotation datablock are you using.

But that's not a Grease Pencil/Annotations issue that's a UI/UX Issue. If/once that's fixed and the active tools are added to added to the editors then there's space and workflow for other options...


Okay the bottom line:


I do not have a problem with removal of features or functionality, as long as it's replaced with something that works. I really do not see this happening before 2.80 release.

IMHO, change annotations is not a primary task for 2.80. Maybe, we could close this task report because the problem is fixed now and open a new task with Annotation ToDos (not only the topbar and space issues).

is not a primary task for 2.80.

I know and that's why I didn't report this months ago (and why I don't report all of the bugs/issues/crashes that I still put up with today, because I know it will get removed)

Maybe, we could close this task report because the problem is fixed now and open a new task with Annotation ToDos (not only the topbar and space issues).

This sounds like a good course of action.


@Antonio Vazquez (antoniov) Before this task is closed, can I ask you: Do you at least see where I'm coming from? (just in case)

@Christopher Anderssarian (Christopher_Anderssarian) I understand your points, but we need at some point stop to add things and try to stabilize all. For sure there are a lot of things to fix, but we try to get something good enough... you know, the resources and time are limited. Anyway, it's my opinion only... I'm not part of BF.

As the main problem of this task is solved, we can close it.