Menu
▾
▴
Re: [Glsdk-devel] Glsdk-devel Digest, Vol 1, Issue 47
|
From: v71 <mj...@ti...> - 2008-08-28 21:53:30
|
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 > ****************************************** |
