Preselection highlighting

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.

1 Like

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.

Ok, but this question was made by more users in other sites/threads? why blender have problems editing dense mesh? is a problem of CPU or GPU? have solution? the solution is easy/hard to implement?

It’s not an easy problem to solve, there will more optimizations in 2.80, and more after. Going into the technical details here is not particularly useful though, it requires being familiar with the Blender code. There is some information here:


Personally I dont need preselection highlighting in the 3d view, as blenders selection works pretty predictable (which is in contrast not really the case in maya so there its really helpfull).

One area where its very handy though is uv mapping. As the correlation between the actual 3d geometry and the corresponding uvs is not communicated at all. So you end up selecting some uv elements just because you dont know how it all connects toghether.


Dear friends. I’m Modo user and I’ve noticed that during low poly modeling in Blender 2.8 I miss preselection highlight. I`m fresh Blender user but I model things in Modo everyday.

Preselection highlight is needed for me mostly for vertex and edges to know is my pointer is point demanded edge/vertex or not.

I’ve noticed that without highlight I clicked few times on edges/vertex and I`ve missed them. Then I realised that highlighting is helping me with that.

I would like to have same feature in Blender but with no cost for performance that`s why I think it may be done as separate option in preferences (or as addon by someone).

I hope this helps. Even without that Blender is awesome :slight_smile:


I can not wait to have this type of function coupled with a serious snapping.
I imagine the possibility during the positioning of a point, to have the interactive preview of all the snap points available near the area where I have to do the snapping.
It is a function that I have always wanted.

1 Like

I noticed that the built-in addon “snap_utilities_line” by @mano-wii already does the work described in this thread, what prevents a global adoption ??

I noticed that as well.
I tried the “Make Line” tool out and made a mesh with 1 mil+ polygons to see how performance would be. There was a long 7 second pause when activating the tool or entering edit mode with the tool already active, but after that the highlighting worked fine with no discernible lag.

Fast preselection highlighting was not practical in 2.7 with old opengl, but should be possible in 2.8 with small performance cost. it will take some extra gpu ram. This is how it could work…

Edit mode drawing would have a selection ID buffer as an additional output target during all rendering. This would be smaller than the full 3d view, but it would take vram. It could potentially store more than one ID per pixel, but that gets more expensive in vram and render speed.

When moving the mouse, the full 3d viewport would NOT be re-rendered, as this would be slow. Instead the highlight would be rendered as a 2d overlay, and temporarily composited on top, like the overlay gismos, so it could be quickly changed every frame by just rendering that single primitive and re-compositing the overlay.

The cost of this method is… slightly more vram usage for the selection id buffer to always be used, a potentially larger overlay composite buffer (i don’t know if the current overlay buffer is as large as the viewport or just as big as the gismo area). A bit slower drawing always (but probably only a tiny bit), because fillrate is spent on the selection id buffer, and because of a few extra shader instructions to write an additional output target.

I suspect someone will eventually do this… they just have alot on their plate in 2.8.


This would be a most welcome addition to Blender. :slightly_smiling_face: Particularly when working with face dot selection in x-ray mode when two dots (one on the front of the mesh, one on the back) are close to each other.