Menu
▾
▴
glsdk-devel — Main development list for the OpenGL SDK
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(248) |
Sep
(51) |
Oct
(9) |
Nov
(3) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: H. H. <hen...@gm...> - 2008-08-29 08:51:19
|
Someone has posted us a suggestion in the OpenGL forums for the first tutorial: http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=245033&Main=47674#Post245033 I think we should begin to put more effort on making actual tutorials, reference manuals, programming guides etc. than what we are now having. The first tutorial (drawing a simple triangle) should be quite trivial without the need of mathlib (although which is already quite complete) or shapelib. The lack of GLFW GL3 support does put us on akward situation, but what I haved talked with the GLFW guys, they are putting a full effort to it. Is there anyone who would be interested on writing stuff for this? Because without the tutorials and other documentation, we will not be able to put this SDK through. Rob, you have been quiet for long time. Are you still with us? Anyone else? On Tue, Aug 26, 2008 at 9:25 PM, Jason McKesson <ko...@gm...> wrote: > Actually, that reminds me (I generated that list basically off the > cuff). Rather than a "my first cube", we should do a whole tutorial on > the different kinds of primitives: triangle strips, lists, fans, etc. > > Also, we should have a tutorial on map buffer (specifically map buffer > range, once conformant drivers are more prevelant), for dealing with > dynamic geometry. This would probably be after Transform&Camera, but > before normals and per-vertex lighting. > > On Tue, Aug 26, 2008 at 11:11 AM, Andrew Gajda <and...@gm...> > wrote: > > I would insert either after #1 or after #2: > > My first cube: Hello 3D world! > > > > It's the perfect lead-in to camera/perspective/normals but (slightly) > more > > complicated than a single triangle. Might be good to note when the > GLShape > > library starts to be used. Right after getting a triangle displayed? > Once > > texture mapping is involved? Maybe the cube tutorial explains what's > > involved in a cube (beyond the triangle tutorial) then shows the beginner > > how to do the same thing using the GLShape library. > > > > pudman > > > > On Tue, Aug 26, 2008 at 1:59 PM, Jason McKesson <ko...@gm...> > wrote: > >> > >> To me, the most important thing about tutorials is this: they're tools > >> for teaching. Which means that they need to be laid out in a specific > >> order (increasing complexity) and with specific intents in mind. Which > >> means that for the initial tutorials, we should sit down and decide > >> what the initial tutorials ought to be. We don't necessarily have to > >> write them ourselves, but we should define what their topics are. > >> > >> I was thinking something on the order of this: > >> > >> 1: My first triangle: Hello-world for graphics. > >> 2: Transformation and Camera > >> 3: Normals and Per-vertex lighting > >> 4: Per-fragment lighting > >> 5: Texture mapping > >> 6: Framebuffer blending > >> 7: Point-sprites > >> 8: Render-to-texture > >> 9: Depth, order, and blending: Introducing the depth buffer and > >> dealing with alpha blending with lots of objects. > >> > >> The idea being that each tutorial builds on the other, introducing new > >> complexity to the previous one. > > ------------------------------------------------------------------------- > 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 |
|
From: Jason M. <ko...@gm...> - 2008-08-29 00:14:39
|
Thanks. I haven't been monitoring posts in the advanced forum, and I missed it. On Thu, Aug 28, 2008 at 2:46 PM, Orhun Birsoy <orh...@gm...> wrote: > In case you missed it, > http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=244945#Post244945 > > > -- > Orhun Birsoy > > ------------------------------------------------------------------------- > 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 > |
|
From: Branan R. <br...@gm...> - 2008-08-28 23:09:25
|
Yes, but you sent the message to the list, which means he won't get it until the next digest On Thu, Aug 28, 2008 at 4:06 PM, Henri Häkkinen <hen...@gm...> wrote: > My reply was meant for v71 who seemed to have some sort of troubles with the > mailing list. > > On Fri, Aug 29, 2008 at 2:04 AM, Mars_999 <ma...@si...> wrote: >> >> Is this for me? Or the entire list? I am already working with Branan... >> >> ----- Original Message ----- >> From: Henri Häkkinen >> To: gls...@li... >> Sent: Thursday, August 28, 2008 6:01 PM >> Subject: Re: [Glsdk-devel] Glsdk-devel Digest, Vol 1, Issue 47 >> You have enabled the digest mode which means that you will get a combined >> summary of each message sent at the end of each day. You may change it from >> the mailing list settings or request branan to help you. >> >> At the moment, Branan is writing a shapelib for generating geometry for >> basic primitives. These include such stuff as cubes, cylinders, cones, >> teapot etc. If you have any code to contribute for us, sent it over him or >> to me by email. Model loaders, such as Lightwave or .obj is not yet >> necesary. >> >> -- >> 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 > > |
|
From: H. H. <hen...@gm...> - 2008-08-28 23:06:31
|
My reply was meant for v71 who seemed to have some sort of troubles with the mailing list. On Fri, Aug 29, 2008 at 2:04 AM, Mars_999 <ma...@si...> wrote: > Is this for me? Or the entire list? I am already working with Branan... > > ----- Original Message ----- > *From:* Henri Häkkinen <hen...@gm...> > *To:* gls...@li... > *Sent:* Thursday, August 28, 2008 6:01 PM > *Subject:* Re: [Glsdk-devel] Glsdk-devel Digest, Vol 1, Issue 47 > > You have enabled the digest mode which means that you will get a combined > summary of each message sent at the end of each day. You may change it from > the mailing list settings or request branan to help you. > > At the moment, Branan is writing a shapelib for generating geometry for > basic primitives. These include such stuff as cubes, cylinders, cones, > teapot etc. If you have any code to contribute for us, sent it over him or > to me by email. Model loaders, such as Lightwave or .obj is not yet > necesary. > > -- > 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 |
|
From: Mars_999 <ma...@si...> - 2008-08-28 23:04:21
|
Is this for me? Or the entire list? I am already working with Branan... ----- Original Message ----- From: Henri Häkkinen To: gls...@li... Sent: Thursday, August 28, 2008 6:01 PM Subject: Re: [Glsdk-devel] Glsdk-devel Digest, Vol 1, Issue 47 You have enabled the digest mode which means that you will get a combined summary of each message sent at the end of each day. You may change it from the mailing list settings or request branan to help you. At the moment, Branan is writing a shapelib for generating geometry for basic primitives. These include such stuff as cubes, cylinders, cones, teapot etc. If you have any code to contribute for us, sent it over him or to me by email. Model loaders, such as Lightwave or .obj is not yet necesary. -- 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 |
|
From: H. H. <hen...@gm...> - 2008-08-28 23:01:11
|
You have enabled the digest mode which means that you will get a combined summary of each message sent at the end of each day. You may change it from the mailing list settings or request branan to help you. At the moment, Branan is writing a shapelib for generating geometry for basic primitives. These include such stuff as cubes, cylinders, cones, teapot etc. If you have any code to contribute for us, sent it over him or to me by email. Model loaders, such as Lightwave or .obj is not yet necesary. -- Henri 'henux' Häkkinen |
|
From: Branan R. <br...@gm...> - 2008-08-28 22:03:36
|
You seem to be set to recieve digests. You won't recieve individual replies immediately like that. I can look at your ML settings from the admin interface, if you'd like. Branan |
|
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 > ****************************************** |
|
From: Orhun B. <orh...@gm...> - 2008-08-28 21:46:00
|
In case you missed it, http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=244945#Post244945 -- Orhun Birsoy |
|
From: H. H. <hen...@gm...> - 2008-08-28 21:30:55
|
Yes. We are open source development community and rather than giving assignments we allow people work on the things they feel comfortable. The reason why we haven't actually written tutorials is that nobody has actually showed interest yet. Hopefully we will get activity once GLFW gets GL3 update. On Thu, Aug 28, 2008 at 11:16 PM, Andrew Gajda <and...@gm...>wrote: > My point was that a simple drawing a triangle demo/tutorial doesn't require > a math library. And that tutorial will be the most critical as it > introduces everything that follows: context setup, VBOs and shaders. Scale, > translations, rotations all occur after that. > > ------------------------------------------------------------------------- > 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 |
|
From: Branan R. <br...@gm...> - 2008-08-28 21:19:49
|
I'm still at work. I'll take a detailed look at it in about 2.5 hours,
if no one else has by then
Branan
On Thu, Aug 28, 2008 at 2:14 PM, Henri Häkkinen <hen...@gm...> wrote:
> I am unable to get glmMatLookAt4f function working. I am following the
> formula given in the gluLookAt manpage, but still no luck. Could somebody
> take a look at my code? The test case gives me a failure. Here is my local
> copy of the function (the repos version is outdated).
>
> GLMmat4f *
> glmMatLookAt4f (GLMmat4f *out,
> const GLMvec3f *eye,
> const GLMvec3f *center,
> const GLMvec3f *up)
> {
> GLMmat4f t;
> GLMvec3f f, s, u;
>
> assert (out);
> assert (eye);
> assert (center);
> assert (up);
>
> /* FIXME: not working */
> /* FIXME: unoptimal implementation */
>
> glmVecSub3f (&f, center, eye);
> glmVecNormalize3f (&f, &f);
> glmVecNormalize3f (&u, up);
> glmVecCross3f (&s, &f, &u);
> glmVecCross3f (&u, &s, &f);
>
> out->m00 = s.x;
> out->m01 = s.y;
> out->m02 = s.z;
> out->m03 = 0.0f;
> out->m10 = u.x;
> out->m11 = u.y;
> out->m12 = u.z;
> out->m13 = 0.0f;
> out->m20 = -f.x;
> out->m21 = -f.y;
> out->m22 = -f.z;
> out->m23 = 0.0f;
> out->m30 = 0.0f;
> out->m31 = 0.0f;
> out->m32 = 0.0f;
> out->m33 = 1.0f;
>
> glmMatIdentity4f (&t);
> t.m03 = -eye->x;
> t.m13 = -eye->y;
> t.m23 = -eye->z;
>
> glmMatMul4f (out, out, &t);
> return out;
> }
>
>
> --
> 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
>
>
|
|
From: H. H. <hen...@gm...> - 2008-08-28 21:14:15
|
I am unable to get glmMatLookAt4f function working. I am following the
formula given in the gluLookAt manpage, but still no luck. Could somebody
take a look at my code? The test case gives me a failure. Here is my local
copy of the function (the repos version is outdated).
GLMmat4f *
glmMatLookAt4f (GLMmat4f *out,
const GLMvec3f *eye,
const GLMvec3f *center,
const GLMvec3f *up)
{
GLMmat4f t;
GLMvec3f f, s, u;
assert (out);
assert (eye);
assert (center);
assert (up);
/* FIXME: not working */
/* FIXME: unoptimal implementation */
glmVecSub3f (&f, center, eye);
glmVecNormalize3f (&f, &f);
glmVecNormalize3f (&u, up);
glmVecCross3f (&s, &f, &u);
glmVecCross3f (&u, &s, &f);
out->m00 = s.x;
out->m01 = s.y;
out->m02 = s.z;
out->m03 = 0.0f;
out->m10 = u.x;
out->m11 = u.y;
out->m12 = u.z;
out->m13 = 0.0f;
out->m20 = -f.x;
out->m21 = -f.y;
out->m22 = -f.z;
out->m23 = 0.0f;
out->m30 = 0.0f;
out->m31 = 0.0f;
out->m32 = 0.0f;
out->m33 = 1.0f;
glmMatIdentity4f (&t);
t.m03 = -eye->x;
t.m13 = -eye->y;
t.m23 = -eye->z;
glmMatMul4f (out, out, &t);
return out;
}
--
Henri 'henux' Häkkinen |
|
From: Andrew G. <and...@gm...> - 2008-08-28 20:16:47
|
My point was that a simple drawing a triangle demo/tutorial doesn't require a math library. And that tutorial will be the most critical as it introduces everything that follows: context setup, VBOs and shaders. Scale, translations, rotations all occur after that. |
|
From: Andrew G. <and...@gm...> - 2008-08-28 20:11:04
|
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
>
|
|
From: H. H. <hen...@gm...> - 2008-08-28 20:08:13
|
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 |
|
From: Branan R. <br...@gm...> - 2008-08-28 20:04:13
|
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
>
>
|
|
From: H. H. <hen...@gm...> - 2008-08-28 20:02:43
|
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 |
|
From: Jason M. <ko...@gm...> - 2008-08-28 20:01:49
|
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. |
|
From: H. H. <hen...@gm...> - 2008-08-28 20:00:51
|
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 |
|
From: H. H. <hen...@gm...> - 2008-08-28 19:58:18
|
> The probleI wim there is that you have to create a mat3x3 just to create > the mat4x4 that you actually want. That seems wasteful and not > entirely obvious to the user. > > More importantly, what about the other 3 floats in "out" that are not > being set by this? > > I know it's a pain to add another version of all of those functions > (I've done it), but it really is the most obvious, simplest solution. > Yes. I think you are right. I will add the entry-points for creating 4x4 rotations etc.* at some point!* Right now, I really would like to start writing the API ref. > > ------------------------------------------------------------------------- > 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 |
|
From: Branan R. <br...@gm...> - 2008-08-28 19:54:19
|
Actually, GL3 does need a math library - it lacks fixed-function matrices, so we need to provide that. Branan On Thu, Aug 28, 2008 at 12:43 PM, Andrew Gajda <and...@gm...> wrote: > After v0.2 I'd suggest focusing on other parts of the until features of v0.5 > are required. > > We have yet to have any GL code checked in, much less actually discussed > aside from a quick tutorial list. Already there are people starting with > GL3.0 > (http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=244952#Post244952) > which has no requirement for a math library or a shape library. > > On Thu, Aug 28, 2008 at 1:05 PM, Henri Häkkinen <hen...@gm...> wrote: >> >> The mathlib is coming well and the initial API begins to close in for a >> conclusion. There are only some issues left in the current implementation >> which I want to address before I can say I am completely happy with it. The >> gmMatLookAt4f function seems not to create correct kind of results and >> glmMatInverse2f/3f needs some attention as the implementations lacks trivial >> optimizations. After these issues are resolved and API documentation >> written, I think we should release a sort of alpha so that people could >> experiment with it. >> >> My roadmap for the GLM development is the following: >> >> v0.1: The initial API fully implemented, tested and documented in API >> reference manual. >> v0.2: Updated API from the feedback of the community. >> v0.5: Additional functionality included; colors, quaternions, planes, >> matrix stacks (?) .... >> ... >> v1.0: The API fully implemented, tweaked, updated and tested along with >> written programming guide, API reference and samples. >> >> v2.0: SIMD optimization? >> >> I would also like to begin to write the API reference. We should think >> about it's layout. I think it's best to adopt GL-like documentation style in >> which functions can be documented together, something like: >> >> type glmVecLength{234f} (GLMvec *v) >> >> >> >> I hope that somebody with DocBook capabilities could either write me some >> boilerplate or instruct me how to write with it. >> >> -- >> 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 > > |
|
From: Andrew G. <and...@gm...> - 2008-08-28 19:43:52
|
After v0.2 I'd suggest focusing on other parts of the until features of v0.5 are required. We have yet to have any GL code checked in, much less actually discussed aside from a quick tutorial list. Already there are people starting with GL3.0 ( http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=244952#Post244952) which has no requirement for a math library or a shape library. On Thu, Aug 28, 2008 at 1:05 PM, Henri Häkkinen <hen...@gm...> wrote: > The mathlib is coming well and the initial API begins to close in for a > conclusion. There are only some issues left in the current implementation > which I want to address before I can say I am completely happy with it. The > gmMatLookAt4f function seems not to create correct kind of results and > glmMatInverse2f/3f needs some attention as the implementations lacks trivial > optimizations. After these issues are resolved and API documentation > written, I think we should release a sort of alpha so that people could > experiment with it. > > My roadmap for the GLM development is the following: > > v0.1: The initial API fully implemented, tested and documented in API > reference manual. > v0.2: Updated API from the feedback of the community. > v0.5: Additional functionality included; colors, quaternions, planes, > matrix stacks (?) .... > ... > v1.0: The API fully implemented, tweaked, updated and tested along with > written programming guide, API reference and samples. > > v2.0: SIMD optimization? > > I would also like to begin to write the API reference. We should think > about it's layout. I think it's best to adopt GL-like documentation style in > which functions can be documented together, something like: > > type glmVecLength{234f} (GLMvec *v) > > > > I hope that somebody with DocBook capabilities could either write me some > boilerplate or instruct me how to write with it. > > -- > 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 > > |
|
From: Jason M. <ko...@gm...> - 2008-08-28 19:42:46
|
On Thu, Aug 28, 2008 at 12: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?
Because "out" may be equal to "blah":
someFunc(GLMvec3f *out, GLMvec3f *in1, GLMvec3f *in2);
GLMvec3f first, second;
someFunc(&first, &first, &second);
|
|
From: Jason M. <ko...@gm...> - 2008-08-28 19:41:02
|
On Thu, Aug 28, 2008 at 9:52 AM, 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. You can if you want, but we'll have to support every operation that Vec4's support on them. So if we have a "UniformVec4f" function for setting uniforms, we would need a separate "UniformQuatf" function for setting quaternions. It seems wasteful, especially if we're going to use Vec4f's for things like colors. > >> >> - 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. The problem there is that you have to create a mat3x3 just to create the mat4x4 that you actually want. That seems wasteful and not entirely obvious to the user. More importantly, what about the other 3 floats in "out" that are not being set by this? I know it's a pain to add another version of all of those functions (I've done it), but it really is the most obvious, simplest solution. |
|
From: Andrew G. <and...@gm...> - 2008-08-28 19:35:41
|
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
>
>
|
1 message has been excluded from this view by a project administrator.
