On 2017-02-02 20:58, doug moen wrote:

Describing the position and orientation of e.g. a camera in this case
becomes awkward if you consider it as "3D rotations". It is well defined
as a local coordinate system: A location for the location origin and 3
direction vectors (3 cosines each) for the local axes, all relative to
the global coordinate system. All this again is simply expressed as a
4x4 homogenous transformation matrix, as in the multmatrix command.

To modify the camera locaton and/or orientation you pre- or
post-multiply (depending on the wanted effect) with another matrix to
get a new local coordinate system.

Carste Arnholm

doug.moen wrote

Let me clarify my statement. Euler angles is the one of the worst systems to
represent rotations in a API. Quaternions would be even worst.

I don't care which representation is used internally. It may be quaternions,
Euler angles, whatever - what is better from the system point of view. But
for the user, that means, in the language, neither one are acceptable. At
least for me, with a no-complex-numbers mind neither a pilot driver's
licence. I live with the feet on earth, a 2D surface. I can turn right or
left. I can't fly. To work with Euler angles means to compose 3 basic
rotations. In my mind, I can compose 2 at most without twisting it. The most
natural way to represent a rotation for me would be a direction and an
angle. I can't see which rotation is represented in a rotation matrix the
same way I can't see it in a quaternion. These are mathematical
representations and not modeling tools! That is my question: which is the
best modeling means to represent rotations?

BTW, unitary coordinate system change is a rotation.

--
View this message in context: http://forum.openscad.org/How-to-translate-3-vector-axis-to-a-camera-viewpoint-tp20289p20303.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Ronaldo said: "for the user, in the language ... which is the best modeling
means to represent rotations?"

Let's represent a 3D rotation as an abstract data type, call it Q. As a
user you don't care about the internal representation.

Construction of a Q:

q = q_from_axis_and_angle(axis, angle) -- axis is a [x,y,z] vector
q = q_from_directions(forward_direction, upward_direction)
q = q_from_xyz_angles(angles)
From Euler angles, using the OpenSCAD convention.
q = q_from_rotation_matrix(matrix)
q = q_rotation_to(from_vector, to_vector)
The shortest arc quaternion that rotates from the 'from' direction
to the 'to' direction.
q = q_slerp(q1, q2, t)
Interpolates along the shortest spherical path
between the rotational positions q1 and q2.
The value t should be between 0 and 1.
https://en.wikipedia.org/wiki/Slerp

Accessing the data in a Q:

[axis, angle] = q_to_axis_and_angle(q)
[forward_direction, upward_direction] = q_to_directions(q)
[xangle,yangle,zangle] = q_to_xyz_angles(q)
rotation_matrix = q_to_rotation_matrix(q)

Applying a Q:

vector = q_rotate(q, vector)
matrix = q_rotate(q, matrix)
rotate(q) shape -- a possible extension to OpenSCAD

Implementing this as an OpenSCAD library, I'd represent a Q as a
quaternion, specifically as a 4-vector, [x,y,z,s], so that's what you'd see
if you echo'ed a Q. There are other possible internal representations for a
Q, but the quaternion representation would be the most efficient. The
internal representation shouldn't matter to users: you would not normally
attempt to construct a Q directly, you'd only use the library functions.

On 3 February 2017 at 09:28, Ronaldo rcmpersiano@gmail.com wrote:

Adrian said:
So, I have three orthogonal vectors and I wish to set my viewport to the
'top
view' of these vectors.  How would I go about doing that?  I'm thinking that
I would have to modify the $vpr variable, but how?

The QT5 quaternion package has a function that constructs a quaternion from
3 orthonormal axes. So if we add
q_from_axes(xaxis, yaxis, zaxis)
to my proposed Q library, then Adrian could probably write
$vpr = q_to_xyz_angles(q_from_axes(xaxis, yaxis, zaxis));

I haven't actually started to write any quaternion code yet. But there are
lots of open source packages to copy from, and the QT5 code could be
starting point. Eg,

https://github.com/RSATom/Qt/blob/master/qtbase/src/gui/math3d/qquaternion.h
https://github.com/RSATom/Qt/blob/master/qtbase/src/gui/math3d/qquaternion.cpp

On 3 February 2017 at 11:29, doug moen doug@moens.org wrote:

Ronaldo said "applying quaternions to rotate points is quite slower."

I didn't know this. Rotating a point using quaternions is 24
multiplications, vs 9 multiplications (using a 3x3 rotation matrix) or 16
multiplications (using a 4x4 rotation matrix).

If you are performing a large number of these quaternion operations during
each frame of a video game, then it could be a significant performance hit,
relative to using a 3x3 rotation matrix. Especially since I suspect GPUs
have hardware support for matrix multiplication. In the context of game
programming, you want to have both rotation matrixes and quaternions
available as tools.

In OpenSCAD, execution time of a script is usually not an issue, it's
usually CGAL operations on complex objects that limit performance. The
evaluator is extremely slow compared to C, so if the performance of the
rotation library does turn out to be important, then hard coding the
operations in C is going to have a much bigger impact than the actual
representation chosen for 3D rotations.

The other general representation that makes sense to me is a 3x3 rotation
matrix. A few of the operations I specified would require conversion
to/from quaternions to implement, so you'd still like a quaternion library
to implement those operations: q_from_axis_and_angle(), q_rotation_to(from,
to) and q_slerp(q1,q2,t). Slerp is quite useful for animation.

General purpose 3D graphics libraries provide both matrices and
quaternions, so I guess the right answer is to support both.

On 6 February 2017 at 09:47, Ronaldo rcmpersiano@gmail.com wrote: