Re: [boost] QVM Review

Subject: Re: [boost] QVM Review
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2015-12-16 16:21:31

Phil, thank you for your review.

On Wed, Dec 16, 2015 at 12:26 PM, Phil Endecott <
spam_from_boost_dev_at_[hidden]> 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