Re: [Glsdk-devel] Commentary on the math library

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

On Thu, Aug 28, 2008 at 12:32 PM, Jason McKesson <ko...@gm...> wrote:

> - We should have a series of Vec4 functions that treat their inputs as
> normalized quaternions. Basically quaternion multiplication, quaternion
> inverse, and a function to convert quaternions into rotation matrices.
> Enough to use quaternions. Oh, and a function to convert angle/axis into a
> quaternion (and one to go back?). I don't think we need a full-fledged
> quaternion type, as a 4-vector of floats is a 4-vector of floats; it's all
> in how you use it.
>

I think we should implement full featured GLMquatf type.


> - Rename the parameters in the lerp functions. I have always had a problem
> with lerp functions in terms of figuring out which parameter I would get
> with an alpha of 0 and which I would get with an alpha of 1. So the idea is
> to have the lerp parameter names themselves specify which way it works. IE:
> "glmVecLerp3f (GLMvec3f *out, const GLMvec3f **v0*, const GLMvec3f **v1*,
> GLfloat s);" It is much more apparent than if s==0.0f, you'll get v0, since
> it has a 0 in the name. Same goes with v1.
>

Fine, this is a valid point. I will be renaming all argument names into v0,
v1 and m0, m1 for consistency at some point.



> - The names of many of the matrix functions do not intuitively describe
> their results. Take the function "GLMmat3f *glmMatRotateX3f (GLMmat3f *out,
> GLfloat angle);" This can do one of two things. It can overwrite the
> contents of "out" with a rotation matrix about the X axis, or it can *
> multiply* the contents of out by that matrix. The latter would be the
> typical OpenGL style, but the former is what most math libraries would do.
> However, what about "GLMmat3f *glmMatTranslate3f (GLMmat3f *out, GLfloat x,
> GLfloat y);"? This is a function where it would make some sense for it to
> not overwrite the full contents of "out" (though an argument can be made
> that it should). Or at least, one would expect there to be a version of
> Translate3f that will only change the 2 positional coordinates of a
> transformation matrix.
>
> Honestly, I'm not sure what to do about it, or if we should do anything at
> all. If all of the functions have one specific kind of behavior (overwrite,
> say), then at least the library is consistent. It just feels weird to me to
> have a function like "glmMatTranslate3f" that completely overwrites the
> matrix rather than just setting certain fields.
>

This matter needs to be considered. We should also write the API references.


> - All of those Mat3 functions for generating transformation matrices? We
> should have Mat4 versions as well. Since Mat3's cannot easily be converted
> into Mat4's, and Mat4's are full 3D transformation matrices, it makes sense
> to provide full coverage in generating transformation matrices at the Mat4
> level.
>

I think we should provide an entry-point for creating 4x4 matrices from 3x3
matrix and a 3D vector as the last vertical column:

glmMatCompose (&out, &rotation, &translation);

or something similar.


> - BTW, is the math library going to provide a matrix stack, or is that
> something for a higher-level library?
>

No idea at this point yet.


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