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

[Andrew G. <and...@gm...>]

Maybe it's been a while since I've done pure C (like with my function
overloading example) but can someone tell me what the advantage might to
doing:
*someGLMfunc( GLMvec3f *out, blah, blah )
{
   GLMvef3 tmp;
   ...
   tmp.x = something;
**   tmp.y = something;
**   tmp.z = something;

   *out = tmp;

   return out;
}*

Why not just assign *out directly?

On Thu, Aug 28, 2008 at 12:52 PM, Henri Häkkinen <hen...@gm...> wrote:

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