Fixed in R2.
Circle select respects these settings now in R2.
Fixed in R2.
So indeed the new R2 release is on GraphicAll.
Fixes issues above plus:
- Ctrl-leftclick crash fixed.
- Manipulator snap now also in object mode, and works good in all settings now.
- Proportional highlighting when Constant now works correctly.
- SHIFT now works when preselecting loops/rings/paths.
- And some minor stuff.
Thx all, if we do this together it could be great! Gonna sleep now.
Wow! Will take it for a spin at home this weekend, by the looks of it! awesome!
Quick question will the high-lighted color be themeable ?
I vote for trunk as well, with exception of #3 and #4:
Direction based box selection would just piss me off. I always go both ways. Using MMB to deselect is consistent through the whole of blender and there’s no reason to break that convention here.
#4 is a great idea, but it can cause a really large number of problems with rigging and animation. However this is just a warning - I do think it could go to trunk as long as it’s safe to use in all cases and doesn’t cause any unexpected problems with rigging and animation. As well as in the case of python-api access, having separate attributes for the visual location and the actual location.
Otherwise this is super great 
talk to the devs on #blendercoders in irc, on a mailing list or via email to a particular dev (maybe Ton, he handles some of this UI/UX stuff). Preselection hilighting has always seemed like a useless visual cue, but with the addition of showing the loops, rings, paths and proportional edit range it’s really a useful tool 
Modal Circle-select is also a huge plus - if there’s nothing wrong with your code then there isn’t a very strong argument as to why it wouldn’t be included in trunk
Just make sure you contact the devs.
Just wanted to say thanks for your work on this. Really helps, especially with path select because you can see the path before committing to selection. Did you do any tests on using preselection as input to the ops ala wings3d (basically preselection acts like a regular selection if you press a hotkey)?
You sneaky little… You haven’t said a thing! : D This is so great.
I did some extensive testing, here are the results:
- While Circle selection is active, and you hover over window borders, the double-arrows mouse pointer tends to toggle on and stay.
- I see that preselection face overlay is partly transparent. Could we get a way to control this transparency?
- Preselection is really visually intrusive when it is not using subtle shades. If you check other software the preselection color is usually a pale yellowy-orange or a pale blue, not full-on maxed out red and green : ) So more subtle shades would be welcome.
- Turn Box Select modal, ended with B. That is to keep it consistent with Circle Select.
- I’m not sure about the Box Select select-deselect modes you used, they are hard to discover and very non-standard. Check out my proposed functionality in my doc (link in signature).
- I get this in the header - https://db.tt/e1wHx5lr
- When adding to selection using path select, the proportional editing display does not update.
- The Projected (2D) proportional editing option does not work.
- Elements are not prehighlighted on occluded parts of the mesh, when limit selection to visible is off.
- Have a textured, uvmapped model, 3d view and uveditor open. Select an edge with proportional editing on, turn on preselection - crash. Here is a file so you can reproduce it - https://dl.dropboxusercontent.com/u/6959287/Other/PreSelTest.rar
- Free Manipulator is great, but it should be reviewed by the UI team : ) I’ll think about how it functions, better solutions than the Free mode + unlink button could be possible.
A circle mouse pointer maybe? If you need graphical elements paleajed - talk to me : )
Already is. Search for Preselected in Theme > 3d View.
Great! All appear very good.
Now I need someone implementing edit two object at some time in blender.
First off, thanks for your efforts.
I currently got no time to test it, but I am curious about the performance impact of it.
Selection in Blender already impacts performance quite a bit, especially in edit mode (obviously) on objects with a high polygon count.
Did you consider it in your implementation to keep the performance impact as small as possible?
Of did you even overhaul the underlaying selection algorithmic?
Would it be possible to add some kind of visual cue to indicate circle select mode aside from the circle?
There should really be a header text, i miss this in trunk as well. Many modal operators show useful information in the header. For circle select, it would read something like “Circle Select: RMB to select, LMB to deselect, C to confirm.”
BTW: it should accept Escape to cancel, and also Spacebar to confirm (some ops in blender do this)
more subtle shades would be welcome.
Well, it’s themeable, but yeah, nicer defaults would be good.
Turn Box Select modal, ended with B.
Circle sel and box sel have quite a different nature, not sure if it’s a good idea, feels a bit force to me, just to keep it consistent. But need artist feedback for serious decision making.
Direction based box selection
It’s confusing indeed, would disable it by default. Could be allowed via custom keybindings if that was supported.
Could we get a way to control this transparency?
Not sure about the performance impact here, but yeah, the theme colors could be RGBA
Keep up the great work!
@Paleajed
there are some missing feature in this C implementation that make Blender preselection UNIQUE compare to the addons
- Face edge border subtle lighting color is missing
- X-Ray wen vertex, edge, face presel path, loops, ring, proportional is missing, this is really useful for visual feedback
- preselection vertex gradient is missing
- presel vertex normal preview is missing only face is there useful to detect in complex meshes wen normal are flipped or corner sharing two vertex
- wen i get home i’ll further test this implementation, the free manipulator is great i have some ideas to make it better wow this have a lot of possibilities…:yes:
I hope that all of the addon features don’t get lost in the " C " implementation
I guess it’s because it’s WIP.
I’m not sure if this is needed… I have an impression that the way it is currently, actually makes it clearer what will be selected… I mean, it’s clearer that you will select a vertex, and not a vertex with 4 edges for instance. I know it has the drawback, that with two verts really close together, you don’t know which of them you will select.
the problem is of greater importance when there are verts in the exact same location - think of split edges! For this case, highligting for connected geometry would help i guess. But how would you select the one vert you are after? Would you just move mouse around and hope pre-sel will eventually show the rightone? Is that reliable?
This is really awesome! I haven’t had a chance to test this yet. I’m on Mac. I’ll try and do a build with your patch tonight. Did you update the patch yet?
The one thing I’m wondering is, does this work with left mouse select/Maya style navigation, etc.? Or are the hot keys/behaviors hard coded?
This might actually go a long way to make the whole Left vs right mouse button select argument less important. Sebastian’s main complaint about LMB select is that it’s to easy to accidentally select and move something without meaning to. I disagree, but I can see how someone who is used to Blender’s default RMB select could be annoyed by it. However with pre-selection highlighting, you would always know exactly what you where about to click on and move. I feel like this is a pretty important change for Blender due to the very nature that selection works in it.
As far as voting this into trunk, obviously this need to be a permanent solution in Blender. But not until all the little oddities are worked out. We have yet to hear from anyone who uses a non-standard keyboard or view navigation layout. I have a non-standard view navigation layout (but I use blender key layout) so I think after I have a go at it, there might be a few things to discuss. 
We’ll see though, I’m super excited about it!
Works very nice in my opinion. Very fluid. The default colors might be adjusted true but else very nice.
I am actually ver yhappy to see the “free” manipulator as that has been somewhat of a lack in Blender I feel, but for rotating it is still hard to use it right. its hard to align one of the axis to an arbitrary edge for example.
There was an addon that made this very easy by using the 3d-curser and make it possible for the manipulator to point one axis at the cursor and then make the curser snappable to geometry by draggin the curser mouse button over said geometry.
As said else very nice! Kudos
Nice work.
Would be nice to have integrated in trunk.
Direction based box selection would just piss me off. I always go both ways. Using MMB to deselect is consistent through the whole of blender and there’s no reason to break that convention here.
Yep, its included as a test, not even a real proposal, just seeing how its received. More comments are welcome.
#4 is a great idea, but it can cause a really large number of problems with rigging and animation. However this is just a warning - I do think it could go to trunk as long as it’s safe to use in all cases and doesn’t cause any unexpected problems with rigging and animation. As well as in the case of python-api access, having separate attributes for the visual location and the actual location.
I hadnt thought about that yet. Im really not into rigging/animating at all, so I cant imagine straight out what would be going wrong. Id appreciate people to test and get back to me with examples of problematic behaviour. Python API wise this distinction will be added for sure.
Modal Circle-select is also a huge plus - if there’s nothing wrong with your code then there isn’t a very strong argument as to why it wouldn’t be included in trunk
Needs testing. You know circle select stays on when moving over another view?
Did you do any tests on using preselection as input to the ops ala wings3d (basically preselection acts like a regular selection if you press a hotkey)?
Its been suggested when I was working on the PreSel addon, when I get some time Ill add it in to be reviewed by the users.
I see that preselection face overlay is partly transparent. Could we get a way to control this transparency?
Good one, Ill add it.
Preselection is really visually intrusive when it is not using subtle shades. If you check other software the preselection color is usually a pale yellowy-orange or a pale blue, not full-on maxed out red and green : ) So more subtle shades would be welcome.
We should decide on this together.
Turn Box Select modal, ended with B. That is to keep it consistent with Circle Select.
I need opinions!
When adding to selection using path select, the proportional editing display does not update.
Fixed in R2 ! EDIT : no it isnt… thought you meant something else.
Elements are not prehighlighted on occluded parts of the mesh, when limit selection to visible is off.
Same here.
Free Manipulator is great, but it should be reviewed by the UI team : ) I’ll think about how it functions, better solutions than the Free mode + unlink button could be possible.
No, I want it reviewed and discussed by all of YOU. The “UI team” can take my code and do with it what they want (its GPL after all), and of course they can get in on the discussion, but as long as its my build thats up for scrutiny, I want this to be an Open (!) Development.
A circle mouse pointer maybe? If you need graphical elements paleajed - talk to me : )
Do take a stab at designing one! More ideas? Putting usage text on the header is a nono, since the normal header icons should be available during Circle Select, its modal after all.
Already is. Search for Preselected in Theme > 3d View.
And theres separate theme colors for UV editor. Maybe this is overkill?
I currently got no time to test it, but I am curious about the performance impact of it.
Selection in Blender already impacts performance quite a bit, especially in edit mode (obviously) on objects with a high polygon count.
Did you consider it in your implementation to keep the performance impact as small as possible?
Of did you even overhaul the underlaying selection algorithmic?
No Im using the current selection code for it (I heard implementing new selection code would be part of Viewport FX GSOC?). But take note its easy to switch off Preselection with a highly accessible checkbox in 3D view > Npanel > Mesh Display and UV editor > Npanel when it would get in the way.
BTW: it should accept Escape to cancel, and also Spacebar to confirm (some ops in blender do this)
Hmm, no, cause its not really an op but more a mode. You can undo seperate selection strokes. Cancelling the entire mode span would undo everything else you do (other tools and so on).
Could be allowed (box select direction) via custom keybindings if that was supported.
If more people agree on this I could add an option for direction sensitivity you can use on any custom keybinding.
Face edge border subtle lighting color is missing
Could be added, but whats the real added value of it?
preselection vertex gradient is missing
Ill get it in whenever it fits in the schedule.
presel vertex normal preview is missing only face is there useful to detect in complex meshes wen normal are flipped or corner sharing two vertex
I can do that if theres a need.
the problem is of greater importance when there are verts in the exact same location - think of split edges! For this case, highligting for connected geometry would help i guess. But how would you select the one vert you are after? Would you just move mouse around and hope pre-sel will eventually show the rightone? Is that reliable?
Inherent of Blender selection code (which is used by Preselect). Either move around the mouse or select the one, and the other will be highlighted; but then youre stuck with the first one being selected… Im open to implementation suggestions that would solve this.
This is really awesome! I haven’t had a chance to test this yet. I’m on Mac. I’ll try and do a build with your patch tonight. Did you update the patch yet?
The patch is latest. Ill do a Mac build myself today if I find time and the ol’ dusty Hackintosh wants to cooperate…
The one thing I’m wondering is, does this work with left mouse select/Maya style navigation, etc.? Or are the hot keys/behaviors hard coded?
All behaviour is customizable, but as it stands at the moment, preselection of paths/loops/rings has its own bindings and they wont change along with normal selection bindings, youll have to set them seperately (fixing this would be kinda hackish I suppose). Circle Select respects Left/Right settings. If any of the new functionality has to be changed for eg. Maya maps, the required settings will just have to be added (by me) correctly to the different presets; Id be delighted if people could figure out what needs to be done? If more control issues pop up, let me know!
As far as voting this into trunk, obviously this need to be a permanent solution in Blender. But not until all the little oddities are worked out. We have yet to hear from anyone who uses a non-standard keyboard or view navigation layout. I have a non-standard view navigation layout (but I use blender key layout) so I think after I have a go at it, there might be a few things to discuss.
We’ll see though, I’m super excited about it!
Yes! Discussion and testing are the exact purposes of this thread and the actual builds.
I am actually very happy to see the “free” manipulator as that has been somewhat of a lack in Blender I feel, but for rotating it is still hard to use it right. its hard to align one of the axis to an arbitrary edge for example.
There was an addon that made this very easy by using the 3d-curser and make it possible for the manipulator to point one axis at the cursor and then make the curser snappable to geometry by draggin the curser mouse button over said geometry.
I actually discussed this with CoDEmanX on IRC yesterday. Unsure about implementation yet. Holding Alt during Gkey starts alignment from current position, releasing it chooses end position (aligning from A to B)? Of course this would work together with Ctrl-snap? Cause people will want to align from vert to vert for example (not only along edge).
And YES, I am delighted with the response so far! I am a strong proponent of preselection; not only for paths/loops/rings/proportional but also for plain selection when things get complex (like non-occluded, when I get it working) and also when using a 3D view along with the UV editor.
Keep the remarks coming; I am a strong believer in community efforts and yes, if we want to go all the way with this, for sure an effort it will take!