@dale@pierrec see at exactly 0:30 that’s a gumball with aligned directions + normal.
Please, can you have this ready as internal function in 9 for other developers to use? Be it c or c++ or whatever…
Exposing this “single arrow gumball” to rhinocommon would be awesome, but if this is a limit, at least do it for internal use, please!
This is 10+ years late already.
Plasticity is having this after 2 years from initial release, while it is not a “surface modeler”, and Rhino is not getting it… after more than 20 years?
I’ve moved your comment to the Rhino Developer category so we could discuss further.
Rhino’s MoveUVN command pre-dates our gumball tool. Having this functionality built into gumball might be more intuitive. I believe this is what your comment is about. Please correct me if I am confused.
If I understand correctly, you’d like to move surface control point just like the MoveUVN command?
Any additional comments or clarification is always appreciated. Just trying to figure out how to help.
My understanding on the situation is that there is no “class” for a simple gumball composed by just a single arrow or any other draggable UI element.
The only gumball class accessible is a version with 3 arrows, strictly at 90 degrees each-other.
I think even your own developers would use it if existed, to add functionalities like the one you see at 0:30. My guess is it doesn’t exist. So nobody is doing anything.
Am I wrong? Do you have something better than that 3-arrows gumball? Can you please implement it in rhino commands for 9 release?
Managing control points for SubDs is hell. Same thing with surface control points.
Many surfacing tool would benefit from a global restyle. See the video^.
But also in other situations, for example fillet, we have this 2000-vibes UI:
I’m not a heavy gumball user but I agree that it could have these options.
However, I prefer direct dragging in combination with _DragMode shortcuts. There are also options like ControlPolygon, UVN and View which I find very useful. And all one click select and drag (use ctr for “vertical” moves).
I know those, but I do have osnap active most of the time and many other geometries are on the screen.
DragMode on ControlPolygon will make you also snap to everything else, so you have to continuously turn on and off the osnap.
Also, if you have gumball ON, the central white dot will prevent from using ControlPolygon dragmode if the control point was already selected, as said here Rhino8 WIP - Gumball
So it’s a mess of turning on and off gumball and osnap. Not a solution, in my opinion.
Currently i’m using Scale command, that lets me keep everything on while i “move” a point by scaling it nearer/away from one neighbour point. Not a good solution either.
The simple behaviour of the gumball (draggable without messing with osnap) would be best.
That’s my point.
I have some other 400-ish rows of c# just to do this and I don’t like it:
If someone inside McNeel can create a set of modern “draggable UI” classes, then the other developers will have tools to create modern commands… and if exposed to Rhinocommon users will do stuff too.
Sorry, no, as we’re just getting organized. We’ve logged a lot of gumball and grip related wishes. We’re in the process of figuring what’s a priority and who has bandwidth to work on it.
If you have wishes or comments, please post them in Rhino category and not in a long, years old thread where it will be buried.
The priorities are really strange to me. Everything regarding better surface quality (even the most basic tool for simple CV modeling) is for some strange reason always considered “Class A” or “Automotive” and therefore not Rhinos core market, because someone made a survey that came to the conclusion that many Rhino users are working in the architectual field.
Probably not the time and place for a “rant”, but still I think its the wrong way round. Rhino does not have a big market share in quality surfacing because Rhino does not have any high quality surfacing tools. And to deal with that, Rhino decides not to develop any quality surfacing tools because it does not have a big market share in that area…
Good surfacing quality doesn’t make things “automotive”. The automotive industry just happens to use the best surfacing quality available. Many Rhino users are Industrial Designers who want better surfacing quality.
Blender showed everyone that if a company provides the tools, the professionals will come and jump on board.
The quality surfacing market is in a similar situation like 3D animation/CGI was with Maya etc. insane annunal costs per seat ($$$$$.$$+) and little to no progress but still total dependency on these tools due to the existing pipelines.
You guys could break the mold, but decide not to.
In that regard Autodesk was smarter than Rhino in buying VSR and killing it before it became a competitor .
No I’m not going to repost all my wishes and proposals I did over the years. After posting many ideas for better surfacing tools for over 8 years in this forum with exactly ZERO results I have given up.
I’m still happy with the great work you do and the fantastic support you provide. Thank you for that!
Is the development about this already finished? I hope not. What about SubDs?
I wanted to discuss about it but never got a reply from Joshua..
The new “widget” is interesting (now even as 2D elements on screen space, nice!) , but the arrows have an absolute size related to the control net wires size.
This is not good, as sometime you micro-manage control points really near the geometry, and such arrows spawn too big and completely out of the screen.
The usual fixed scree-size as the normal gumball would be good.
Also, I updated my Rhino 9/WIP and TestMoveUVNWidgets command no longer works.
With this thread I wanted to suggest on developing a proper c / c++ / c# class for a new type of gumball, to be accessible also for users through SDK or rhinocommon.
I see Joshua did something in that direction… (or not?)
For surfaces TestMoveUVNWidgets was good (even though it’s an additional layer of abstraction over an obsolete command like MoveUVN… imo).
But for SubD it still generated a fixed set of 3 arrows, strictly orthogonal each-other …
Please: literally recreate a better “widget” from scratch and replace it everywhere (see my third post about fillets UI/UX too) and make it accessible for users.
Current gumball class is not enough for 2025.
Please, SubD need better workflow for micro-adjusting control points. Few clicks. Fast. Simple. See other softwares.
This was one of the big reasons why I switched from Cinema 4D to Blender. In Cinema I had to constantly click on the axis arrows to move, scale or rotate something, in Blender I just need to hold down the MMB and point to the direction or what I want to do. This increased my modeling speed several times. I think the author of this topic meant the same thing when he compared Plasticity and Rhino. Yes, Rhino is a more serious program than Plasticity, but it would still be useful for it to be able to change geometry on the fly, rather than having to go into additional settings that can be called up by some additional method.
the issue is about adding moveUVN widgets. So that issue is closed, that’s simply how our bugtracking system works. It doesn’t mean that the feature itself is finished.
At the risk of offending someone… please forget about MoveUVN command, make something new, from scratch.
New gumball class, new deformation algorythms, new UI/UX.
The toggle for those widgets is inside MoveUVN window. At least make the toggle reachable from outside or from a command line.
Are those “widgets” only an additional layer of abstraction over the old MoveUVN command? Please avoid so.
If you managed to create a new class of gumball which is free from the old “3-orthogonal-arrows” limit… good! Clean that, make it stable and reliable, maybe also let user use that class through rhinocommon… and then go berserk with new functions for actual surfacing!
MoveUVN, SoftMove, SoftTransform … all old!
With just those new widgets a whole new set of editing workflows can exist, much faster, accurate and simpler than before. Please aim to achieve that.
I wasted so much time trying to do it myself, but SubD topology, gumball class, and real-time updated preview were impossible to combine for me.
I’ll try again if there will be some new tools in rhinocommon… maybe then i’ll stop bothering you about this.
These new controls are a prototype for a set of new in-viewport user interface widgets that we are actively working on for Rhino 9 and yes they would be exposed through both the C++ SDK and RhinoCommon. The clickable widgets in the FillSrf command are also part of this set of prototype widgets.
