Hi Marc - so, the DragMode constraints for UVN and/or ControlPolygon would show up as toggles right on screen(?) is that correct, if there are control points selected.? Do I follow?
-Pascal
It’s an example of a control that would not be a dialog box nor an option panel like Osnaps or Selection Filters, something that would enable more control and would allow the discovery of features.
I see this appearing when points are turned on on a surface, no selection yet. It would show what is possible in the next step.
Imagine this scenario:
-Surface is selected then points are turned on, a panel appears
-This panel shows option to the constraints available. Could be radio buttons for U-V-N.
-Grey-out options could show “keep tangency on edge” with an option to select edge(s) and make the option available.
It would work well combined/in concert with MoveUVN.
Yep, sounds like a good avenue to explore - we’ve been hearing a little about making control point editing a little more graceful and controllable.
thanks,
-Pascal
Sounds like a nice development for MoveUVN. The sliders(?) there could be colour keyed to match the UV (and N?) arrows that appear on the surface itself. U/V chain selection is a bit of a lottery atm.
Jess’s picture with the selection filter brings a small item to mind; can Blocks have an option for Properties > Name to be automatically populated with the block name? The current ‘Block instance’ isn’t always very helpful, especially when you’ve got several blocks stacked up.
2 Likes
More about Command Line Fuzzy Logic
I think the fuzzy logic should consider the current selection. In the screenshot below I have grayed out all commands which will not accept the selected circle as input. Actually there are no surfaces or meshes in the entire file so these commands could be grayed out even without anything selected. Just a thought… @mikko
3 Likes
Unfortunately there’s no way to know what sort of objects a command will accept until you run the command. And even if we were to inform Rhino about all of our own commands, it still wouldn’t work for plugin commands.
in V5, but we are talking about V6. Anything should be possible even with PlugIns. Some simple plugin properties manually defined would make it happen.
Yes, points selection is arduous too.
Select U/V, Next U/V, Previous U/V are all a bit of a lottery where we loose a lot of time.
By putting a lot of responsibility on plugin developers, which I don’t think is a good idea. It also wouldn’t cover compiled scripts or python code. I’m not saying it’s a bad idea, it would be great to be able to filter the results in that way, but I don’t think we’ll ever be able to get it exactly right, and I worry about presenting users with false positives or false negatives. Features that can’t be trusted implicitly are always risky to have, it’s impossible to determine ahead of time whether they reduce more confusion than they sow.
Yep you are right, so the ball is back in Mikko’s park. All known info could be fed in manually to the fuzzy logic, And maybe it can learn the rest by a command watcher over time?
If a command is slightly faded in the auto-complete list it does NOT mean that it cannot be executed. It is just a visual indicator which commands might be the one I’m looking for.
that breaks convention… if something is greyed out, it means it’s unavailable.
i’m not saying you shouldn’t or can’t break conventions, just that it should require more careful consideration prior to doing so.
Why not just sort the results in the way, Grasshopper already does for it’s components.
So if you enter only one letter, the top results will be the most probable for the selected type and/or last operation. If you have a different workflow, Rhino could adjust it’s probability weightings accordingly.
and that’s what it is for the current selection in my example.
Alternatively the working commands could also be bold.
Edit: It was easier to mask the redundant commands 
While talking about conventions: In other applications commands which require certain objects are greyed out if these objects are not available. Here for example Illustrator with an empty document: 
right… that’s what i was getting at… the items which are grey Can’t be selected.
where as the particular idea i was responding to stated the items could still be selected even though they were grey.
in the case of your idea, i’m not saying i don’t like it… it’s sweet actually… it’s just that rhino would have to be smart enough to know what each command requires prior to running it and if a selection does not apply to a command, the command would be greyed out and non-selectable. (or maybe better-> the grey command doesn’t show up in the list at all… would make more sense for people who use the arrow keys to navigate the list by not cluttering up key clicks with unnecessary list items)
it sounds like a whole lot of work to get it running like that and i’m not entirely sure how much it will speed up the process… it will possibly make things less confusing at points but as far as actual speed up, the benefit might not be so great.
No good. Just because the current selection is incompatible with a command, doesn’t mean the command can’t be run. It just means the current selection will be deselected, after which you’re prompted to select the objects that are allowed.
I agree with all of Jess’ proposals, all of this could get established without even (seriously) touching the GUI.
Looking at Rhino’s lack of context sensitive behavior I consciously need to bring to my mind again that here multi-subobject selections (e.g. of a surface and a curve) do actually make a lot of sense.
Inside mesh modellers, which cleanly divide what commands are available for what object types (and where simultaneous selection of Vertices and Faces isn’t even allowed) one has far greater options for cleanup. Some programs even swap contents of the main menu and of all forms of context /pie menus, based on the currently selected subobject type, as illustrated in these screenshots. Here nothing irrelevant is shown, not even greyed out and there’s no functionality truncated.
left: menu content with face selection, right: the same menu item with an edge selected
As said, I realize that trying to do similar things in Rhino was quite a bit harder, but it should be well worth the effort.
You need to look maybe a little too closely for real convenience, but there are colored U and V direction indicators on surfaces with points on. For what it is worth, I am lobbying for the ability to click on the control polygon to select a row of points, then in that context at least, there is no need to know about U and V.
http://mcneel.myjetbrains.com/youtrack/issue/RH-29185
-Pascal
1 Like
Well actually we have three scenarios.
- Commands which work with the current selection (bold)
- Commands which do not accept the current selection (normal)
- Commands which cannot be executed for whatever reason (greyed)
Of course if and how this stuff will be displayed should be adjustable in the options.
I’d prefer that a greyed out command could be invoked but then telling me why it cannot proceed. And hey, this thread is about unconventional brainstorming → cursive?
[quote=“hifred, post:99, topic:10449”]
context sensitive behavior
[/quote]Thanks Holger - you name it. Now how to branch that thread?