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