Page MenuHome

Edge Selection fails when the following Conditions met:
Closed, ResolvedPublic


I had a couple of Times the Problem, that sometimes when the “Limit Selection to Visible” is deactivated, Edges could not be selected anymore.
It also had alot to do with Ortho after a total zoom in or zoom out and how near the two Edges where away from each other(Nearer = more problematic).
I have now a demo of it, but I could not test it on any of my Systems, so I have no Idea how big the Chance is, that it would repeat the Error on your Machines.
The Example shows just the basic Problem, on more complex Objects in some amount of Zoom we had to use to work on a Detail, it gets really annoying when we had to zoom out or rotate the Sight or activate the “Limit Selection to Visible” to be able of picking the next Edge.

Tested on the original 64BIT Blender 2.62.0 Version r44136, the System was(Mint12 64BIT), the Machine was(Acer Aspire 8930)
Had the Problem also on Win7 64Bit, but can not confirm my demo on it.



Event Timeline


Can confirm this with 2.62 and 2.57, seems like edge selection fails when limit selection to visible is disabled and neither of the vertices of the edge are in view. Attaching another test case where you can pan to show a single vert and then selecting the topmost wide edge should become possible, the same works with the already attached file.

Ubuntu 11.10 32bit, Nvidia Geforce 9600GT driver 280.13

Guessing it's this bit, seems to only check that verts are within view region

Index: source/blender/editors/space_view3d/drawobject.c
--- source/blender/editors/space_view3d/drawobject.c (revision 45440)
+++ source/blender/editors/space_view3d/drawobject.c (working copy)
@@ -2126,7 +2126,7 @@
project_short_noclip(data->, v1_co, s[0]);
project_short_noclip(data->, v2_co, s[1]);

- if (data->clipVerts == V3D_CLIP_TEST_REGION) {
+ if ( 0 && data->clipVerts == V3D_CLIP_TEST_REGION) {
if (!is_co_in_region(data->, s[0]) &&
!is_co_in_region(data->, s[1]))

very old bug, think its been reported before, but fixed anyway r45498.

Thanks alot for fixing it, this was very anoying :) :) :)
Uuuups, i tested it in the new r45619 on the same file, it's a bit better, but when we zoom in a bit more, the problem still exist and in perspective view it's even worse now :(
Will make a new thread, since i don't know if anyone reads these closed ones.