not to be replaced but my goal this year to start using some layers other than “Default”
i like the idea of reduction generally. but here to be fair i use it when for control point curved profiles which need an underlaying raster to keep tangencies, it is also good for layouting and to organise representative stuff. not something i would like to lose too quickly. maybe it could be replaced with a more sophisticated smart track. in indesign or affinity design/publisher for instance you get those smart guides which beam in all directions as soon as they detect some affinities.
Nah, leave it please!
How ever, since we are talking about this (without wanting to derail this anti-wishlist):
When moving objects that sit between(!) the grid lines already, I would expect them to snap to the grid points. What they do is move by a grid increment, so that they remain mis-aligned. Not so useful.
Where this feature makes sense is e.g. when creating VisualArq walls etc. Their automatic joints are quite sensitive when the endpoints are not aligned nicely. Setting the grid spacing to 1cm or something would help in always finding the ‘sweet spot’.
What I could do without, however, is this ‘Planar’ button.
Don’t you dare!!
There is no chance of Gumball going away.
That said, I will never use it.
Hi Eugen - I am not sure how you are doing it but if you have an osnap, say End, you can start there and end on a grid line.
-Pascal
Of course that SmartTrack that looks cool in a demo and was some big deal to get(thanks to Alias’ lawyers?) but no one ever actually uses was the next thing on my list, lol.
Could be that I dunno what I’m doing…
Here’s what I get -
Does that make sense?
-Pascal
Yes, thanks, that’s what I would like.
Can you show me your snap settings, please?
Thanks, sorry, I meant the OSnap settings.
I tried both Smooth and Snappy dragging of the Gumball. Does not work like you show.
Just End, here - but in this case none at all works just as well.
-Pascal
Got it!
You have to move the point itself, then it snaps to the grid.
Moving the 2D handle of the Gumball moves it in increments, even with Snappy Dragging on. Kind of strange.
I would say ui, If anything
I would probably also say SmartTrack or GridSnap are the commands I virtually never use and thus can ‘live without’… however:
Don’t forget that Rhino is multipurpose software and has an infinitely customizable user interface. So the feature you might never use might be exactly essential to someone else who is using Rhino in a different field or a different way.
There was someone who said Move Rotate and Scale are unessential - probably because they use the Gumball for those functions. And also someone who said they never use the Gumball, so Move, Rotate and Scale would be ‘essential’ for them.
Voilà - it’s possible that your personal field or way of working makes certain commands in Rhino superfluous… for you. There are other people out there that use Rhino differently. Aside from the two mentioned in the first paragraph, I use pretty much all of what has been mentioned so far above - Gumball, UI (command line, toolbars, panels, etc.) layers, etc…
Wise words!
At the moment you can choose not to use certain commands. Remove them and you take away others’ choice to use them. I would miss any of the specific suggestions made so far.
Perhaps a more helpful line of enquiry would be to investigate whether customising the UI - and keeping that customisation through new releases - could be made easier, so that with trivial effort you could hide the features that bother you.
Hi -
FWIW, that is being worked on in Rhino 8. The Windows part is pretty much in place, and when that is completed on macOS in a few weeks, the feature will be turned on in public builds.
-wim
Of course this is just an exercise, none of those features are going away, but never getting rid of anything just because someone somewhere might still be using it, no matter how obsolete or redundant, is basically giving up on the concept of User Experience Design, and saying feature bloat is great. What we’re supposed to be paying for in commercial software vs free alternatives is actual coherent Interface Design.
From the Department of Redundancy Department:
Of course, but I don’t see anything mentioned above that is completely obsolete. As far as ‘redundancy’ goes, all of Rhino is redundant. For most of the basic object creation and editing concepts there are often multiple ways of achieving the same result. Should all of them be removed save one?
We have a direct rectangular planar surface tool. Should we then not let people make a planar surface from a rectangular curve because another tool exists to do the same? Or the inverse, should we eliminate making planar rectangles directly because it’s possible to do with a rectangle + planarsrf? No, obviously. It’s a dumb example of course.
Of course, yes, there are of course certain things that could of course be consolidated that might make some relatively little known commands/options ‘redundant’ of course. But I think that list isn’t all that long personally.
Interesting topic Jim, especially seeing that the answers are a combination of personal/industry preferences to never use a tool that is clearly essential for others. Other answers are activism against tools that are still deeply flawed in the way they have been developed.
The one important possibility that I see here is the ability to disable tools, commands, interface elements, and also override Rhino default preferences. More importantly this should be done at an administrator level, not just user level.
For example, I’d love to set things up to anyone using Rhino within our CloudZoo team, in my case would be things like:
- move only selected object (the opposite is a horrible default that causes accidental micro moves, a nightmare scenario for CAD use)
- default path for scripts, and load scripts at startup
- default template file with our desired units, tolerances, layers, materials
- default material library
- enabling/disabling certain import/export formats. I never want to see .3ds or .X_T as export formats in my company. The former is junk that splits meshes based on polycount limit, the latter is deeply broken last time I checked, and it’s never been fully tested or maintained.
G