Re: [boost] (Boost) QVM update

Subject: Re: [boost] (Boost) QVM update
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2013-01-09 18:50:26

On Tue, Jan 8, 2013 at 10:00 PM, Nathan Crookston
<nathan.crookston_at_[hidden]> wrote:

> * I'm sure [qvms]_traits is used all over the place, but I'd still rather
> see scalar_traits, vector_traits, etc., especially as those may be
> specialized by the user.

They used to be called vector_traits, etc, but I think that the
shorter names are more practical, given that even user-defined
specializations appear in namespace qvm. I'll make sure s_traits gets
the proper exposure in the documentation though.

> * It looks like matrix types (probably vectors and quaternions too) must be
> default constructible (for both make and the template conversion operator
> of mat), though I didn't see that particular requirement noted -- am I
> mistaken?

Yes, some functions do require that types are default-constructable,
though make<> could be specialized. I should mention this in the
documentation.

> * inverse:  I was surprised to see that you're inverting using the matrix
> of cofactors.  For my personal education, why do you use that method -- is
> it more stable or efficient than others?

This just is the way I've been inverting matrices and it has worked
for my needs. :) That said, I'm not against adding support for
alternative implementations, even if they put additional requirements
on the input matrix.

Do note however, that I've implemented inversion and all other
algorithms in meta-code that is able to output specific code for any
size matrices. See (boost)/libs/qvm/gen/gen.cpp (which was used to
generate the files in (boost)/qvm/gen.)

> * I haven't looked, but I assume QVM is targeting cases where both matrices
> fit into cache?  Meaning, it doesn't worry about things like cache blocking?

I've been careful to avoid language-level inefficiencies (like
temporary objects, etc.), but I haven't been too concerned with low
level optimizations. I'm not against optimizing further (again, the
code generator may be useful for that.)

> * Further on swizzling -- when I'm dealing with OpenGL texture coordinates,
> the canonical names for them are s, t, r and q.  Is there an interface
> whereby I could allow writing something like this?

There is also RGBA for color vectors. Maybe it makes sense to add more
swizzlers, that isn't very difficult because (you guessed it) there is
a code generator for that too.

> I haven't had a chance to try QVM out -- I'd like to work up examples with
> e.g., std::array<float,4>, then something with boost::units types as the
> scalar types.  In fact, working with the latter would be a killer feature
> from this library for me.  I'll let you know what I find.

Yes, that would be interesting. So far I've hooked up DirectX and
OpenGL matrices and vectors, and types from 3rd-party code I've used,
so I know that v_traits/m_traits/q_traits work well. I haven't had a
need to hook up a custom scalar type yet. Practically speaking, we
don't know if s_traits is designed correctly until I or someone else
does that.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode