Thread: Re: [Glsdk-devel] Glsdk-devel Digest, Vol 1, Issue 47

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

I think there is some small problem with this list , sometimes i receive 
only garbage
or requests to join the list i have already joined.
By the way i see that someone is starting to write a model generator lib, i 
am willing to give mine to inspect / absorb / modify / whatever

----- Original Message ----- 
From: <gls...@li...>
To: <gls...@li...>
Sent: Thursday, August 28, 2008 10:11 PM
Subject: Glsdk-devel Digest, Vol 1, Issue 47

> Send Glsdk-devel mailing list submissions to
> gls...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/glsdk-devel
> or, via email, send a message with subject or body 'help' to
> gls...@li...
>
> You can reach the person managing the list at
> gls...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Glsdk-devel digest..."
>
>
> Today's Topics:
>
>   1. Re: [GLM] development roadmap (Jason McKesson)
>   2. Re: are you reading my posts ? ( Henri H?kkinen )
>   3. Re: Commentary on the math library (Branan Riley)
>   4. Re: [GLM] development roadmap ( Henri H?kkinen )
>   5. Re: Commentary on the math library (Andrew Gajda)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 28 Aug 2008 13:01:59 -0700
> From: "Jason McKesson" <ko...@gm...>
> Subject: Re: [Glsdk-devel] [GLM] development roadmap
> To: gls...@li...
> Message-ID:
> <11a...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Thu, Aug 28, 2008 at 12:54 PM, Branan Riley <br...@gm...> wrote:
>> Actually, GL3 does need a math library - it lacks fixed-function
>> matrices, so we need to provide that.
>>
>> Branan
>
> Those functions are deprecated, but still perfectly functional.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 28 Aug 2008 23:02:54 +0300
> From: " Henri H?kkinen " <hen...@gm...>
> Subject: Re: [Glsdk-devel] are you reading my posts ?
> To: gls...@li...
> Message-ID:
> <fb6...@ma...>
> Content-Type: text/plain; charset="utf-8"
>
> Yes we are reading your posts and we have commented upon them.
>
> On Thu, Aug 28, 2008 at 10:45 PM, v71 <mj...@ti...> wrote:
>
>>
>>
>> -------------------------------------------------------------------------
>> 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 3
> Date: Thu, 28 Aug 2008 13:04:22 -0700
> From: "Branan Riley" <br...@gm...>
> Subject: Re: [Glsdk-devel] Commentary on the math library
> To: gls...@li...
> Message-ID:
> <cad...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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
>>
>>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 28 Aug 2008 23:08:24 +0300
> From: " Henri H?kkinen " <hen...@gm...>
> Subject: Re: [Glsdk-devel] [GLM] development roadmap
> To: gls...@li...
> Message-ID:
> <fb6...@ma...>
> Content-Type: text/plain; charset="utf-8"
>
> Yes indeed those functions are available but we have set a design goal not
> to use the deprecated API. But indeed, once we have a working basic 
> mathlib
> we should concentrate on other things until a mathlib update is needed.
> Unfortunately, I don't have a GL3 class graphics hardware available, so I
> myself am not able to write GL3 tutorials. I could help other people who 
> are
> interested in writing the tutorials, and I could perhaps write the
> programming guide and be a general editor for the SDK, or help Branan with
> the shapelib. I am sure there are things to do.
>
> On Thu, Aug 28, 2008 at 11:01 PM, Jason McKesson <ko...@gm...> 
> wrote:
>
>> On Thu, Aug 28, 2008 at 12:54 PM, Branan Riley <br...@gm...> wrote:
>> > Actually, GL3 does need a math library - it lacks fixed-function
>> > matrices, so we need to provide that.
>> >
>> > Branan
>>
>> Those functions are deprecated, but still perfectly functional.
>>
>> -------------------------------------------------------------------------
>> 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
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 5
> Date: Thu, 28 Aug 2008 16:11:10 -0400
> From: "Andrew Gajda" <and...@gm...>
> Subject: Re: [Glsdk-devel] Commentary on the math library
> To: gls...@li...
> Message-ID:
> <ac0...@ma...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Gotcha.  Thanks.
>
> On Thu, Aug 28, 2008 at 4:04 PM, Branan Riley <br...@gm...> wrote:
>
>> 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
>> >
>> >
>>
>> -------------------------------------------------------------------------
>> 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
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> -------------------------------------------------------------------------
> 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
>
>
> End of Glsdk-devel Digest, Vol 1, Issue 47
> ****************************************** 

Thread: Re: [Glsdk-devel] Glsdk-devel Digest, Vol 1, Issue 47

Utility libraries for working with OpenGL.

glsdk-devel