Interesting
When you will do that for subd cages then please do it also to work with surfaces CP. I know there are other options for surfaces but it would be great to have one tool for all. Cheers!!!
Why this extreme narrow focus on this newly created ticket for a four year old request? Because if you do falloff, why restrict it to SubD? Why not fix all existing horrible soft modification tools at the same time and unify the ux/tool algorithms?
fair point. I will add that to the discussion-
Probably OT.
Often I see you devs work for a “quick solution” that does the trick, like recently I’ve seen proposed to add a literal python script to built-in rhino commands (align grips to circle…)
That maybe will work, but wouldn’t it be best if proper changes are made at a lower level?
I speculate rhino core is c or c++ on the lowest (less abstract) level.
Then we have a lot of methods via c# , then python, grasshopper, etc etc…
For example: the gumball.
The gumball combined with a “dynamic preview” (while dragging), is a mess.
I tried to both use the default one (limited to always 3 orthogonal arrows ) or to make a new one… a mess.
You feel the UI is fighting with all other parts of rhino, some simple operations create stutters on screen, etc etc…
Wouldn’t it make more sense for you devs to build a proper gumball or “handle” or “clikkable/draggable UI element”, that is more versatile, customizable, etc etc?
Most of Rhino command interactions seems to be limited to a simple line segment (from A to B, like during move) or a circle (like with rotate) … that’s a limiting UI/UX!
Maybe if a more serious “handle” is developed at c/c++ level (and then maybe made also accessible for c#/python) it would THEN make developing all kinds of soft editing tools simpler!
Hope what I wrote make some sense.
You devs know best.
Sorry for the OT.
To be clear, I’m not a dev… I’m an artist and a user (also tech and trainer) , but I get what you are saying.
I’d have to have the actual devs chime in on what you are proposing as doing a major rewrite on a major component of Rhino is far beyond my pay grade.
Oh, ok, I didn’t know this.
As I was somewhat quiet last month ( ) … i’ll now summon…
@dale @stevebaer @brian @pierrec
Sorry for bothering.
What do you think about my last comment ^ ?
Also please consider reading
… as it is extremely interesting and spot on.
Seems like a decent proposal. Writing low level tools for widgets like the gumball are done in C++ and take quite a bit of time to get them to work properly with an understandable SDK.
As the default gumball accessible from c# is not good for me, I tried to make one…
I did found myself doing on-screen 2D intersection and line-closest-point methods only to make the gumball behave like I expected, and then translating that single value into an interactive transformation for my selected grips. A mess.
If developers themselves do not have something better in c/c++ , I imagine they would “struggle” in a similar way every time they try to make a new soft-edit command.
We need MoveUVN to be forgotten.
MoveUVN is “East”, we need to go “West”.
Diametrally different approach.
Other users like @gustojunk use alternative software and can report UXs there, and ask for the same here in Rhino.
Too many words again, sorry.
Have a nice weekend!
The gumball has never been a stellar example of our SDK. We know it is difficult to work with and hope to improve this in the future.
Hello. I would just like to reference a thread I made that might have relevance to this thread. I talk about the features in alias, IMO, that would be great for rhino subd .