From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2006-06-14 13:16:12
On 6/14/06, Janek Kozicki <janek_listy_at_[hidden]> wrote:
> Another question - would quaternions be something like vector<4,double> ?
> For me it looks like a good idea. Template specialization can offer
> category A operations that are specific to quaternions, when someone
> works with unitless vector<4>.
> It would be just like template specialization will provide cross product
> for vector<3>, which is specific only for vector<3>.
> Besides quaternions are also known to be used together with
I don't think this is the correct thing to do. There are uses of
vector<4> where quaternion operations don't make sense, but classic
vector operations do.
In graphics programming vector<4>s are sometimes used as the color
component, with data encoded into each field to be used by a hardware
There are often times where the 'w' component is used to signal that
the vertex is at infinity, but should otherwise still be treated as a
For lights, the 'w' component is used to signal the type of light,
directional or point (omni-directional). That type specifies how the
x,y,z components should be interpreted. If the light is directional,
then the x,y,z is a direction vector. If the type is a point light,
the x,y,z components are a position in space.
I agree about the only allowing certain operations using template
specialization for the vector/quaternion classes, but I disagree that
quaternion can simply be vector<4> with the provided quaternion
specializations. I think it should be a separate class following the
I currently use enable_if and is_same from boost to determine what
functions should be exposed. There are convenience functions like:
as_array() to be used like glVertex3fv(my_vec.as_array());
that only make sense if the vector contained all of the same type.
Otherwise, in cases like vec3<float, short, float>, as_array() would
be disabled. I suspect that we could do the same for the rest of the
operations (dot_product, cross_product, etc).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk