What the Gumball so badly needs [SOLVED]

Awesome. I can’t wait to get a trial of this and check it out. The counter-intuitiveness of 3DS Max has always driven me nuts, since I discovered it a few years ago. It’s more like a genetically-revived T-Rex with some genetic modifications rather than a Goliath–a patchwork of functions and tools that only work well together if you learn its esoteric il-logic! I hope Modo solves all the issues that I have with Max.

Just curious: have you ever compared Modo to Blender?

Well, again, that was helpful, I have used _InterpcrvOnSrf countless times, but I didn’t know how to do it with other functions like polylines, shapes, etc. Thank you!!

BUT there are still some issues. There should definitely be a check box in the OSNAP bar because it’s quite a setback to have to type the command or select from the drop-down menu every time. Also, if you have to use it more than once, _PersistentOnSrf locks it in and you can’t unlock it until the command is completed. What if you want to draw a 3D polyline that touches a surface at several points and also connects to other surfaces or objects?

I guess there is no way to make this an automatic OSNAP like all the others?

Perhaps a script is in order?

[quote=“3DSquatch, post:21, topic:7490”]
Awesome. I can’t wait to get a trial of this and check it out. The counter-intuitiveness of 3DS Max has always driven me nuts, since I discovered it a few years ago. It’s more like a genetically revived T-Rex with some genetic modifications than a Goliath–a patchwork of functions and tools that only work well together if you learn its esoteric il-logic! I hope Modo solves all the issues that I have with Max.

Just curious: have you ever compared Modo to Blender?
[/quote]

modo is, on the basis of my very limited experience with MAX, a much more intuitive and fluid modeler and picks up a lot of ‘refugees’ from MAX. But it’s not a CAD application and is not suitable for precision modeling (although there are rumors of improvements in that area coming in 801 - we’ll see). But for non geometrical work, it’s a joy to work in. Download a copy, make some shapes and then immediately start playing with Fall Offs and you’ll see what I mean.

I’ve not worked in Blender but on the basis of chatter in the sub d forums I would say that it’s gaining ground continually against the paid applications and soon will be a serious contender. My paid work, unfortunately, is pulling me away from the sub d modelers and towards the parametric programs. I will have to learn Solidworks or Inventor this year, like it or not.

Yup … just tried that and that’s the ticket for sure. Thanks Pascal (I type that so often - we need an emoticon or a key command for ‘Thanks Pascal’ ).

not really. not if you’re comparing it to how sketchup works regarding surface snapping… sketchup’s cursor will always go on surface automatically… and will also recognize an intersection between a surface and a line passing through it… these things aren’t as easy to accomplish in rhino.

in rhino, i’ll often use the _Intersect command to mark curve-through-surface intersection or draw lines longer than needed then trim them using the surface etc… not so bad once you get used to it but not as easy as it might be.

i rarely use the onsurface osnap even though that’s what i may need at the time… it’s 4 or five clicks where as drawing a longer line then trim is less and the selections can be less precise (meaning- you can do bigger/looser window selections with trim instead of needing to find a little checkbox)

[quote=“jeff_hammond, post:25, topic:7490”]
not really. not if you’re comparing it to how sketchup works regarding surface snapping… sketchup’s cursor will always go on surface automatically… and will also recognize an intersection between a surface and a line passing through it… these things aren’t as easy to accomplish in rhino.[/quote]

That’s a pity! I learned 3D with SketchUp and it was–BY FAR–the best learning tool for modelling. It’s a very intuitive, fast and fluid program that is, by virtue of its simplicity, very limited in its power. Despite the fact that it doesn’t handle high-poly or large models very well, it’s surprisingly accurate for CAD and it’s amazing what you can still pull off in it, at crazy speeds to boot! It’s why it’s gaining ground in my field (architecture) everyday. I think a lot of this has to do with its “smart” modelling aids like the surface snaps, etc.

Too bad Rhino can’t do the same for automatic surface tracking and snapping.

[quote=“jeff_hammond, post:25, topic:7490”]
in rhino, i’ll often use the _Intersect command to mark curve-through-surface intersection or draw lines longer than needed then trim them using the surface etc… not so bad once you get used to it but not as easy as it might be. [/quote]

I do the very same, but it gets on my nerves after doing it a dozen or more times in the course of an hour. This should definitely be fixed if there already isn’t an easy alternative that we are overlooking.

Using the drop-downs? Never! I use commands instead. For me, memorized commands and hotkeys are the fastest way to model [second only to Gizmo/Gumball-Transforms, automatic “smart features” like OSNAPS, SmartTrack (Rhino) or Polar Tracking (AutoCAD)]. After that, graphic sidebars and floating icon toolsets are my next choice. I only use drop-downs to search for new commands to memorize and to create new toolset buttons for. If time is of the essence, drop-downs are never an option.

What I was referring to when I mentioned a “checkbox” was the actual OSNAPS checkbox (see screenshot below), which, as you know, turns on the various automatic snaps. Rhino really needs one here for OnSrf tracking. It would make precision modelling even better and much faster.

right. that’s what I meant in the example. the osnap panel.

trim via keystroke vs. setting up a oneshot osnap.

So, assuming that the closest thing to an automatic surface constraint/snap is having a button handy, I decided to make one. The icon is crude, but it does the trick.

To create the working icon, first save the PNG file I have attached here. In Rhino, right-click in the docked or floating toolbar were you wish it to reside and choose “New Button”. In the Button Editor, type _OnSurface in the ‘command’ field and then give the button a short description in both the ‘Tooltip’ and ‘Text’ fields. Then click on the blue underlined text link in the top righthand corner of the Button Editor. Then click 'File > Import Bitmap…" Locate the save location of the PNG file you saved and click ‘open’. Close both the ‘Edit Bitmap’ and ‘Button Editor’ windows by clicking ‘OK’ in each.

