Re: [Glsdk-devel] [GLm] api

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

> > 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. RotateYPR is a convenience function, meaning that it is easier for the
user to set up a complicated rotation matrix in this way. It is also faster
to calculate a yaw-pitch-roll rotation matrix in one go than constructing
each rotation independently and then multiplying them together. The current
implementation thought does it just this way, but the function needs a
cleanup.

Will only Mat3 have Scale and ScaleUniform defined?

3D scaling matrices are natively 3x3 matrices. There could be a 4x4 version
of it and there definelty should be 2x2 version of it (this will be added).


> Vector's Scale function is actually equivalent to ScaleUniform function
> for matrix.

MatScale* creates 3x3 scaling matrices while VecScale multiplies each vector
member by a scalar. They are two different things.


> Should vectors have both Scale and ScaleUniform functions
> defined instead? If yes, then Mul and Div become obsolete.

Vectors could have ScaleUniform also for a convenience, but currently they
don't have. Vector mul and div are not part of the current API for reasons
stated in my previous posts.


> 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.

Your points are very well worth considering. Currently the API has only
Rotate(out, axis, angle). I think it is bad idea to bloat the API needlesly
and we should choose only one of the two. The real question is which is
better. The matter 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, I gather you support the current API effort.


> > 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 how I feel also. This is also the OpenGL convention of operations
which we would like to conform to.

My current GLM efforts revolve around stabilizing and writing test cases for
the current API. This will take time, as matrix test cases are complicated
to write. Once this is done, I will continue on adding new entry-points
(such as the above suggested 2x2 scaling matrix constructor).

-- 
Henri 'henux' Häkkinen