Page MenuHome

GPencil: Ghost point on selection
Closed, ResolvedPublicBUG


System Information
Operating system: Linux-5.10.0-6-amd64-x86_64-with-glibc2.31 64 Bits
Graphics card: GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 460.73.01

Blender Version
Broken version: 3.0.0 Alpha, branch: master, commit date: 2021-08-17 18:20, hash: rB88dc274d0533
Broken version: 2.93.0 Beta, branch: master, commit date: 2021-04-21 20:15, hash: rB0f66dbea904f
Broken version: 2.92.0, branch: master, commit date: 2021-02-24 16:25, hash: rB02948a2cab44
Broken version: 2.83 and up
Worked: 2.82

Short description of error
When selecting with box select, sometimes a weird point appears and stay until you want to take a closer look, but then it vanishes again. It appears to be sometimes black, sometimes orange and sometimes gray. Here are some screenshots:

The orange dot is not the origin, but at that location. I have also seen it jump to other places when selecting or even when doing completely unrelated things, so it seems to be a memory issue. Blender does not report unfreed memory in the console though.

Here is also one that appeared during weight painting, so it is colored, but this time neither at the origin nor in the drawing plane:

Exact steps for others to reproduce the error

  1. Add a grease pencil monkey
  2. hide 3D Cursor and Origins from overlay and enable Stroke Direction

From here there are several ways to recreate it. Everything that triggers a rebuild in editmode works.

  1. Drag box select very often and keep an eye out for the point at the origin
  2. toggle edit mode until you see it appear
  3. duplicate all the geometry in editmode multiple times and try selecting again. (most reliable to reproduce)

Was able to recreate this in a different file as well using the Stroke Primitive Object like in the screenshot.

Simple way to reproduce is: toggle edit mode

Event Timeline

Antonio Vazquez (antoniov) renamed this task from Grease Pencil ghost point on selection to GPencil: Ghost point on selection.Aug 17 2021, 10:50 PM

I cannot reproduce on my system and never noticed before this bug.

Can reproduce on master with described steps: rB24c16f54571fe948aa5c02f807ca23188b436764

Simple way to reproduce is: toggling edit mode
{F10287251} (video Added in task description)

Pratik Borhade (PratikPB2123) changed the task status from Needs Triage to Confirmed.Aug 18 2021, 8:40 AM

Might be caused by D8660, can't test that right now though.
I tried debugging it more using Overlay > Stroke Direction, and found that for all the cases where I got it, it was a red dot -> endpoint of a curve. I only got it about 5 times in total though, so might not be for certain.

It seems to be some uninitialized data in the VBOs passed to edit_gpencil_vert.glsl

Figured it out. @Antonio Vazquez (antoniov) if you try this patch you should be able to see the ghost appear:

diff --git a/source/blender/draw/intern/draw_cache_impl_gpencil.c b/source/blender/draw/intern/draw_cache_impl_gpencil.c
index 6ed4148a7fe..2c686b253b5 100644
--- a/source/blender/draw/intern/draw_cache_impl_gpencil.c
+++ b/source/blender/draw/intern/draw_cache_impl_gpencil.c
@@ -863,6 +863,7 @@ static void gpencil_edit_batches_ensure(Object *ob, GpencilBatchCache *cache, in
         NULL, ob, NULL, gpencil_edit_stroke_iter_cb, &iter, do_onion, cfra);
+    iter.verts[0].vflag = 0x12;
     /* Create the batches */
     cache->edit_points_batch = GPU_batch_create(GPU_PRIM_POINTS, cache->vbo, NULL);
     GPU_batch_vertbuf_add(cache->edit_points_batch, cache->edit_vbo);

The problem was that on the first vertex which is there for technical reasons the material was not initialized to -1. So a simple fix here is:

diff --git a/source/blender/draw/intern/draw_cache_impl_gpencil.c b/source/blender/draw/intern/draw_cache_impl_gpencil.c
index 6ed4148a7fe..e78e41b917a 100644
--- a/source/blender/draw/intern/draw_cache_impl_gpencil.c
+++ b/source/blender/draw/intern/draw_cache_impl_gpencil.c
@@ -446,6 +446,8 @@ static void gpencil_batches_ensure(Object *ob, GpencilBatchCache *cache, int cfr
     for (int i = 0; i < 2; i++) {
       iter.verts[iter.vert_len + i].mat = -1;
+    /* Also mark first vert as invalid. */
+    iter.verts[0].mat = -1;
     /* Finish the IBO. */
     cache->ibo = GPU_indexbuf_build(&iter.ibo);

@Pratik Borhade (PratikPB2123) I cannot reproduce it...could you test the fix? For me the fix is logic, but I cannot test it.

@Clément Foucault (fclem) do you see any problem with the proposed fix?

Antonio Vazquez (antoniov) changed the subtype of this task from "Report" to "Bug".Aug 18 2021, 11:35 PM

could you test the fix?

Hi @Antonio Vazquez (antoniov) , this is something I tried on lite debug build (will try with full build) and issue does not happen even without the proposed fix.

Might be caused by D8660, can't test that right now though.

Also: Can not reproduce with 2.92 (2021-02-24) so I don't think mentioned patch is the actual cause for the issue

@Pratik Borhade (PratikPB2123) It's probably caused by D6293 which introduced that file. The best way to recreate the issue seems to be duplicating all strokes, since it is likely to be using to a new memory location in that case. That way I could even recreate this issue in 2.90.1 and 2.83 but not in 2.82

Henrik Dick (weasel) updated the task description. (Show Details)