Subject: Re: [boost] Interest in a new generic matrix library with specific 3D operations?
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2014-07-03 08:35:17
Emil Dotchevski wrote:
> The QVM library is more generic.
>
> In my experience, while the interface of the operations of a vector/matrix
> library can be standardized, it is often impractical to standardize the
> vector and matrix types themselves, because different use cases demand
> different compromise between ease of use and performance. For example, 16
> or 32-byte alignment may result in maximum speed but that isn't always the
> best option.
>
> That's why the emphasis in the QVM library is on the generic nature of the
> operations: they are independent of any types and can kick-in for any
> user-defined or third-party matrix/vector types (and of course types that
> QVM itself emits).
>
> This allows developers to define platform-, project- or even
> module-specific types and the full set of QVM operations become available
> automatically. Later, if necessary, profiler-guided optimizations can
> target only a critical subset of the types and the operations; e.g. one can
> overload to optimize only operator*, and only for some aligned_mat44 type
> (overload resolution will always prefer such user-defined overloads over
> the QVM overloads.)
>
Yes, the QVM design is more generic. This is why I proposed to use the
concepts from this library in the implementation of the algorithms.
To be more precise, I thought about domain-specific algorithms. In this
case from computer graphics but tools for other domains like robotics or
physics could be implemented as well, e.g.:
- functions for handling view and perspective (implemented by Fabien as
SetOrtho(), SetFrustum(), SetLookAt(), etc.),
- some generic Rotation concept allowing to represent it (in 3D) as
axis-angle, matrix3x3 or quaternion, which could just be simply applied
to e.g. a Vector in a unified way,
- the conversions between various representations,
- similar thing with Orientation - rotation + translation (e.g.
matrix3x4 or quaternion and a vector),
- similar thing with Transformation - the above + scale (e.g. matrix4x4
or quaternion and some vectors),
- differential operators like gradient, divergence, etc. and probably a
VectorField concept,
- most certainly many more...
Of course we should debate if and where such domain-specific algorithms
could be put.
But this is also true for QVM I guess.
A little off-topic...
Would it be difficult to extend QVM to use e.g. Boost.SIMD in the future?
E.g. provide additional traits defining the alignment of the data and
use vectorization accordingly?
Regards,
Adam