I’ve wondered since shortly after starting using Rhino, why there is not an option for Rotate3D to set the axis to a line. It seems like it would be pretty straight forward to have the tool set the rotate axis to the two points of the line. Quite often I find myself rotating a part on its edge and this would reduce the number of clicks as well as the possibilities of error due to the wrong point being picked. I realize there are several ways of approaching it, but I keep coming back to the idea that this would be a smoother workflow. I’m interested to hear any other thoughts about this.
Hi Ryan -
I’ve written that up as RH-90365 Rotate3D: Allow Picking Curve
-wim
rhinopython/spb_Rotate3D.py at master · CADacombs/rhinopython · GitHub
is a script that wraps _Rotate3D with an added option to derive the rotation axis from a line, arc (through its center and normal to its plane), cylinder, cone, or torus.
(The UseLastAxis option is not included.)
Thank you, I appreciate it.
Excellent, I thought about giving this a go, but I just haven’t felt like I had the time. I will try it out in a little bit. Thanks for sharing.
@KelvinC
Using a line as Axis is great.
I do not understand the concept of using a startpoint-Endpoint Axis from a Curve.
Is there a typical use case i miss ?
For a curve i would expect that same behavior as for _cplane _curve
select the curve, select a point on the curve, the tangent will become the the Axis of the rotation.
This will add functionality to the command - at least for lazy people that do not use _cplane…
defining start and endpoint - can be reached with the standard approach of clicking 2 points - the start and end point…
kind regards - tom
Sorry for the late response I just found this as a draft response I never submitted.
My main objective was to gain access to straight lines and segments. Off the top of my head, I can’t really think of how I would use the semi-arbitrary lines assumed from an arc or end points of an arc, but my intuition says that the end points are geometrically more reliable points to reference.
sorry to insist on this - this is a stupid new option/feature.
it will only introduce new inconsistencies.
The feature / workflow is already accessible by snapping to both endpoints. Also with 2 clicks.
(click 1 startpoint, click2 endpoint)
the same amount of clicks:
(click 1 select option “curve” click 2 select curve)
what s the benefit ?
where are at least 5 sample Workflows from real world modelling challenge where this option is essential ?
i can not imagine one.
but i can imagine _revolve allowing a curve to be selected as axis:
the user will expect some fancy inverse railRevolve-like-deformations:
all other commands that use curves as input use the shape of the curve not just the endpoints.
usage from youtrack:
i really hope this will not make it into the final rh 9 release
Out of curiosity, what is your concern with this option? If it is not the default, how does it negatively affect your workflow?
I have been using this regularly and have found it quite useful.
I have somewhere to be but will come back and expand on this later.
I have to teach it to my students and they will ask all sorts of questions.
Rotate3d is a top 100 beginner s command it should stay simple.
To many options will not make rhino a better program. Its just disturbing noise/load especially for beginners.
I don’t like options that I would never program for one of my customers/ plug ins.
And i don t want to teach… just ignore this or that option … and for the next command i have to teach that it s super important to check an option.
I understand the teaching concern, especially with a command like Rotate3D that is used often by beginners. I agree that adding options just for the sake of adding options can make commands feel noisier, and I also understand not wanting to teach students “ignore this option” in one place and “pay close attention to this option” somewhere else.
That said, I think this particular option has a practical benefit that is easy to overlook if the workflow is viewed only as “two clicks versus one click.”
For me, the advantage is not just click count. It is reducing the number of precision-dependent picks. I use Rotate3D constantly, always through a keyboard alias, and in my workflow being able to define the axis from an existing curve means I can often reduce the operation to selecting known geometry instead of manually snapping to two endpoints. A missed or slightly inaccurate snap may not be obvious immediately, especially if it is only off by a small amount, but it can create stacked errors that are harder to trace later. By comparison, selecting the wrong option is usually obvious and easy to correct.
So, the benefit is not that this makes an impossible workflow possible. The current endpoint-snapping workflow already works. The benefit is that it can make a common workflow faster, more reliable, and less dependent on perfect point picking when the axis already exists as model geometry.
I also do not think this needs to complicate beginner teaching if the existing default behavior remains unchanged. Beginners can still be taught the simple point-to-point axis method first. The curve option can be treated as an advanced convenience, similar to many other Rhino command options that become useful once users are modeling faster and reusing existing geometry more deliberately.
Regarding the concern that users may expect the curve shape itself to affect the rotation, I think that can be handled by clear command wording. Perhaps something like “AxisCurve” or “UseCurveAsAxis” would make it clear that the curve is being used only to define the axis, not as a deformation rail. Rhino already has many cases where selected geometry is used as a reference rather than as a full shape input, so I do not think that expectation problem is unmanageable.
I am not heavily invested in whether this must be added to the next release, as long as I can still script the workflow. But I do think there is a real modeling advantage here: fewer precision picks, less chance of tiny unnoticed snap errors, and a faster path for users who already work heavily with aliases and existing construction geometry.
I tried to attach a video demonstrating a few times I used this today, but the video file size is too large.
it s also about consistency.
see also this topic:
a nice approach / implementation that would not disturb any newbie would be a nestable command similar to _distance _radius _IPlane …
_CurveEndpoints - that would enter start and endpoint of a picked curve (or segment)