twist angle unavail and odd

[GoogleCodeExporter]

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 Vatan....@gmail.com on 30 Jun 2014 at 2:34

[GoogleCodeExporter]

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 comment by Vatan....@gmail.com on 30 Jun 2014 at 3:31