Small object are not selected with Box Select tool #63356

New Issue

Marek Moravec · 2019-04-07T09:37:49+02:00

Marek Moravec commented

2019-04-07 09:37:49 +02:00

System Information
Operating system: Windows-10-10.0.17134 64 Bits
Graphics card: GeForce GTX 970/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 388.13

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

Short description of error
Objects that are too small to be visible in the viewport don't get selected with Select Box tool. Other selection tools like Circle Select or Laso Select work as expected. The problem exist in all viewing modes (wireframe, solid, eevee). In Blender 2.79 all objects get selected no matter how small they are.

Exact steps for others to reproduce the error
Select-Small-Objects.blend

Open the attached blend file. There are two cubes, one with scale 10, the second with scale 0.01.
Zoom out to see the larger cube.
Select the large cube to make it active.
Box Select both cubes. The small cube does not get selected.
Select the small cube to make it active.
Box Select both cubes. Both cubes get selected.

**System Information** Operating system: Windows-10-10.0.17134 64 Bits Graphics card: GeForce GTX 970/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 388.13 **Blender Version** Broken: version: 2.80 (sub 53), branch: blender2.7, commit date: 2019-04-02 19:53, hash: `a813e259d6` Worked: 2.79 official **Short description of error** Objects that are too small to be visible in the viewport don't get selected with Select Box tool. Other selection tools like Circle Select or Laso Select work as expected. The problem exist in all viewing modes (wireframe, solid, eevee). In Blender 2.79 all objects get selected no matter how small they are. **Exact steps for others to reproduce the error** [Select-Small-Objects.blend](https://archive.blender.org/developer/F6916510/Select-Small-Objects.blend) 1. Open the attached blend file. There are two cubes, one with scale 10, the second with scale 0.01. 2. Zoom out to see the larger cube. 3. Select the large cube to make it active. 4. Box Select both cubes. The small cube does not get selected. 5. Select the small cube to make it active. 6. Box Select both cubes. Both cubes get selected.

Marek Moravec commented

2019-04-07 09:37:49 +02:00

Added subscriber: @Traverso

blender-admin commented

2019-04-07 09:37:49 +02:00

#71031 was marked as duplicate of this issue

blender-admin commented

2019-04-07 09:37:49 +02:00

#70692 was marked as duplicate of this issue

blender-admin commented

2019-04-07 09:37:49 +02:00

#70108 was marked as duplicate of this issue

blender-admin commented

2019-04-07 09:37:49 +02:00

#69832 was marked as duplicate of this issue

blender-admin commented

2019-04-07 09:37:49 +02:00

#69802 was marked as duplicate of this issue

blender-admin commented

2019-04-07 09:37:49 +02:00

#66333 was marked as duplicate of this issue

blender-admin commented

2019-04-07 09:37:49 +02:00

#59153 was marked as duplicate of this issue

blender-admin commented

2019-04-07 09:37:49 +02:00

#64606 was marked as duplicate of this issue

Sebastian Parborg commented

2019-04-07 21:55:55 +02:00

Added subscribers: @brecht, @ZedDB

Brecht Van Lommel was assigned by Sebastian Parborg

2019-04-07 21:55:55 +02:00

Sebastian Parborg commented

2019-04-07 21:55:55 +02:00

@brecht who to assign this to?

Brecht Van Lommel removed their assignment 2019-04-09 13:29:23 +02:00

Campbell Barton was assigned by Brecht Van Lommel

2019-04-09 13:29:23 +02:00

Brecht Van Lommel commented

2019-04-09 13:29:23 +02:00

Added subscribers: @fclem, @ideasman42

Brecht Van Lommel commented

2019-04-09 13:29:23 +02:00

Not sure if this is for @ideasman42, @fclem or someone one else. Or if this is some known limitation of new selection code.

Campbell Barton commented

2019-05-02 06:31:09 +02:00

This is a limitation in OpenGL Queries (2.7x has this issue too).

Setting as low priority since it's not a regression in occlusion queries.

Possible solutions I can think of aren't especially nice:
,

Draw vertices & edges when selecting (not just the surface geometry).

