You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What steps will reproduce the problem?
1. create a cone
2. modify vertical angle to 0
twist vanishes
3. modify horizontal angle (ex 24), press enter
output:
horizontal field returns to 0
hidden twist field increments by inserted value
4. modify horizontal angle again (ex 12) press enter
horizontal angle sets to 0 again
5. set vertical angle to 5
twist field appears with 36 as a value
also the twist field rotates the cone around its center axis, and once i have
started fiddling with the values, both horizontal and twist only cause
rotation. I need to orient the viewer so that the cone is in profile, and grab
the rotation point so that the cone dips in a direction I want. now all
fields update, and the horizontal field does what I would have expected it to.
this behavior swaps back and forth repeatedly.
Proposed:
rename and correct backend so the angle defines the cone relative to absolute
axis
OR
create vector based input for angle
now if you add a different way of specifying the values, I would assume you can
keep both in drop down lists so that one auto-updates the other as you enter
text, so the user has flexibility to design in a manner that makes sense to
them. Also "horizontal" "vertical" and "twist" are extremely vague
descriptions of motion.
also I would personally love to see the ability to define a cone by tip or
center point location of one end, followed by cone angle and direction. that
is more generally how I design things, angle not diameters.
What version of the product are you using? On what operating system?
linuxcnc ubuntu 10.04, heekscad 1.0.0 from neomilium ppa
Original issue reported on code.google.com by [email protected] on 30 Jun 2014 at 2:34
The text was updated successfully, but these errors were encountered:
after thinking about this for a while, the axis angle should probably not be
defined by its angle off the cardinal axis, but rather the angle of the
projection of the axis onto the plane. While the first makes more sense from a
math point of view to me, it quickly overdefines the center axis. I realized
what is much more intuitive to the user would be the following parameter
"angle when looked at from axis X" which is the same as "angle off of Z axis of
projection onto ZY plane"
that can be specified three times and I think will always give you only 1 real
solution, but I think it can easily define a non-solveable geometry. Vector
would still be the easiest, but they are never user-friendly. A naming
convention is still not super clear what would be ideal, but thats always the
hardest part.
alternately 2 angles relative to planes should also get you there, which I
suspect was the original design intent. "along x" and "along y" angles could
define the axis, with "along x" being equal to the angle between the Z axis and
the vector when viewed from the y axis, projected onto the XZ plane, and "along
y" being the angle between the Z axis when viewed from the x axis, projected
onto the YZ plane.
"along x" makes sense to me since it is how much the cone will "lean towards"
the x axis. slightly better naming could be vaguer tho, like "pitch" and
"roll", which kind of forces the user to make 0 assumptions and not get tricked.
of course the backend is probably intended to only take a certain kind of
input, so however you fix it is up to you. Vectors are good (x,y,z) since
there is 0 ambiguity, but they suck since they are very non-user friendly, you
need to do math outside the program to figure out what inputs you want. angles
are nicer imho.
Original issue reported on code.google.com by
[email protected]
on 30 Jun 2014 at 2:34The text was updated successfully, but these errors were encountered: