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

[Branan R. <br...@gm...>]

In creation functions that's safe.

In any functions that take a *in matrix, you have possible
memory-aliasing isues with pointers

Branan

On Thu, Aug 28, 2008 at 1:01 PM, Henri Häkkinen <hen...@gm...> wrote:
>
> 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
>
>
> -------------------------------------------------------------------------
> 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
>
>