While this guarantees correct selection, it's extra drawing to support this corner case.

Patch for mesh drawing: {P963}

Enable 'Center Points' for unselected objects.
Detect object bounding boxes that approach 1x px screen-space scale and use a different drawing method when selecting.

This is a limitation in OpenGL Queries (2.7x has this issue too). Setting as low priority since it's not a regression in occlusion queries. ---- Possible solutions I can think of aren't especially nice: , - Draw vertices & edges when selecting (not just the surface geometry). ``` While this guarantees correct selection, it's extra drawing to support this corner case. ``` ``` Patch for mesh drawing: {P963} ``` - Enable 'Center Points' for unselected objects. - Detect object bounding boxes that approach 1x px screen-space scale and use a different drawing method when selecting.

Campbell Barton removed their assignment 2019-05-02 06:31:23 +02:00

Brecht Van Lommel commented

2019-05-14 16:52:34 +02:00

Added subscriber: @senteria

Brecht Van Lommel commented

2019-05-29 04:17:58 +02:00

Added subscribers: @CMalcheski, @mont29

Germano Cavalcante commented

2019-07-02 14:23:22 +02:00

Added subscriber: @Rawalanche

Ludvik Koutny commented

2019-07-02 14:42:00 +02:00

Low priority? Really? This behavior can have severe, sometimes even devastating effects when unnoticed.

When you spend for example significant amount of time cleaning up some complex imported model, miss out on a few small pieces, do not notice and either save file and reopen after or run out of the undo steps, you may end up having wasted up to hours of work.

Low priority? Really? This behavior can have severe, sometimes even devastating effects when unnoticed. When you spend for example significant amount of time cleaning up some complex imported model, miss out on a few small pieces, do not notice and either save file and reopen after or run out of the undo steps, you may end up having wasted up to hours of work.

Maciej Niezgódka commented

2019-07-02 14:53:10 +02:00

Agree, this is big bug. Unacceptable for stable release.

Philipp Oeser commented

2019-07-02 15:24:01 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2019-07-02 15:24:01 +02:00

Issue came up in #65856 as well, just wanted to note we have #64282, where #64281 (Option to lasso-select using geometry instead of object centers) was added.
So maybe we should add the opposite there as well? [selecting object centers with box select]

Issue came up in #65856 as well, just wanted to note we have #64282, where #64281 (Option to lasso-select using geometry instead of object centers) was added. So maybe we should add the opposite there as well? [selecting object centers with box select]

Campbell Barton commented

2019-07-03 02:00:35 +02:00

@fclem mentioned conservative rasterization would solve this, however I could only find a reference to the nvidia extension .

We could enable the extension on nvidia & use a geometry shader for drivers which don't support this, however this adds a performance penalty for all selection, so we'd need to see if it's significant or not.

@fclem mentioned conservative rasterization would solve this, however I could only find a reference to the [nvidia extension ](https://developer.nvidia.com/content/dont-be-conservative-conservative-rasterization). We could enable the extension on nvidia & use a geometry shader for drivers which don't support this, however this adds a performance penalty for all selection, so we'd need to see if it's significant or not.

blender user #1436282 commented

2019-09-12 20:39:28 +02:00

Added subscriber: @Linuz

blender user #1436282 commented

2019-09-12 20:39:28 +02:00

again another report by me, found ^ this original report this evening now,

as I'm working with blender it IS really an annoying problem which needs to be fixed, and causes serious problems while f.e. grabbing selections

pls close my report as duplicate of this one:
https://developer.blender.org/T69802

again another report by me, found ^ this original report this evening now, as I'm working with blender it IS really an annoying problem which needs to be fixed, and causes serious problems while f.e. grabbing selections pls close my report as duplicate of this one: https://developer.blender.org/T69802

Brecht Van Lommel commented

2019-09-13 09:25:33 +02:00

Added subscriber: @clepsydrae

john bogren commented

2019-09-13 10:38:35 +02:00

Added subscriber: @Gossepojk

john bogren commented

2019-09-13 10:38:35 +02:00

Hello, I have to agree with the people above.
This bug results in a lot of mistakes and lost objects.

Really appreciate the work you are doing with the software though!! :)

