On Tue, Jan 8, 2013 at 10:00 PM, Nathan Crookston <nathan.crookston@gmail.com> 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