On 8/5/2011 12:46 PM, Wesley Smith wrote:
typically, vector multiplication is treated as either dot-product or
cross-product (with cross-product only existing in certain numbers of
dimensions, such as 3 and 7, and "sort of" in 2).
This is exactly why I said "vector algebra considered harmful". The
cross product is actually a shadow of a more general product called
the outer product, which is defined in every dimension and not just
for vectors. The dot product is the inner product. The geometric
product is a combination of the inner and outer products. The
geometric product of two 3d vectors is a quaternion.
fair enough.
generally it works though, and for 3D leads to the convention of 3D
vector operations:
add, sub, scale, dot, cross.
as well as vector length and normalization, ...
as well as some special-case operations, like lerp and bspline
(interpolate between several points along a Bezier spline) and similar.
then one can create a sort of basic "mathematical toolbox" of sorts.
for 2D and 3D, vector math works fine.
and in 3D, vector math is much nicer than 3D trigonometry.
To see what's possible when you don't confine yourself to vector
algebra, have a look at A Treatise of Plane Geometry Through Geometric
Algebra[1]. Saying that vector algebra works fine to my mind is like
saying that programming in assembly works fine.
well, we also often constrain ourselves to a 3D euclidean space as well.
it all maps fairly nicely to the world in which most people live (at
smaller scales, people can assume that space is euclidean and everything
works fine).
but, anyways, would you rather have people constrain themselves to raw
algebra+trigonometry instead?...
and, also, I do use some amount of assembly programming...
apart from its terrible portability, it is actually fairly useful.
quaternions also exist, and can be useful, but for many practical tasks
(such as performing rotations) share an ongoing battle with matrix-math, and
in some cases with angle-based systems.
may as well include quaternions as well though, since as I see it there is
no fundamental conflict between them and vectors.
There's no conflict but if you confine yourself to vector math, you're
losing a large chunk of the higher level structure available.
Culturally, we've been indoctrinated into thinking that matrix math
and vector algebra is the be-all-end-all of spatial computation when
it's really the lowest level representation. There are much richer
languages out there that deal with hierarchies of subspaces [2].
one doesn't have to "confine themselves to vector math".
I was never saying here that one can't use anything more advanced, only
that often, for most simple tasks, vector math is a fairly
straightforward strategy.
now, as for quaternions vs matrices, each has pros and cons...
IME, rotation matrices are a little easier to visualize, and,
conveniently, just happen to contain the unit base-vectors for their
local space (relative to their parent space). often, these give them a
slight advantage despite needing more numbers.
a downside of matrix-math though is that (if used as a "canonical"
rotation) one needs to regularly fudge with them to keep all of the unit
base-vectors as orthogonal and normalized (I have some code from before
I had understood quaternions that could have been much nicer had I used
them, me having written slightly hairy-looking code for handling
renormalization and interpolation of matrices).
more convenient IME then is to keep the canonical rotation as a
quaternion, and then use matrices for many leaf-calculations (with a
little code to convert between them).
some cases though are still better expressed with angles (mostly because
angular systems can be made more easily self-constraining), despite
angles sucking for general-case rotations.
[1]
http://www.lomont.org/Math/GeometricAlgebra/GA%20Treatise%20A%20-%20Calvet.pdf
[2] http://faculty.luther.edu/~macdonal/laga/
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