Hello, I have to agree with the people above. This bug results in a lot of mistakes and lost objects. Really appreciate the work you are doing with the software though!! :)

Jeroen Bakker commented

2019-09-20 12:10:20 +02:00

Added subscriber: @CharlieJolly

Campbell Barton commented

2019-10-10 12:26:46 +02:00

If we're not likely to get conservative rasterization done for 2.81, a simpler solution could be to use the existing geometry batch to draw wires (even though it's GPU_PRIM_TRIS).

Then at least we wouldn't have to create new batches just to draw edges.

If we're not likely to get conservative rasterization done for 2.81, a simpler solution could be to use the existing geometry batch to draw wires (even though it's `GPU_PRIM_TRIS`). Then at least we wouldn't have to create new batches just to draw edges.

Philipp Oeser commented

2019-10-23 09:36:02 +02:00

Added subscriber: @3di

blender user #1436282 commented

2019-10-23 09:41:41 +02:00

question only: does https://developer.blender.org/project/board/2/ mean this task is not on the 2.82 workboard ?

michael campbell commented

2019-10-30 15:37:12 +01:00

In #63356#711468, @lichtwerk wrote:
Issue came up in #65856 as well, just wanted to note we have #64282, where #64281 (Option to lasso-select using geometry instead of object centers) was added.
So maybe we should add the opposite there as well? [selecting object centers with box select]

yep I'm guessing this would resolve the issue, as lassoo and circle select don't suffer from this bug.

Or better still make all of the selection tools consider geometry and centroids. This way you'd be guaranteed selection at any distance regardless of how much of the object falls within the selection perimeter.

> In #63356#711468, @lichtwerk wrote: > Issue came up in #65856 as well, just wanted to note we have #64282, where #64281 (Option to lasso-select using geometry instead of object centers) was added. > So maybe we should add the opposite there as well? [selecting object centers with box select] yep I'm guessing this would resolve the issue, as lassoo and circle select don't suffer from this bug. Or better still make all of the selection tools consider geometry and centroids. This way you'd be guaranteed selection at any distance regardless of how much of the object falls within the selection perimeter.

Campbell Barton commented

2019-10-30 21:48:33 +01:00

This uses existing batches to lines to account for faces being side-on, points to account for edges being viewed side-on.

While I don't like this at all since it's drawing 3x times, it does resolve the issue without using extra GPU memory to store edge/vertex batches.

diff --git a/source/blender/draw/engines/basic/basic_engine.c b/source/blender/draw/engines/basic/basic_engine.c
index 0dd1a4fd686..feaef731d38 100644
--- a/source/blender/draw/engines/basic/basic_engine.c
+++ b/source/blender/draw/engines/basic/basic_engine.c
@@ -189,8 +189,26 @@ static void basic_draw_scene(void *vedata)
 {
   BASIC_PassList *psl = ((BASIC_Data *)vedata)->psl;
 
-  DRW_draw_pass(psl->depth_pass);
-  DRW_draw_pass(psl->depth_pass_cull);
+  /* Until we have conservative rasterization, this is a hack but it works. */
+  if (DRW_state_is_select()) {
+    glPolygonMode(GL_FRONT_AND_BACK, GL_POINT);
+    DRW_draw_pass(psl->depth_pass);
+    glPolygonMode(GL_FRONT_AND_BACK, GL_LINE);
+    DRW_draw_pass(psl->depth_pass);
+    glPolygonMode(GL_FRONT_AND_BACK, GL_FILL);
+    DRW_draw_pass(psl->depth_pass);
+
+    glPolygonMode(GL_FRONT_AND_BACK, GL_POINT);
+    DRW_draw_pass(psl->depth_pass_cull);
+    glPolygonMode(GL_FRONT_AND_BACK, GL_LINE);
+    DRW_draw_pass(psl->depth_pass_cull);
+    glPolygonMode(GL_FRONT_AND_BACK, GL_FILL);
+    DRW_draw_pass(psl->depth_pass_cull);
+  }
+  else {
+    DRW_draw_pass(psl->depth_pass);
+    DRW_draw_pass(psl->depth_pass_cull);
+  }
 }
 
 static void basic_engine_free(void)

