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

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

On Thu, Aug 28, 2008 at 10:35 PM, Andrew Gajda <and...@gm...>wrote:

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

Consider for example what happens when the user calls like this:

glmMatMul2f (&mat, &mat, &mat);

Writing the result into a temporary value and then finally overwriting the
*out avoids the complications that would arise. And we decided to allow
(&mat, &mat, &mat) rather than marking it as "undefined behaviour".


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