When I use the point command to place a point, then I click on some surface to place the point on that surface, the surface is ignored and my point ends up on the CPlane. Why is this? I cant imagine any case in which this is the intuitive or desired behavior, especially in shaded mode (or any other opaque rendering mode).
I’m aware that you can hold control and hover over the Osnap menu to see some secret options for placing a point on a surface, but why this interface? Could we at least get a pointOnSrf command or something?
Does anyone agree that this is a strange UI? I feel that Rhino is superior to other CAD in that it requires less clicking than most programs, but placing a point on a surface feels like it takes far too much clicking. Do people agree? Am I missing something?
because you need to tell Rhino that you want to place a point on a surface.
Start the _Point command, do what you describe above and actually click on the entry “OnSrf”, then Rhino asks for a surface and the cursor is constrained once to draw a point on the surface.
You might look into one shot and persistent object snaps in the Object Snap toolbar to learn more. The OSnap panel is just a shortcut to these snaps.
I’ve looked into Persistent Snaps, and they don’t seem to help. They are only persistent for the duration of a command. This means that to place 10 points on a surface using the point command, I need to click 40 times. The four clicks that I’m refering to: Right click to repeat the command, control click to turn on OnSrf, click on the desired srf, then click the point.
A pointOnBrep command or something like that could bring this click count down by 4x, and would be incredibly easy for developers to implement. 4 clicks per point seems like a bad UX.
Another Idea, rather than opt into placing a point on the surface that is clicked on, opt out of using the surface. I feel strongly that when the average person uses the point command and clicks on a surface, their intent is not to place a point on the c plane behind the surface.
Why are you trying to place 10 points on surfaces? There’s like no reason for this. You can also make a buch of points and Project them on to a surface if you really really want.
No, you would run the _Points command, chose the _PersistentOnSurface snap and select the surface so you can place as many points on the surface as you want while the command runs. You could even put this into a macro if you need to do this task often to save some clicks:
! _Points _PersistentOnSurface
The behaviour of the point picking mechanism you’re expecting to happen by default would be extremely recource intensive. Imagine working on a scene containing thousands of geometries, Rhino would have to cast and intersect a ray whenever you move your mouse to find out where you want to place the point. That is the reason why you’re asked for a single object to constrain to.
Maybe, but it’s never been asked for in case of breps or surfaces. It exists for meshes (_SnapToMeshObject) and subds (_SnapToSubDObject) and needs to be disabled afterwards which may be the next issue users complain about…
Casting a single ray through thousands (or even millions) of geometries is incredibly cheap (milliseconds) using the right acceleration structures, so that should not be an issue.
I think that adding a SnapToSurface snap would be great. I don’t see any reason not to have it.
[Edit]: Also building a macro or writing my own command is not the goal, my goal it to help improve rhino. I could easily implement all of this stuff for myself in RhinoCommon.
[Another Edit]: Also, casting a ray is not necessary. You could rasterize Guids to a buffer and perform a lookup in that buffer depending on what pixel is clicked on. This brings performance from Log(n) to 1.
No, it’s not, at least not in Rhino. I’ve been writing such tools in the past, eg. for a single mesh with millions of faces it is very slow to constrain the mouse to. Even starting the point getters .Constrain() can take seconds as Rhino makes a copy of the mesh whenever the point getter is initialized. You can read about that here.
There is no reason to copy the mesh in this situation. Maybe Rhino does for some reason, but this is a flaw in Rhino. An ez solution to nonsense copying is wrapping rhino geometry in a COW (copy on write). Maybe Rhino 9 could get some performance wins by eliding unnecessary copies.. Idk. Anyhoo signing off. Thanks for your time, and I hope these concerns are acknowledged.