Edit: testing this with high poly scenes and it can be ~80x slower, so it's not practical to use.

This uses existing batches to lines to account for faces being side-on, points to account for edges being viewed side-on. While I don't like this at all since it's drawing 3x times, it does resolve the issue without using extra GPU memory to store edge/vertex batches. ``` diff --git a/source/blender/draw/engines/basic/basic_engine.c b/source/blender/draw/engines/basic/basic_engine.c index 0dd1a4fd686..feaef731d38 100644 --- a/source/blender/draw/engines/basic/basic_engine.c +++ b/source/blender/draw/engines/basic/basic_engine.c @@ -189,8 +189,26 @@ static void basic_draw_scene(void *vedata) { BASIC_PassList *psl = ((BASIC_Data *)vedata)->psl; - DRW_draw_pass(psl->depth_pass); - DRW_draw_pass(psl->depth_pass_cull); + /* Until we have conservative rasterization, this is a hack but it works. */ + if (DRW_state_is_select()) { + glPolygonMode(GL_FRONT_AND_BACK, GL_POINT); + DRW_draw_pass(psl->depth_pass); + glPolygonMode(GL_FRONT_AND_BACK, GL_LINE); + DRW_draw_pass(psl->depth_pass); + glPolygonMode(GL_FRONT_AND_BACK, GL_FILL); + DRW_draw_pass(psl->depth_pass); + + glPolygonMode(GL_FRONT_AND_BACK, GL_POINT); + DRW_draw_pass(psl->depth_pass_cull); + glPolygonMode(GL_FRONT_AND_BACK, GL_LINE); + DRW_draw_pass(psl->depth_pass_cull); + glPolygonMode(GL_FRONT_AND_BACK, GL_FILL); + DRW_draw_pass(psl->depth_pass_cull); + } + else { + DRW_draw_pass(psl->depth_pass); + DRW_draw_pass(psl->depth_pass_cull); + } } static void basic_engine_free(void) ``` ----- Edit: testing this with high poly scenes and it can be ~80x slower, so it's not practical to use.

Ludvik Koutny commented

2020-01-29 12:57:56 +01:00

In #63356#803594, @ideasman42 wrote:
This uses existing batches to lines to account for faces being side-on, points to account for edges being viewed side-on.

While I don't like this at all since it's drawing 3x times, it does resolve the issue without using extra GPU memory to store edge/vertex batches.

diff --git a/source/blender/draw/engines/basic/basic_engine.c b/source/blender/draw/engines/basic/basic_engine.c
index 0dd1a4fd686..feaef731d38 100644
--- a/source/blender/draw/engines/basic/basic_engine.c
+++ b/source/blender/draw/engines/basic/basic_engine.c
@@ -189,8 +189,26 @@ static void basic_draw_scene(void *vedata)
 {
   BASIC_PassList *psl = ((BASIC_Data *)vedata)->psl;
 
-  DRW_draw_pass(psl->depth_pass);
-  DRW_draw_pass(psl->depth_pass_cull);
+  /* Until we have conservative rasterization, this is a hack but it works. */
+  if (DRW_state_is_select()) {
+    glPolygonMode(GL_FRONT_AND_BACK, GL_POINT);
+    DRW_draw_pass(psl->depth_pass);
+    glPolygonMode(GL_FRONT_AND_BACK, GL_LINE);
+    DRW_draw_pass(psl->depth_pass);
+    glPolygonMode(GL_FRONT_AND_BACK, GL_FILL);
+    DRW_draw_pass(psl->depth_pass);
+
+    glPolygonMode(GL_FRONT_AND_BACK, GL_POINT);
+    DRW_draw_pass(psl->depth_pass_cull);
+    glPolygonMode(GL_FRONT_AND_BACK, GL_LINE);
+    DRW_draw_pass(psl->depth_pass_cull);
+    glPolygonMode(GL_FRONT_AND_BACK, GL_FILL);
+    DRW_draw_pass(psl->depth_pass_cull);
+  }
+  else {
+    DRW_draw_pass(psl->depth_pass);
+    DRW_draw_pass(psl->depth_pass_cull);
+  }
 }
 
 static void basic_engine_free(void)

