Hi All
İn PowerShape one command for all objects .
Curve_Surface _Solid _Mesh . . .
1 Like
Hi - there tend to be different options for different types of geometry in Rhino. In the early days there was some experimentation with “überization” of commands. It didn’t fare well.
-wim
1 Like
@wim, let’s expand on this answer because I don’t buy the current approach as being any good, for anybody.
This could be solved if the tool is looking at what input geometry is being selected and then offering the topology-specific options that all these separate tools are doing already.
Was that ever experimented in the early days? What tools? I don’t recall having tested anything that have been thought-out to be user-centered like this.
I have a really hard time accepting that this is the best McNeel can do:
Also I feel that this segmentation of tools is mostly an answer to be able to develop these tools for different topologies at different levels of execution.
Consistency is a lot of work, and what I see here is lack of consistency as a shortcut to postpone that work.
Example: My biggest disappointment this week was seeing the neutered SubDSweep2 being spun-off into a tool that doesn’t even do any surface matching (with is one of the most useful thing to do to SubD faces).
I still want a full featured SubD Sweep2, at least starting with this:
…and eventually a well thought-out UX where a responsive/contextual dialog can show the relevant, applicable and desirable controls and options for a single Sweep2 command, for any topology type. I’d even argue that the command should be called Sweep, and the 1 &2 rail options could also be interactive in the tool dialog.
I know this is a lot of work. A lot of design work, before you do the programming work. And at McNeel design has always been an afterthought, so we end-up with 1000+ commands because that’s easier for your developers to deal with. I could even argue about this being easier for them too.
Maybe V8 is all about cleaning up this wonderful mess we have into a much more useable and accesible product?
G
3 Likes
It’s the nature of how Rhino has been developed. People request “thing,” they make “thing.” Also Rhino is a platform, so while it might be difficult for “the mothership” to do this Grand Unification work, it’s absolutelynotgonnahappendotcom for 3rd parties.
Also…this sounds like a cool design project with not a ton of basis in UI design theory, at least what I ever read which was ages ago by the likes of Jef Raskin . Making tools “smarter” so that we don’t need different ones in different contexts, sure that’s great. Hiding the complexity under a bunch of context-sensitive fluff doesn’t do anything for discoverability. Of course again with Rhino being a platform, what you can do under any particular context of selected stuff is…practically anything.
3 Likes
Hi Gustavo -
This is in there to some extent now - e.g. in Split. A problem that you start to run into is that it complicates selection and command flow - you need to answer the selection question all the time, window selection does not work for particular object types, and the same command has different paths and options depending on the selection; I say this tends to be helpful on paper only, in practice I think it replaces one apparent complexity with another actual one - selection filters, modifier key acrobatics, etc., macros are harder to design… I don’t say there is not a lot of good that could be done to Rhino’s commands, but consolidation is tricky especially after the fact, and should not be mistaken for a goal in itself. (it seems to me).
-Pascal
2 Likes