Direct surface control point manipulators and UVW improvement


(B Design Bg2) #1


Is there any way to directly adjust the position and rotation of individual or multiple control points with “arrow manipulators” similar to the ones shown in the following video at 5:14?

I regularly use the UVN tool, and I’m also aware of the holding down the Alt key while building a “Blend surface” to rotate it’s end control point manipulator, but I often need to manually adjust already built surfaces and it’s a lot slower and less interactive to move control points indirectly from the separate window of the UVN tool.
Not to mention that when the surface control points are turned on and the UVN tool is active, there are no visual indicators with letters on the surface to tell which direction is U, which V, and which is N, nor it will show whether it’s positive or negative direction (left and right in the UVN window). A few simple letter icons (U, V and N) would do wonders and prevent frustrations with moving the wrong slider, resulting in often use of Undo.

Arrow manipulators are a great way to directly interact with the control points exactly where they are located and I see them as a good alternative of (and sometimes better than) the UVN tool. Until then, I mostly use Scale 1D to move the control points, as well as UVN tool and the Gumball.

Currently, the closest thing to the arrow manipulators is the Nudge keys functionality (Rhino options > Modeling aids > Nudge), but this only works with presets of distances and forces the modeler to often leave the mouse and move his or her left or right hand to the arrow keys. I use 3d Connexion mouse with my left hand and Logitech G502 with the right one, so obviously working with the keyboard’s arrow keys (and Ctrl and Shift keys as modifiers for the alternative Nudge distances) at fixed preset distances is not the most effective way to manipulate the control points.

There are also two things that could be improved with the “Pickable polygon” setting (Rhino options > Mouse > Selecting > Make control polygon pickable).

  1. It’s fairly easy to accidentally select couple of control points instead of a single one. If there was some way to disable picking the control polygon in less than 10-15 pixels next to a control point (the so-called dead zone), that would be resolved just fine. It’s even better if the modeler could choose custom dead zone measured in pixels.

  2. While holding down Shift and clicking on the next control polygon to select additional control points, that will actually de-select previously selected control points. This is something that needs to be fixed, because it’s confusing to de-select with Shift, which is always used as “add to selection” for the rest tools in Rhino.

It would also help a lot if it was possible to right-click while dragging a UVN slider, in order to cancel the current adjustment of the control point(s) and move it back to its original location. This kind of right-click cancel/undo command is already implemented in many other tools in Rhino, but it’s really pity that the UVN tool lacks it.



(Pascal Golay) #2

Hi Bobi - look at drag modes -(DragMode command) I don’t say this solves all of your problems but it may help = ControlPolygon drag mode is one I find especially useful.

This should not happen as far as I know - it does not, here.

I share your frustration at too-easily picking a pair of points by hitting a control polygon very near a control point.


(B Design Bg2) #3

Hi Pascal, thank you for the quick response! I actually avoid using the drag mode (UVN and Control Polygon) for a number of reasons.

  1. Drag mode will not restrict the movement along given axis, instead, it allows for free-directional manipulation or one restricted to the 4 directions of the control polygon. The main difficulty is having to move the control point(s) at a very small distances where the desired direction of point manipulation could be accidentally switched to another direction. For example, if I want to move the point in left direction by just a fraction of a millimeter, it’s possible to move it either up or down, because there is no dedicated arrow manipulator to restrict the movement to the desired direction.

  2. I usually work with “Object snap” and “Snap to occluded objects” both turned on and that makes the movement of control points with Drag mode confusing, because it may snap the control point to some object in a completely different area of the scene. Again, a dedicated arrow manipulator (that’s fully independent, i.e. not affected by the object snap even if the latter is turned on) will solve this issue completely.

Attached here is a quick idea for the basic functionality of the arrow manipulators that I described in my original post. It’s a bit of a mess, but I tried to include examples and write explanations in the image for better understanding. Your team proved to have lots of great ideas for the UI of Rhino and I’m pretty sure that you can further develop this tool with even greater options and capabilities.

I guess that many people will be happy to use these advanced features for a more direct and accurate manipulation that combines several functions at one. It’s what Alias and other Class-A surface modelers use for reason, although they are more simplified and lack some of the functionality that is shown in the image.

(Pascal Golay) #4

Hi Bobi -

Right… the workflow for now is to move the point a larger amount in the direction you want and then hit the Tab direction lock.
Holding Alt will suspend OSnaps while you drag.

