[boost] Re: TR2 and C++0x heads up

From: Hubert Holin (Hubert.Holin_at_[hidden])
Date: 2005-06-02 05:32:13

Somewhere in the E.U., le 02/06/2005

   Bonjour

      I am combining here answers two two posts, which, in unison, I 
think validate my point.

      The possible objection to the usefulness of quaternions, for a 
significant portion of potential users at least, is the absence of a 
direct link to their favorite - and mutually incompatible - 
domain-specific API, leading to inefficiencies.

      This, to me, only betrays the fact that it is these other 
domain-specific API that need to be optimized for the domain's need 
(speed or whatever), and perhaps, ultimately, standardized, not a 
general tool such as quaternions and octonions.

      Quaternions, while inherently useful to, say, games, are not 
limited to that domain and, beyond the difficulty of trying to 
standardize APIs for non-standardized and competing libraries, I believe 
it would be wrong to not standardize them or specialize early for one 
problem domain. It would be akin to not standardizing the complex 
numbers in C++ because no direct link is provided to plane rotations, or 
including a link to a specific non-standardized API in the standard for 
C++ complex numbers.

      I might add that extant libraries only code well-know solutions to 
problems. I started this work in part because a particular problem had 
to be solved (interpolation of orientation under constraint, which has 
real economic meaning for the companies involved). The problem has been 
solved but has not been officially published (nor sold, for various 
reasons), so does nor appear (AFAIK, it's been quite a few years since I 
did that) in libraries today. Using a quaternion library independent 
from any existing 3D library enables me to solve the problem for all of 
them. Specializing for one would leave out the others. This is just an 
example, there are other real problems waiting to be solved, and the 
right level of abstraction to solve them is not the existing 3D 
libraries (properly speaking the "proper level of abstraction" is the 
mathematical realm, but what we propose are "incarnation" of the objects 
we use). While we are dealing with examples, a related problem, dealing 
with speed, is *quickly* finding *many* very close rotations, say in the 
plane, with a lessened emphasis on precision. A naïve way of doing this 
with incrementing the angle and using transcendental functions usually 
is not the best way to proceed. Again, thinking within the box of a 
given 3D API is not the most useful way, unless this API provides us 
with good incarnations of mathematical objects. One could at least hope 
that (in the best of worlds...) the standardization process would 
produce something sensible in that regard.

      It is an open secret that the lack of a de jure standard C++ way 
of representing elementary low-dimensional objects such as rotations is 
hurting us all (from GUI designers to physicists). Proposals for such 
surface here from time to time, but none has gone so far as to be 
submitted for review, IIRC, which IMHO is a shame.

      What I believe would be good would be to standardize the 
quaternions and octonions on their own, provide non-normative (but 
efficient) links with specific APIs (in a way similar to the example 
link I provide with the library), or at least with a few of them to 
avoid the kind of situation we are in w.r.t. Unicode, and when the other 
domains have their API standardized as well, finally provide standard 
links (faster than w.r.t. Unicode ;-)   ).

      It would at least help to prevent each domain-specific library to 
reinvent the wheel (there are quaternions in many extant libraries, 
tailored to the local needs...), when what they really need is the 
vehicle using these wheels, and perhaps help communication between them, 
paving, perhaps, the way for their own standardization. Let's do things 
one step at a time (while not being oblivious to the bigger picture).

In article <d7flif$mvb$1_at_[hidden]>,
 "Thorsten Ottosen" <nesotto_at_[hidden]> wrote:

> "Hubert Holin" <Hubert.Holin_at_[hidden]> wrote in message 
> news:Hubert.Holin-94C135.13380630052005_at_sea.gmane.org...
> | Somewhere in the E.U., le 30/05/2005
> |
> |   Bonjour
> |
> | In article <d5bk7j$jg7$1_at_[hidden]>,
> | "Thorsten Ottosen" <nesotto_at_[hidden]> wrote:
> |
> | > "Beman Dawes" <bdawes_at_[hidden]> wrote in message
> | > news:d5bav1$fha$1_at_sea.gmane.org...
> | > |
> | > | "Hubert Holin" <Hubert.Holin_at_[hidden]> wrote in message
> | > | news:Hubert.Holin-6DA78B.18275104052005_at_sea.gmane.org...
> | > | > Paris (U.E.), le 04/05/2005
> | >
> | > | >
> | > | >      Dare I say that this time around I would try to not drop the 
> | > | >      ball
> | > | > (again) and propose the quaternions and octonions as possible "Small
> | > | > Additions"?
> | >
> | > My understanding of the quaternions lib is that it is not useful for
> | > doing rotations and that stuff needed in the 3D graphics world.
> |
> |      Could you please elaborate? I did include one possible way of
> | linking with rotations in the library. This work did stem (in part) from
> | some work with rotations specifically for some 3D graphics problem
> | (though this part, interpolation of orientation under constraints, is
> | *not* included in the library).
> |
> | > If you intend to submit it, I would like to see motifications that made 
> this
> | > possible.
> | >
> | > -Thorsten
> |
> |      I am open to any suggestion. I must say this post is something of
> | a surprise to me. Perhaps are you referring to the lack of any
> | "reasonably standard" C++ implementation of rotations in R^3?
> 
> no, I think I'm referring to  comment from Gary Powel about this issue (he 
> works in the Games industry, I think)
> 
> anyway, I don't have seriuos time to investigate this issue, but maybe you 
> could look at
> scene graph packages like OSG to see if you can do the same:
> 
> http://www.openscenegraph.org/documentation/OpenSceneGraphReferenceDocs/classo
> sg_1_1Quat.html
> 
> 
> best regards
> 
> Thorsten 

In article <429C4777.2090302_at_[hidden]>,
 Martin Slater <mslater_at_[hidden]> wrote:

> > 
> >       I am open to any suggestion. I must say this post is something of 
> > a surprise to me. Perhaps are you referring to the lack of any 
> > "reasonably standard" C++ implementation of rotations in R^3?
> > 
> 
> This is somewhat limiting from a games programmers perspective. 
> Quaternions on there own are definitely useful but the two common 3d 
> apis (Direct3D and openGL) required conversion to 4x4 matrices before 
> presentation to the API. So without a full range of 4 vectors, 3 
> vectors, and 3x3, 4x4 matrices at a minimum (and possibly 4x3 matrices 
> as an optimisation) there's little chance that it'll get used by many in 
> the industry. Obviously with 4x4 matrices and 4 vectors you can do 
> anything that you could do with their 3 space counterparts (and more) 
> but speed is always a primary concern with these things. Throw into that 
> mix different "handedness" conventions (openGL is right handed, direct3d 
> left handed) and its extremely hard to satisfy everyone. Octonions just 
> don't have any major use as I know in the games business as a whole;)
> 
> Anyway both these areas are well served by the D3DX library from 
> Microsoft and others such as Dave Eberly's Wild Magic library so I'm not 
> sure the games industry really needs this kinda thing standardised 
> without going the whole hog and supplying everything.
> 
> My 2c.
> 
> Martin

   Merci

Hubert