On Wed, Jul 1, 2015 at 10:47 PM, Andrew Hundt
On Fri, Jun 26, 2015 at 11:22 PM, Emil Dotchevski < emildotchevski@gmail.com> wrote:
On Fri, Jun 26, 2015 at 7:33 PM, Michael Marcin
wrote: On 6/26/2015 1:30 AM, Emil Dotchevski wrote: What I mean is Boost.Geometry already has adapters for point types among other things. You are providing adapters for matrix vector and quaternion types.
http://www.boost.org/doc/libs/1_58_0/libs/geometry/doc/html/geometry/example...
It seems to me Geometry is about shapes and shape operations and iteration. QVM has nothing to do with shapes or iteration, but it defines a complete set of generic namespace-scope quaternion/matrix/vector operations, which Geometry doesn't. I also think that it shouldn't: if you want to use such operations with Geometry types just use the QVM adaptation machinery
I've always dreamt of boost.geometry supporting 3d, and qvm might be a way to accomplish that. However, it might make the most sense for boost.geometry 3d components to utilize qvm under the hood to implement 3d geometric functionality rather than make qvm part of boost.geometry. Perhaps others can imagine better ways to accomplish these goals.
I've done my best to keep QVM as lightweight as possible, including by separating different operations in different headers -- for example, if you need to work with 3D vectors and nothing else, you can usually just #include "boost/qvm/v3.hpp" to basically get a few hundred lines of simple operator definitions. Also, consider that QVM can work with other libraries' native types, which results in relatively little coupling. So yes, I imagine that it may make sense to use QVM in the implementation of libraries like Geometry, though I'm not familiar with it so I might be wrong. -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode