@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!