To use the function, open a command like ‘Line’, ‘Polyline’, etc., then click on your beginning point. Now click the new button for the _OnSurface command. Select a target surface and now you can place the second point of the line/polyline anywhere on that surface.

Not quite the same as an automatic snap, but it’s MUCH easier than resorting to the drop-down menus each time you need it.

Happy modelling.

Hi 3dSquatch,

i don’t know if this will help, but when you hold CTRL key when you hover over Osnap panel, you will be able to choose OnSRF and PersistantOnSrf. Isn’t this what you need?

Some more VERY helpful info! Thanks.

The only problem is, it’s still not an automatic OSNAP, which it should be. These commands are temporary (functional only during certain commands) when there should be an option to include them in the OSNAP Panel.

Maybe a new feature for Rhino 6? In the meantime, wHat I am going to do is create a toolbar and icons for all those snaps, unless someone knows of a way to make them “automatic”.

Cheers!

Would this mean that Rhino would have, with this snap active, constant ‘Near’ type snapping to any and all surfaces?

-Pascal

Hi Pascal,

Well, I’m not sure if “any and all” is what is meant. I am thinking more along the lines of how SketchUp tracks a “face” (i.e. surface) whenever you hover over one with any tool. Not sure how this could be accomplished in Rhino seeing as SketchUp uses polygon meshes for surfacing as opposed to NURBS. But if this could become a feature in Rhino, it would make modelling more efficient, in my opinion.

Just a thought…

SketchUp Line Draw – Face Constraint:

SketchUp Move – Face Constraint:

yeah… it would also kill two birds with one stone… the people that don’t want snaps to happen on points ‘behind’ objects… the all time surface snap would have precedence over other snaps… so an end point which is behind a surface wouldn’t register…

ie-- it would solve this:
http://discourse.mcneel.com/t/stop-object-snapping-to-stuff-behind/7416

in rhino, it would be better than the comparison application (sketchup) because ‘surface’ would be an osnap setting which you could enable/disable… if ‘surface’ is on-- it won’t find snaps behind a surface… if it’s off-- it will act as it currently does… and personally, i would use both.

Well thought out…and said!! Exactly what I wanted to convey.

Thanks Jeff!

Hi Jeff- I am not sure this follows at all, if I understand… as snaps work now, unless we do some other magical tweaking, having say End on as well as this hypothetical NearSrf thing, End would be happy to find ends that are occluded by the surface, and ‘NearSrf’ has no way to know which of the surfaces below the cursor you mean.

-Pascal

Actually, I misinterpreted the “near-type” snapping, which I now understand to be the equivalent of the “near” OSNAP for curves. Yes, that is exactly what I meant and what SketchUp does. But, as Jeff pointed out, this new OSNAP feature could have the potential to out-do SketchUp’s in several important ways.

It would be VERY helpful…

Well, SketchUp does it. It won’t snap to any snap that is blocked from view by another surface unless you set the visual style to X-Ray or Wireframe. What Jeff is saying, I think, is that it would be nice if you could turn on a similar feature with Rhino, such that when “NearSrf” is checked on the OSNAP panel, the crosshair would only snap to foreground surfaces (as well as other selected foreground snaps) and nothing in behind and out of view.

hmm… yeah, i’m speaking from a position of not exactly knowing how the osnaps are currently implemented from a programming point of view…

but from my point of view, it’s similar to how other osnaps are ‘stronger’ than others…

it was sort of touched on in this thread:
http://discourse.mcneel.com/t/snap-to-grid-inoperative-when-e-g-near-in-use-on-a-line/6845

but not quite… i believe there’s another thread around here which talks more specifically about how ,say, perp & center tend to override other snaps… or have a stronger bias… so if a user is getting an ‘on surface’ snap, the other osnaps they may have on would be inactive (basically)…

that said, i thought it already worked the way i’m describing if using the current per command surface osnap but it doesn’t… it’s actually pretty good what happens with snaps behind a surface when using ‘on surface’ in that the point is projected to the surface via it’s normal… i see this a being useful so i’m glad i happened across it… but yeah, that wouldn’t qualm the wishes of people wishing to eliminate snapping behind objects altogether…

but maybe what i original said about it wouldn’t be as easy to implement as i originally guessed… or ‘magical tweaking’ would be in order.


[edit] – just realized my use of the word ‘qualm’ up there makes no sense at all… whatever though :smile:

some sort of Q word should work there.

[quote=“pascal, post:36, topic:7490”]… as snaps work now, unless we do some other magical tweaking, having say End on as well as this hypothetical NearSrf thing, End would be happy to find ends that are occluded by the surface, and ‘NearSrf’ has no way to know which of the surfaces below the cursor you mean.
[/quote]

hi pascal.

again, just speaking from an observation pov…

it does seem as if some of the required ‘rules’ are already in play… i was thinking “yeah, this wouldn’t work because what happens if a surface is behind a surface-- how will it know to use the frontmost one?”

so i tried it with a curve and the near snap… draw a curve, copy it vertically, use the near snap in the top viewport… near will always (as far as i can tell) grab the frontmost copy of the curve… (as will the other osnaps besides near-- though, using end for instance, if you offset the two lines then ‘end’ will override ‘near’ )

so that’s what nearSrf would do too.

‘qfulfill’

-qPascal

1 Like