Phil, thank you for your review. On Wed, Dec 16, 2015 at 12:26 PM, Phil Endecott < spam_from_boost_dev@chezphil.org> wrote:
Actually since first looking I've found that it does have more functionality than I thought - for example, I've only just found that it has functions to create matrices representing rotations (but not any other affine transformations)
Not true, it can do translation and scaling as well. There is no shear support right now but that's easy to add if needed. The expression trans_m(v) reinterprets v as a translation matrix. Scaling is done by diag_m(v), which reinterprets v as a matrix whose diagonal is the elements of v with all other elements zero.
and to compute the inverse of a matrix (but not the determinant).
Not true, there is the determinant() function, and there are actually two overloads of inverse, one that itself computes the determinant, and another that takes the determinant as an argument, in case it was computed already. Generally, the library's functionality covers 3D graphics pretty well. I am open to reasonable additions, as discussed earlier.
But there's still not enough meat here for me to think it's worth using. If this were a comprehensive matrix algebra library, or a computational geometry library, or a SIMD library, then it might be worth putting up with the syntax. But it isn't, it's just a medium-size collection of operators and functions for quaternions, vectors and matrices that many projects will already having amongst their own local utilities.
What you're saying is that people who need quaternions, vectors and matrices already have quaternions vectors and matrices. That is true, in fact there are very many such types, and the point of QVM isn't to add to the mix but to define an environment where all of the existing types can be used safely together.
What it does offer is the ability to wrap existing matrix and vector classes and use a single unified syntax for all of them. It's just a shame that the single unified syntax is not the one I want to use!
It is interesting to contrast QVM with Boost.Polygon and Boost. Geometry. The similarity is that both of these also wrap existing classes (for e.g. points) by traits class specialisations. When these were reviewed we discussed extensively how support for this compromised the friendliness of the syntax, i.e. the need to write get<0>(p) rather than p.x. What we ended up with there was I think the best that we could do, and it was probably worthwhile because of the substantial core functionality of each of those libraries. In my opinion, QVM doesn't reach that threshold.
The swizzling syntax must be terse or else it's useless. If you've written shader code you'll know utterly inadequate it is to require a syntax like swizzle<1,0,3,2>(vec) instead of (vec,YXWZ). At any rate, swizzling is defined in a separate header, don't include it if you don't want it. I've agreed that other function names can be made longer. Thanks, Emil