Preselection highlighting

@billrey could devs bring to blender support for element pre selection highlight in edit mode?
It will add a HUGE improvement in workflow! Right now it is definitely a “paper cut” with precise selecting.

For example, faces have dots witch supposed to help selecting. Well, it is, until you working with big amount of objects/polys and precision of clicking goes down (especially in wireframe or x-ray mode) :neutral_face:

I am certainly sure that many blender users will confirm how painfully sometimes to select right element because you never know how exactly you should hover cursor on element to select it.


I highly doubt this is possible without adding a huge performance overhead.
Compare the difference in lag time when clicking to select something, versus just rotating around the viewport. It’d be doing those select-calculations constantly in order to do that.

Maybe as an optional overlay when you have performance to spare it could work.

1 Like

It should be an overlay like seams, sharpness, face orientation etc.


Why? Drawing one extra polygon should be no big deal. More importantly it could possibly just work by modulating the color of the polygon hovered over without necessarily needing to draw an extra polygon instead.

or in case you are talking about object mode, sure all the polygons need to be rendered, but again, its not as if duplicate geometry needs to be drawn for it, just modulate the color of the object-item being hovered over.

This shouldn’t really have significant effect on performance at all.

The drawing isn’t the slow part, it’s the the calculations required to determine which thing will be selected, which you would have to run constantly, instead of only when you try and select something.

Notice how selection slows down when you hit a certain density? You’d be running that slow operator every time the mouse moves.

1 Like

This is something that needs optimization irregardless, no?

There’s no easy way to optimise that without drastically increasing RAM usage and/or requiring longer “loading times” to get into edit mode, and likely in the progress slowing down viewport navigation to calculate some sort of selection map as we move around. It’s always going to be a significantly taxing task compared to other tasks.

The solution would to make it an overlay you can turn on/off - that way you only use it when you have performance to spare.

1 Like

I’m always wondering why this is an issue in blender, while there’s no performance problems in other 3d apps.

For example, this is a 6+mil mesh, and yet pre selection highlighting runs very smoothly, no performance issues here.




Probably won’t be easy and I guess developers have more important things to do now.
But it should be possible. Here is a 4 000 000 poly sphere. The lag is negligible.
The preselection highlighting turn off while navigating the viewport, moving objects etc.


Trying to edit faces/edges/vertices on such a high poly model is a hell anyway.
This feature was introduced in Maya not so long ago, I think it was 2014. I didn’t notice any performance slowdown.


But it seems like the system is already in there, and just needs to be available for the other tools and be optimized.

This is a 4+mil mesh in blender with pre selection highlighting.



I don’t know how you got that screengrab (the blender one) but I believe it’s going CPU side preselection which is slow.

I would like to investigate how to do it really fast by rendering an ID map only once and preselect the ID that is below the cursor.

Also I want to rework the selection algorithm to be more optimized for the GPU. But I can’t say when all of this will be done.


The pre selection highlighting I showed there is a feature of the new Poly Build tool.

But it’s nice to hear you are willing to improve that area. :slight_smile:

I’ll admit, I didn’t consider a threaded implementation. Or a gpu one.

What’s the preselection performance like for maya and what you used @ThinkingPolygons when zoomed out?

What I think those programs would be doing is two things.
As you move the view around, in a background thread, a list of all the verts/edges/faces in the view is made and updated. This would add a small lag time before preselection can start after moving the view about
Then that smaller list is used to do the preselection logic once the view stops, also in a background thread so as to not slow the view down.

I would have thought trying to use the GPU for it would be significantly complicated. For instance, what about overlapping verticies, would you have a layered ID map? or not worry about preselection for those because you’d use normal selection logic to get at them - but then shouldn’t you use the same logic for both so it’s always accurate?.


We already use GPU to draw vertices with their indices for edit mode selection.

I’m pretty sure other software use the same method as it’s WYSIWYG.


If blender use same method than other software why so many difference in the perfomance when you edit in maya?

I don’t think there is a reason to blame blender. All the changes aboard and pending stuff is insane amount of work. Anyway, b3d is near the point of performance, usability and beauty all together. Just need to fix a million of small things, but it’s ok, devs will handle this as long as community keep helping and love blender :sunglasses:

blame blender? I am asking the reason.

This is going to slow down the performance a lot, it does in maya and almost any other software with high poly meshes, and its kinda distracting in my opinion.

1 Like

The comment was about one very specific aspect of drawing code, there are many other things that affect editing performance.