Edit: testing this with high poly scenes and it can be ~80x slower, so it's not practical to use.

This mainly concerns object mode, not edit mode (I never encountered this issue in edit mode), so why take topology in consideration at all for tiny objects? Testing bounding boxes/origins for objects below certain screen size (determined by bounds) should be enough...?

> In #63356#803594, @ideasman42 wrote: > This uses existing batches to lines to account for faces being side-on, points to account for edges being viewed side-on. > > While I don't like this at all since it's drawing 3x times, it does resolve the issue without using extra GPU memory to store edge/vertex batches. > > ``` > diff --git a/source/blender/draw/engines/basic/basic_engine.c b/source/blender/draw/engines/basic/basic_engine.c > index 0dd1a4fd686..feaef731d38 100644 > --- a/source/blender/draw/engines/basic/basic_engine.c > +++ b/source/blender/draw/engines/basic/basic_engine.c > @@ -189,8 +189,26 @@ static void basic_draw_scene(void *vedata) > { > BASIC_PassList *psl = ((BASIC_Data *)vedata)->psl; > > - DRW_draw_pass(psl->depth_pass); > - DRW_draw_pass(psl->depth_pass_cull); > + /* Until we have conservative rasterization, this is a hack but it works. */ > + if (DRW_state_is_select()) { > + glPolygonMode(GL_FRONT_AND_BACK, GL_POINT); > + DRW_draw_pass(psl->depth_pass); > + glPolygonMode(GL_FRONT_AND_BACK, GL_LINE); > + DRW_draw_pass(psl->depth_pass); > + glPolygonMode(GL_FRONT_AND_BACK, GL_FILL); > + DRW_draw_pass(psl->depth_pass); > + > + glPolygonMode(GL_FRONT_AND_BACK, GL_POINT); > + DRW_draw_pass(psl->depth_pass_cull); > + glPolygonMode(GL_FRONT_AND_BACK, GL_LINE); > + DRW_draw_pass(psl->depth_pass_cull); > + glPolygonMode(GL_FRONT_AND_BACK, GL_FILL); > + DRW_draw_pass(psl->depth_pass_cull); > + } > + else { > + DRW_draw_pass(psl->depth_pass); > + DRW_draw_pass(psl->depth_pass_cull); > + } > } > > static void basic_engine_free(void) > ``` > > ----- > > Edit: testing this with high poly scenes and it can be ~80x slower, so it's not practical to use. This mainly concerns object mode, not edit mode (I never encountered this issue in edit mode), so why take topology in consideration at all for tiny objects? Testing bounding boxes/origins for objects below certain screen size (determined by bounds) should be enough...?

Clément Foucault self-assigned this 2020-01-29 13:15:03 +01:00

Clément Foucault commented

2020-02-04 15:33:47 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Clément Foucault closed this issue

2020-02-04 15:33:47 +01:00

Harold Williams commented

2022-06-29 01:38:21 +02:00

Added subscriber: @Hwilliams

Harold Williams commented

2022-06-29 01:38:21 +02:00

Hey everyone,

Quick workaround - **Use Toggle X-Ray (Alt+Z /Option+Z)**when you're in a pinch. This is so far working flawlessly for me in 3.2.

Rudimentary guess, when a selection is made in face mode, ngons that take up less than n% of the viewport in screen space aren't being considered? That's why it works in X-Ray, faces seem to be selected by their central points instead of by merit of their area in relation to screen space.

I hope this helps...

Good luck!

Hey everyone, Quick workaround - **Use Toggle X-Ray (Alt+Z /Option+Z)**when you're in a pinch. This is so far working flawlessly for me in 3.2. Rudimentary guess, when a selection is made in face mode, ngons that take up less than n% of the viewport in screen space aren't being considered? That's why it works in X-Ray, faces seem to be selected by their central points instead of by merit of their area in relation to screen space. I hope this helps... Good luck!

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Small object are not selected with Box Select tool #63356