Softimage was pretty good until Autodesk killed it
Did I say XSI? I said Softimage. Softimage is waaaay older than 20 years old.
Softimage was primarily NURBS, if you were not doing hack work. Film industry standard workflow was NURBS, and Softimage ruled, until Autodesk tanked it. I owned a seat and used it on an SGI and then an Integraph workstation. If anyone at the time had problems NURBS modeling fast and efficiently in Softimage, it was the user’s lack of intellect and/or ability.
The thing you think was a gumball in SI was a gnomon, which is entirely different.
Guys:
Gumball can always take more modes without having to display all at once.
Move
Rotate
Scale
All together
The more flexibility for the user the better.
There could be an option to include drag arrows and the ones that want it can just check a checkbox.
You think too hard on obstacles and compromises where the solutions are easy: → Options ![]()
I repeated the “options” thing for years, yet every single developer plus many users were against the optional “Drag strength” handles. I’m pretty sure that at least half of those people will like the extra “Drag strength” handles as soon as they try them in real case scenarios. The other half will refuse to admit that they also like the extra flexibility.
Of course, people who don’t use the Gumball or regularly work on less precise models, such like SubD or general purpose modeling, never use “Dag strength” anyway. Those people may consider the extra handles as a nonsense. It’s understandable. I even know people who think that Gumball is useless. Having no options is the worst option.
Do you have any evidence (video) to show how superior the Softimage (not to be confused with the far more popular Softimage XSI) was compared to Rhino? Maybe you mean Softimage 3D instead? The NURBS capabilities of Softimage XSI 10 years ago were far far worse than Rhino 2’s, so I’m curious how their older version with no “XSI” in the name performed.
Can’t you try some sort of gumball bounding box? If the individual gumballs get within 1,5x their bounding box, display only one?
Also, I think it’s easier to move the gumball to the last selected CV, that way, you can change it easily without redoing a large selection. For example, if ring/looselection fir CVs were added as a modifier + fouble click, you’d do that on the control polygon, then pick the point to move from (if it can’t have all the Gumballs displayed in the first place).
As for drag strength, it shouldn’t judt be the horizontal mousewheel. Preferably, you should make it a modal thing with single press hotkey that you can remap specifically for the gumball. Think of Blemder’s modals if you are familiar with that. Though that might be too much of a UI/UX change for now…. ![]()
I already have two icons for toggling the drag strength between (icon #1) 100% and 10% (Cplane), as well as (icon #2) between 100% and 2% (UVN). These can be assigned to a key, but it’s still cumbersome compared to having secondary Gumball handles for an instant access to the reduced drag strength. There is a slight delay that occurs during the toggle process.
Check post #68 here:
Plug-in food for Rhino is the only way~
This is going nowhere.
The goal was to only have one gumball showing when selecting multiple control points. I think if I hid some based on some how they overlap or other heuristic it’d just as likely I’d hide the one you want to manipulate. That’s also why I implemented the realignment on relocate. I think what you’re getting as is it’s backward and now that I think through it I agree.
This seems to be the solution. We should align to the last singly selected control point since it will be nearest your cursor so you can drag quickly without a lot of jumping around. I opened RH-89017 to change this.
I think that’s how it was done in T-Splines.
This automatically means that, everytime you want to change the grip of the gumball, you’ll deselect and re-select it.
Ctrl-click and Shift-click. 2 inputs
It’s already a workaround instead of an actual solution ![]()
The relocating feature is not good, 4 inputs. Too slow.
When you are micro-fixing the control points, you do many small adjustments.
Click-n-drag, click-n-drag, etc etc.
This “workaround” will require the user to make 2 additional inputs for each and every grip adjustment.
Please consider carefully what i’m writing.
It’s the difference from a tool that actually people will use productively daily to a semi-feature that people will use just in desperate occasions.
This is the only real solution:

Click-n-drag , click-n-drag, quick, efficient.
Imagine doing “relocate gumball” or deselect-select to move the gumball each and every time ![]()
The gumball UVN mode on the gumball would move all selected control points individually along their local normal when one is dragged. This gif makes it seem like you only want to move one at a time?
Fall-off feature.
Which you pick make difference.
this should be the final work speed:

but, applied only on the set of selected points.
A single “click-and-drag” for each grip adjustment.
(my 5-minutes script fails a lot here… )
On SubDs.
With an arrow for each other connected grip, and of course the normal arrow.
Also about the “soft deform” or “fall-off” thing… we should have an option for it to work only on the selected grips or also on the non-selected ones, otherwise for global editing with fall-off you’ll have to always select the whole shape (all the grips) and the visual will be clogged by yellow highlighted grips and control nets.
This problem is so broad that I’m happy McNeel finally is thinking about doing something, but I’m really scared if the final solution will become a “workaround” … as often happens.
If possible, it might make sense to activate the gumball for the CV you are hovering closest to, but in that case it should only apply to an existing selection. That way, you don’t accidentally select a CV that’s not visible in view and you don’t have to select a CV before moving.
E: Best to add a user definable timer function in that case so it is as slow/ fast as people work and they’ll get to work the timing out, just like with the instant Aliases.
I’m glad you’re excited and appreciate all the feedback. I’m in the same boat as you wanting this to be a nice well thought out tool and not another workaround. I’m reconsidering having a widget appear for every selected control point. I don’t think there’s a good answer yet for dense selections but that popup as you mouse over is a decent idea. That needs to be resolved. I do think these tools will need to be integrated into the gumball though. One thing that was readily apparent with the MoveUVN widgets was needing to switch between UVN and World/CPlane alignment for transforming. Whatever widget is shown needs to work with the gumball since it’s not going anywhere.
Absolutely. Please.
Alias has several different types of control point transformations. Two of them (UVN mode and Control polygon mode) activate 4 tiny arrow handles around each control point of the surface(s) with shown control points. This means that a Bezier surface with 6x6 control points has a total of 144 tiny handles shown simultaneously. However, Alias uses the RMB to move the control points along the normal direction, which Rhino doesn’t. This means that in Rhino each control point must have 5 UVN handles (4 for UV along the control polygon, and 1 for N).
The VRS plug-in for Rhino 5 has a similar tool (VSR Control point modeling) with the UV arrow handles shown upon mouse hovering next to the closest points or control polygon, as well as the new Cyberstrack plug-in for the newer Rhino releases. However, both plug-ins feature giant 3d arrow handles that are an overkill in my opinion. I much prefer the clean look of the tiny arrow handles used in Alias.
Hello Joshua,
I know I’m repeating myself, but what you are describing is the “preset” concept.
You preset a direction, row or single CVs, and just start modelling. This way, CV modeling becomes more of a sculpting workflow.
The “peset” concept solves most of the workflow problems:
Choosing between single CV or row of CVs
Dense objects are no problem either, as the “preset” describes the movement and direction regardless of the number of CVs. You just click and move the CVs.
With presets you can switch between UVN and World/CPlane also.
Even a soft-transform/falloff logic could be applied this way.
Selecting CVs first to have a widget appear should be avoided at all costs, as it DOUBLES the workload. Each CV is basicially touched twice. Once to select it and the second time to move it. If you are doing this for 8+ hours a day, this becomes torture.
Short clip of ICEM, to show the workflow (and to show where I stole the concept from
)





