|
Boost : |
From: Janek Kozicki (janek_listy_at_[hidden])
Date: 2006-03-22 15:52:02
Andy Little said: (by the date of Tue, 21 Mar 2006 02:00:43 -0000)
> > sorry that this post got so incredibly long ;)
>
> No problem. I will try to reply to the other parts of your post in more detail
> soon. Overall I can see a good deal of divergence between your aims and mine.
> (That is not necessarily a bad thing of course as we would presumably be aiming
> for the most widespread use). Your applications require very good raw speed
> performance, which I havent paid enough attention to, but I can see now why you
> will be obsessed with that from looking at YADE.
I've reconsidered my "raw-speed" attitude, because from experience I've
learnt that speed comes often uninvited along with good design. So think
about design first, speed comes later :)
My elaborate explanations about anonymous union simply demonstrate that
full opengl compatibility comes at huge price - it forces internal data
structure. A huge no-no in good OO design. Therefore degree of
compatibility with opengl should be a design decision/rationale of
this library.
Fast disply in yade is much less important than geometrical computations
themselves - related to physics of the system, not to the graphics.
> Overall I have been looking at
> ease of use. I am currently interested in integrating geometry /vectors with pqs
> library, but that would increase complexity of the implementation over just
> using float types as you may see in my current geometry offering and will also
> affect compile times, so may be a burden giving you no benefit.
I see a big potential here, if I want to use physical units, having them
built-in inside the geometry would be pretty useful.
> That
> difference of quaternions v matrices is interesting also. The generic nature of
> matrix transforms is at the expense of speed. It should be possible to combine
> both matrix and quaternions transforms somehow of course and I will have to read
> up on using quaternion.
In fact quaternion stores rotation data in more compact form than
matrix. If quaternion is 'messed up' a bit, then rotation angle is just
a bit different - hard to notice the difference. If matrix is 'messed
up' a bit - it losts symmetry and rotation is iffy. Moreover everytime a
vector3d is rotated by quaternion, a 3x3 matrix is built from quaternion
(using only operations + - *). And to be honest I haven't benchamrked if
quaterions are faster. Many people claim this, but I realized that I
shouldn't claim it until I'll make relevant benchmarks.
> It strikes me that perhaps more detailed discussion
> about the goals and rationale of such a library is needed too.
yes, certainly. At first we should decide what entities should appear,
how to name them, and how to sort them into namespaces, to begin with,
that's my library:
- vector2 +
- vector3 +
- vector4 +
- matrix2 +
- matrix3 +
- matrix4 +
- quaternion +
- se3 +
Other readers of this list are welcome to add more components and "vote"
by placing '+' next to it. Of course class names are subject to another
discussion :)
If you are wondering, se3 is a position/orientation combo - small class
which contains only vector3 and a quaternion. It is used to fully
describe a placement of an object in 3d space. I'm still not sure whether
getting rid of it would make things simpler or not.
> As to quanternion...is boost::quanternion not suitable for your applications as
> it stands?
unfortunately not. yesterday I have examined it again, and I see that
the author has started working in that direction (quote at bottom of
quaternion docs webpage: "Use uBlas for the link with rotations (and
move from the example implementation to an efficient one).").
In his example I can see those familiar formulas used to build rotation
matrix out of quaternion (in file HSO3.hpp)
Perhaps he got discouraged by the fact that ublas is not a good choice
for small vectors.
-- Janek Kozicki |
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk