Re: [Glsdk-devel] [GLm] api

[H. H. <hen...@gm...>]

On Tue, Aug 26, 2008 at 12:39 AM, <gl...@mo...> wrote:

> > 1) Should we provide -Mul and -Div for vectors?
> Depends if this math library is graphics-related ;)
> It also depends on whenever we're defining matmemathical operations or
> software functions in this library.


This mathlib is graphics related. What do you mean 'mathematical operations
or software operations'?


>
>
> Isn't glmMatRotateYPR3 obsolete since there are glmMatRotate[X|Y|Z]3
> functions defined?


No. glmMatRotateYPR is a convenience function, meaning that it is easier for
the user to set up a complicated rotation matrix in this way. Also, it is
also faster to calculate a yaw-pitch-roll rotation matrix in one go than
constructing each rotation in separate phase and then multiplying them
together. The current implementation thought, does it just this way, but
this function needs to be cleanup and fixed in time.


Will only Mat3 have Scale and ScaleUniform defined?
>

MatScale3 and -ScalingUniform3 functions constructs a 3x3 scaling matrix. It
might be useful for the API to have equivalent 4x4 matrix constructors too,
thought. The API is not yet set in stone. My current effort includes writing
test cases for the current API, and when this is done, I will continue on
adding more functionality.


>
> Vector's Scale function is actually equivalent to ScaleUniform function
> for matrix. Should vectors have both Scale and ScaleUniform functions
> defined instead? If yes, then Mul and Div become obsolete.
>

Yes and no. The vector scale function multiplies each vector member by
scalar. Matrix scale constructors create scaling matrices. They do different
things. VecScaleUniform is an entry-point which could be included for
convenience thought, true.

Mul and div for vectors are not part of the API for reasons stated in my
previous posts (they are not defined in vector calculus).



>
> Should we have:
> glmMatRotate3f(GLMmat3f *out, const GLMvec3f* axis, GLfloat angle);
> or rather:
> glmMatRotate3f(GLMmat3f *out, GLfloat angle, GLfloat x, GLfloat y, GLfloat
> z);
> ?
>
> Please note that these questions are not in our issue list unless Henri H.
> sees them as worth considering.
>

Of course, your points are very worth of considering :)

At the moment I have only MatRotate (out, axis, angle). I think we don't
want to bloat the API any more than we actually need. Which version of the
above functions we should actually have, is a valid question indeed.
Providing them both, IMO, is redundant. This is open for discussion.



>
>
> > 2) Should we use short naming convention or is the current convention
> fine?
>
> Full operation names are better (subjective opinion), with the exception
> of "Subtract" :)
>

Okay so I gather you support the current API convention.



>
>
>
> > 4) Should we have the dimension of the type in the end of the entry-point
> > (like in OpenGL) or in the middle?
>
> Both are equally fine and referring either to Vec<n> data type or function
> operating on <n> components, but dimension placed at end makes for a nice
> separator between operation name and data type postfix.
>

That is my opinion too and that is also the OpenGL convention of operations
and we would like to conform with that.


>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Glsdk-devel mailing list
> Gls...@li...
> https://lists.sourceforge.net/lists/listinfo/glsdk-devel
>



-- 
Henri 'henux' Häkkinen