From: Max Motovilov (max_at_[hidden])
Date: 2008-03-25 14:30:58
This is a topic I find extremely interesting since by the will of fate I
keep coming back to it in the course of my everyday work. In fact, I
have implemented (fully or in part) a similar set of library facilities
3 times in a row... and I can't very well opensource any of the three
implementations :( Nothing prevents me from collaborating on an existing
open source project though :)
I have only glanced briefly through the documentation so my comments may
be based on an incomplete picture; I apologize in advance if that's the
case. Nevertheless I am going to respond right away just so you know
you're not alone ;). I'll also try to spend more time reviewing your
library later today.
- I very much like the traits-based approach to determining the type of
calculation results. However a good extensible facility for deriving the
result type from argument types appears to be generally useful and not
at all specific to geometry. Unless there is one already in Boost (I am
not aware of it and quick check of the docs didn't help), perhaps it may
be introduced as a separate library?
- While generalized point types (2D vs. 3D and XY vs. lat/lon) are OK,
it is often extremely useful in graphics code to make your objects fit
the underlying representation of an externally defined structure (such
as POINT type in Win32) -- for example by publicly or privately
inheriting from it. This lets you use e.g. vectors of points as
arguments for system APIs. Can be done by adding an extra template
argument (with a default) to point<> and moving most of the
implementation details into a traits class.
- There is a box type but not a (1D) range type (I don't think you allow
1D points, or do you?). It is often convenient to define operations on
bounding rectangles in terms of ranges. The comment about making point
types compatible with externally defined structure applies to boxes too.
- I didn't find any facilites for linear transformations in your list.
Am I not looking in the right place or they aren't there? If the latter,
it is probably the biggest omission. Or do you think this need is best
served with uBLAS? I have no idea if this can be done using uBLAS in
both efficient and convenient way so would like to hear everyone's
thoughts. I am very much used to writing things like:
pt = shift( dst_offs ) * rotate( angle ) * shift( -src_offs ) * pt;
or when it is a repeated operation:
transform2D xf = shift(dst_offs) * rotate(angle) * shift(-src_offs);
.......
pt = xf * pt;
or maybe even
for_each( pts.begin(), pts.end(), _1 = xf * _1 ); // using lambda
- In 2D geometry, very many computations can be most efficiently
expressed in terms of dot product and cross product, so it wouldn't hurt
to have these operations implemented as part of the library. It probably
makes sense (I haven't done that before) to have a type for offset
vectors in geometrical sense separate from points: vec = pt - pt; pt =
pt + vec; et. al. The difference is that the offset part of a linear
transformation should apply to point but not to vector. Again, is this
something best done with uBLAS?
Ok, really need to go back to work. I'll probably have more to say on
this later.
...Max...