I do understand that it is not as handy as proper handles…
BTW, in case you have not tried yet, try DragStrength as well.


(B Design Bg2) #5

Hi Pascal, the main difference with the long dragging, followed by hitting the Tab button to lock the direction is that this is useful only at large distances, while fine tuning of the control points at extremely short distances (less than a millimeter) requires a more advanced control over the movement. To do that, the viewport camera must be set really close to the object, but another problem is that Rhino tends to have some issues with rendering too close objects as the clipping plane basically “hides” the nearby object. Doing lots of control point manipulation this way is quite slow and not only requires constant work with the Alt and Tab keys, it also vastly reduces the positive effect of using a 3d connexion mouse for camera navigation (2x modeling speed, considerably less usage of the normal mouse, and general relaxation for both hands).

This is where the “Move UVN tool” is preferable for such situations, but, as I mentioned above, it provides kind of a non-direct manipulation from a separate window.

Drag strength is a good tool, but limited by the fact that it’s a separate command and in fact people who often work with manual manipulation of control points constantly need 100% drag strength and reduced one. With dedicated arrow manipulators (or handles, as you named them) that would be so much easier, because there is possibility to implement two speeds for dragging. It may be similar to the improved Gumball in Rhino 6 that has a “ball” next to the arrow to extrude the selected curves or surfaces. Imagine if there are two arrows instead of one at each of the 4 sides of a control point (which is 8 arrows total), so that the inner arrow is used for 100% drag strength and the outer one is used for custom set drag strength. That opens whole new level for editing the control points or moving other objects. It can also be implemented in the Gumball in a future update. No more need to constantly change the settings, and focus on the modeling instead.



(Pascal Golay) #6

Hi Bobi -in V6 DragStrength is on all the time if you want it.


Tab direction lock should work with any movement - small or large. I’m not sure what you meant - can you show an example?

If you need to zoom in very close, I’d change the camera to Parallel and use Zoom Target to change the view.

I understand what you’re after with the manipulators, I’m just trying to help you get the most of what is there in the absence of these…



It would be great if one could have Alias’ NUV, etc. manipulation tool equivalent, with Alias’ interactive locator-persistent curvature comb at common surface boundaries. All the math is already in Rhino, so it’s just a proper interface, instead of these cumbersome sliders, etc.

(B Design Bg2) #8

Hi Pascal, thank you for the suggestion! I tried all possible options for control point manipulation in the recent months but none of them is capable to replace proper arrow manipulators. I guess it depends on what the users do mostly, and some people may even not need this functionality in their entire life. However, in the automotive industry and high-quality product design it’s essential to have the ability to fine adjust the control points in a proper way, both to avoid errors/frustration and to speed-up the work process. In these cases control point manipulation usually takes up to 80% of the modeling time to achieve nearly Class-A surface quality.

I just recorded a video showing my basic workflow at creating surfaces. It’s over 3 GB, so it may take a while to upload it. There was some bug in the GeForce Experience which I used to capture the video, so it was unable to record full-screen to show which icons I clicked at, and captured only the active window instead. For this reason, I apologize that it may be a bit confusing to understand what I do at certain moments of the video.

With regards to the parallel view, actually I never use it, because it’s basically impossible to see what I do at very steep angles when I move the camera very close to a surface. I often use my 3d connexion mouse to go into tight sports between two or more models, or “diving” into deep areas of the same model that the parallel view is unable to render due to its nature (example - inside a cup or house). My video also shows how helpful is the perspective mode that allows me to see whatever I want, no matter the camera angle.

I too use the Tab key to lock the direction of moving or scaling objects, but as you can see from my video, most of the time I position the camera at very steep angle so that I can see the control polygon’s consistency and smoothness while dragging the control points by a fraction of a millimeter. With dedicated arrow manipulators that would be piece of cake to do, especially if they have dual arrow manipulators for simultaneous 100% and reduced drag strength. However, from this particular camera angle it’s very confusing to use the “Drag mode” or the Tab key to lock the direction, since both of them work with less errors when I look at the control points from above (normal to the surface). But from that angle I no longer can sport the minor changes of the control polygon.

By the way, if you noticed in that video on YouTube that I included in my original post, at 5:14 that guy was forced to lose the even shape of the blend surface due to the limitations of the arrow sliders in Alias Automotive that will not allow him to “shear” the selected control points in the same fashion that I described in my picture above (moving the big white arrow A along the control polygon’s edge to “shear” the control points while preserving their original direction).



(B Design Bg2) #9

Well, I uploaded the video twice, but there was a notification about some error with posting it. Maybe the 3 GB size was the reason.

However, I made a screenshot of the video to show the typical steep camera angles and close position to the surface that are often used by professionals while they examine and fine tune the control points to achieve nearly Class-A surface quality transition.

(B Design Bg2) #10

Is there any way to implement in Rhino a tool to straighten the rows of control points of a surface, similar to what’s show in the following video at 4:10? It works by sliding the control points along the corresponding control polygon edges based on the current camera view. This is something that many users of Rhino will benefit since it often builds surfaces with twisty control polygon (especially Blend surface and Sweep 2-rail). The Match surface tool could also benefit a lot if it had such functionality with the following option: “Isocurve direction adjustment > current view”.

With regards to the Blend surface tool, it will help a lot of there was an option to straighten the control polygon based on the camera view (just like the video above), ad well as in two directions (one planar section for each end) instead of just one. The existing Planas sections is handy in some situations and I like it a lot, but it can’t resolve some more specific situations.

PS: I have several new ideas about valuable upgrades of the Blend surface tool, among with many other tools, and will post then in a dedicated topic when I have more free time.

(Pascal Golay) #11

Hi Bobi - I have a script that does that - it works, but is a little fiddly to use in the state I last worked on it , but you can have it to play with if you like.


(B Design Bg2) #12

Hi Pascal, of course, I will be glad to test it out and see if it can help with cleaning up the surface control polygons that sometimes get messy. Could you upload it here so that other people also try it?


(Pascal Golay) #13

Hi Bobi - I’ll dig it up in a bit here and make sure it does at least something useful, then post it…


(B Design Bg2) #14

Thanks! Messy control polygon is what usually takes a lot of time to fix up and if your scrips works as expected it will become one of my favourite tools with dedicated icon.

(Pascal Golay) #15

Hi Bobi - here you go -

To use the Python script use RunPythonScript, or a macro:

_-RunPythonScript "Full path to py file inside double-quotes"

This has a lot of ‘junk’ in it that might or might not be useful - I was trying stuff.(the ‘SmoothOnly’ option for example) But basically it seems to work - you select a surface and then a control point - and a direction - edges are drawn in U and V and the row of points that is affected is parallel to the direction you choose. There are various ways to set the target plane - most likely you want the ‘View’ one most of the time. (15.7 KB)


(B Design Bg2) #16

Hi Pascal, I had a chance to try your script and I have to say that it does wonders with the “Plane=View” option! You definitely have to implement this functionality as a native tool in Rhino. It’s a game changer!

However, for the moment I can access this command only when using the “RunPythonScript” command to open a Windows Explored window to manuallt select the script inside the folder where I saved it. I was unable to make it work as a dedicated icon. Maybe I do something wrong? This is what I put inside the command macro window:

-_RunPythonScript “D:\Rhinoceros 6\Planarize surface points”

Every time I click on the icon a warning windows says the following:

(Pascal Golay) #17

Hi Bobi - good, thanks for testing, I am glad it is useful out in the real world.


(Pascal Golay) #18

Make sure to put the full path and correct filename including .py:

-_RunPythonScript “D:\Rhinoceros 6\”

should work.


(B Design Bg2) #19

Thanks for the suggestion, Pascal! I got it working now. To do that I added the missing “py” at the end I also renamed the script because it had extra “_Dev” in the file name.

If there was a possibility to Undo the last change that would be great. I noticed that at the moment the script works in such way that it will run until I manually cancel it. If I make multiple modifications withing the scrip session and then Undo the scene, all of the changes that I made with the script are being Undo-ed together.



PS: This is the icon that I drew for this script:

(Pascal Golay) #20

Yeah… I’ll take a look at adding something like that but my guess of the moment is it might be hard (for me, I mean, not for a real programmer) if it is possible at all in a script. One level of ‘internal undo’ might be more tractable.

@Rhino_Bulgaria - I have an undo working, but also some crashing, so, not quite there. This script is a little unstable, I think because of the (unfortunately, necessary, I think) drawing conduit - it may well be my fault, I don’t have a good handle on using conduits reliably- they are hard to debug in the Python editor.