I’ve been slowly losing my mind and patience with the snapping feature of Rhino. I’ve produced curves that I’ve projected to planes to make certain they’re flat/planar. I’ve then made duplicates and moved them with g-the ball and yet the ends of curves will no longer match up to a line drawn orthogonally from an intersection. I’m rather disgusted as this point and I should stop and watch a movie or something. I’m not impressed yet with my precision or Rhino’s at this point and I don’t know yet how to make things work to the degree I want them too.
i don’t know how helpful watching a tutorial would be… it might actually be more beneficial to record yourself modeling/describing what you’re doing and we watch it to see where things are going wrong for you.
your model has (as far as i can gather) at least 5 places where there should be intersecting curves but they’re not quite touching. (ie- select all then run Intersect )
Guys, I had a little meltdown and made a little fool of myself. Still, I can’t leave this application alone because I think I can get what I want.
Up until Rhino, I’ve been a SU guy. I don’t miss SU. I obviously have to unlearn more than I supposed. I’m trying to develop an approach to modeling in Rhino that lays down a reliable foundation so that in the later stages when the inevitable changes must be made, I can do so with confidence and efficiency.
It’s all fun and games when things start out at zero, but later the poop will hit the propellor and one must be ready!
I’m more than willing to watch any tutorial. I’m presently watching a series on Lynda and I’ve learned a few more tricks. Patience is not my strong suit. But on the other hand, I don’t let go either.
Be aware that the Gumball is not guaranteed to be orthogonal oriented!
It’s bound to the object and it’s orientation is changed with the objects’ transformations.
@pascal
Making use of this instance to point out that the gumball setting “Align to World” is generating false expectations.
IMO this is a bug: A Gumball set to “Align to World” should be aligned to world right?
I myself still get caught by it as a slightly rotated object seems to have a world aligned gumball where in reality it’s not. I’d wish for an option to make the gumball truly aligned to the world regardless of the transformations it’s object has undergone. So a gumball with “Align to World” set will actually be Aligned to World
Generate a set of guide lines for each principle ortho view.
Project each set to its relevant cplane to make certain all is planar
Make certain they align properly to each other.
Those guide sets are then placed on separate locked layers.
Using the snap to locked objects setting, I then create the curves I need.
I often project those newly created curves to the cplane as well.
Once those are made I use the gumball to drag a number of duplicates.
( I would just as soon use the move tool, but I don’t know how to make a duplicate while doing so - tapping the option key doesn’t work.)
The other way is to copy and paste a duplicate and then use the move tool but that’s the sort of extra clicking I try to avoid.
Its at this point things get silly. I’m assuming that a duplicate curve moved orthogonally will have its end points remain orthogonal to the original so that a straight line drawn orthagonally from any point will be intersect at the same point on the copy.
This does not always happen however.
This is why I’m getting out of sorts. I’m not sure how to set up the program to draw with confidence.
(ie- select all then run Intersect ) Thanks Jeff, that’s another powerful tip.
I don’t have any suggestions for the OP other than patience. Working in a new program, no matter what it is, will always be awkward and frustrating. Start off by acknowledging that right at the beginning and you’ll have a better experience.
Concerning the gumball - I use the gumball all the time but I do find it disappointing. Resetting the pivot point is so much easier in modo or C4D or Max. And it’s not always reliable, going from World to Object often doesn’t change anything, the gumball remains the same.
That’s definitely a function in Rhino that needs improvement.
The Copy command lets you move a duplicate of the selected object.
Easier than duplicating the objects and then moving them. The Copy command will stay active until you end it with Enter, so, after you defined the starting point, copies are placed with only one click each.
I made a screen shot to give an example. As per the image, the intersect command was run to check the points and despite dragging a duplicate curve orthogonally it no longer interests a horizontal curve. It’s out by a minuscule amount.
The problem can come from several places. What I would do:
-Disable the Gumball for the moment
-Disable the grid snap
-Disable all objects snaps except the one you intend to use. I leave only “end” and “point” on at all times, using “one-shot” object snaps when needed.
-Disable apparent intersection for object snaps:
I agree with the minimalist approach to snapping, but I’m reluctant to take the time selecting and deselecting modeling aids all day long.
There must be a more efficient way to exploit the functionalities of the program. I’d like to eventually workout some quick keys to call up the osnaps I want when needed and have them remain off by default. I did disable ‘apparent intersections’ as that was a regular problem creator.
I suspect the gumball is the problem most of the time.
Hi James - all of the OSnaps are available as ‘one-shots’ that you can type or put on a shortcut/alias: Cen, Near, End, etc. that last for one pick regardless of the persistent osnaps.
