The FX are working in Screen Space, so any change in the viewport or camera angle will change the final result. Really, FX will work as compositor using the final render/viewport image and apply a filter on it. If you chnage image, you get different result.

I've reverted this change because it was only supposed to affect grease pencil, but also ended up affecting sculpt mode. This then spawned long discussion about the ideal cursor shape, and that's really not the simple and safe change I approved. Since this has not been quickly resolved I'm reverting the commit.

Already committed with @Brecht Van Lommel (brecht) suggestions.

I haven't noticed this problem with recent versions!

Just tried on the same computer with Windows 7 64 bits, it does not happen there.

Is this still an issue with the latest beta?

I cannot reproduce on Windows 10 64 bits RTX2080 TI

This was fixed quite a while ago.
But I'll let the Mod Mafia close as resolved :)

In T62565#697894, @Brecht Van Lommel (brecht) wrote:

As I understand it, @JoshBowman (JoshyB) says this change in gpencil_draw_apply_event worked:

     /* No tablet data -> No pressure info is available */
-    p->pressure = 1.0f;
+    p->pressure = 0.0f;

So that would mean either some mouse move events are missing tablet that, and the release event is not the issue. Or the release event pressure is somehow used elsewhere and affecting the stroke. If someone can run blender with --debug-events from the command line and paints a single problematic stroke, then we can see in the output which it is.

and these are the registered events for a single stroke in console

@Brecht Van Lommel (brecht),
i have drawn 3 strokes. All affected by the pressure issue.
here is the console output for the events:

As I understand it, @JoshBowman (JoshyB) says this change in gpencil_draw_apply_event worked:

     /* No tablet data -> No pressure info is available */
-    p->pressure = 1.0f;
+    p->pressure = 0.0f;

@Brecht Van Lommel (brecht) The events are filtered with the code below:

Probably painting operators should never use the release event mouse coordinates or pressure to draw anything? In principle there should be a mouse move event preceding it, and then the release event should merely stop the painting, not define the last part of the stroke.

@William Reynish (billreynish) I would do if I could reproduce it. I have seen the problem is the line if (event->tablet_data) { (gpencil_paint.c) is not getting data when you use that type of tablets, but if we move the value of 0.0 in the else, then the mouse will not work.

@Antonio Vazquez (antoniov) Can you look at this issue? It seems like there is a solution for pen input - probably we just need to detect if you are using mouse or pen, which we already do anyway.

@Konstantin Bukow (Kobuk) I've just followed the docs to compile my own version of 2.8 with the change you suggested and it works perfectly THANK YOU I'm super excited because it means i can continue development of my Grease Pencil based character rig!

Just to add; if as before, a solid fill object is added to a background layer - the hue is normalised.

There's now quite a hue error for semi-transparent objects:

Hello people! I'm super-happy that my hack could help others to make their pens work correctly with blender! I don't know how to implement a clean solution which would let the mouse keep working. I still think that setting the pressure level to 0 at every release might work, but unfortunately I couldn't find out how to do that. I'd be even more happy if the real devs could find out a solution that helps everybody with not-wacom tablets to be using the GP, as a lot of other blender users might be working off finacial constraints. Let's hope everybody will be happily drawing very soon. Best regards everybody!

Committed in a412f49e7580

• Update some tools with the new cursor to keep consistency.

In D5036#114743, @William Reynish (billreynish) wrote:

@Antonio Vazquez (antoniov) Well yes, if you use a Cintiq/iPad Pro style device, you have no use for the cursor at all, so it really should be a general thing.
The main issue is, I suppose, that if you accidentally enable this option when using a mouse, your cursor will disappear and it will be hard to re-enable it if there is no cursor :)
Ideally I suppose we should make it smart, so that it could somehow detect the input device, although that may not always be possible.

I think is possible detect if you have a tablet device connected, so the hide cursors only must work if this device type is detected.

@Antonio Vazquez (antoniov) Well yes, if you use a Cintiq/iPad Pro style device, you have no use for the cursor at all, so it really should be a general thing.

Example in Windows:

Later, we should probably add an option to completely hide the cursor, if you are using a direct input device, such as a Cintiq or iPad Pro, or other similar devices for input.

This works well I think.

We need a review to be sure we don't break or missing anything.

The diff file isn't working.I'm getting the errors

This appears to be fixed now.

I think the problem originates in the use of rna_Brush_gpencil_tool_items. I guess it is using the names of annotation brushes. At least BKE_libblock_find_name returns a brush without gpencil_settings for "Erase". This is the brush that causes the crash I described further up. Otherwise I don't experience any crashes.

My understanding is that with the latest code in master, the brush pointers would simply become NULL. If that still causes a crash, it means there is an issue in other code, because Blender code should assume that any datablock pointer can become NULL on file read or after scene edits

Committed reworked patch at rBbbaa1bffe9d. The issue is now expected to be solved.

I will take a look

@Antonio Vazquez (antoniov) Can you at least fix the crashing for Primitives like you did for the main Grease Pencil tools?
If there is a invalid brush, for whatever reason, I'd be more comfortable if Blender did nothing, rather then crash...
Opening up the original supplied .blend in your build should show the crash on using the Primitive tools...