Rhino BETA Feature: UVN Gumball

I wonder why CTRL is for symmetry.
In other comparable situations it’s always SHIFT.
image

BTW, I don’t understand what Absolute (the SHIFT mode) does.
Please explain.

Absolute mode moves all the control points the same distance. The default is that each moves proportional to the length of the control polygon chord. Moving the control points proportionally is necessary to maintain G1 continuity at the boundary. I added the absolute option with shift first to match the control polygon drag mode. Control just happened to be free when I added the symmetry. I do think shift makes sense. I can swap these to be consistent but I think I’d also need to change how the control polygon drag mode works.

Thank you for adding this feature, but I think the Shift key would be more suitable than Ctrl.

I hear you. I opened RH-94453.

I agree SHIFT is more appropriate for Simmetry.
Thanks

I also vote for Shift to activate symmetry. :slight_smile:

RH-94453 is fixed in Rhino WIP

RH-91153 is fixed in Rhino WIP

The new behaviour with sub d vertices is off. When a subd vertex is moved with the gumball that changed isn’t always mirrored with reflect / symmetry on.

Turn symmetry on for sub d model

Gumball set to align to object

Select Sub d vertex light grey side of symmetry line.

Move along any direction

Changes not applied to the other side of the model.

On a MBP with latest WIP build.

HI @john19 - There are some things to iron out with the Gumball Object alignment on vertices. We are working on them.

Thanks for the Reflect bug! It’s logged here, RH-96359 Gumball Object: doesn’t work with Reflect.

@Vanessa (or anyone else), do the alignment issues include the reason why when I click on a control point of this SubD only the blue arrow shows up?

Or is there a setting I’m missing? I keep seeing examples on this thread that show the other axes.
Thank you

More specific—arrow display feel inconsistent… or is this behavior intended?

@René_Corella This is because you’re selecting an extraordinary point. Dart and star points don’t have UV directions, so we only show the N (Normal direction) arrow. for SubDs, UVN arrows will only appear on quad topology. If you have a multi-selection that includes an extraordinary point, it will also only show the N arrow.

Extraordinary Vertices

Does that help?

(PS: in the process, I did find a bug, so thanks for asking :glowing_star: :smiley: ).

@Joshua_Kennedy you confirm this?

Please let us have full gumball also for extraordinary vertices. Having only normal direction is too limiting.
Dragging the control point on a direction equal to one of the connected control net edges… it’s needed for normal vertexes but also for extraordinary vertices.

seems related to this:

control points loop selection happens to be unrelated to the very first first selected grips.

The Gumball placement could also be improved. If I select 3 points, as in the example above, it would be more intuitive for the Gumball to be positioned at the center point between the selected points. Likewise, if I randomly select 7, 12, 25, or more points, I think the Gumball should be placed at the centroid (center of mass) of the selection.

My understanding is U and V directions are not defined at extraordinary vertices by the math.

U & V specifically may not be defined - but would it not still be useful to have a constrained axis to move the point along?

The “cage lines” seem to be definable (since they’re in the display) - from a user perspective they could be natural constraints along which to shift the CP.

I would rather call these handles “control polygon handles”. “UV handles” sound misleading, because the handles are actually placed along the control polygon. These should be visible even on “star joints” such like 3-star, 5-star, 12-star joints, etc.
They still share a common blue arrow for the normal direction, but the rest handles are not UV in my opinion

RH-96359 is fixed in Rhino BETA