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

BTW, I don’t understand what Absolute (the SHIFT mode) does.
Please explain.
I wonder why CTRL is for symmetry.
In other comparable situations it’s always SHIFT.

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. ![]()
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.
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.

Does that help?
(PS: in the process, I did find a bug, so thanks for asking
).
@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