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-28 18:52:15
|
Okay, our bug tracker is now active. People wishing to contribute can take a look at it: http://sourceforge.net/tracker/?atid=1103788&group_id=237607&func=browse On Thu, Aug 28, 2008 at 9:30 PM, Branan Riley <br...@gm...> wrote: > Probably the bug tracker. > > Branan > > On Thu, Aug 28, 2008 at 11:26 AM, Henri Häkkinen <hen...@gm...> > wrote: > > I have not used the Sourceforge tracker services much, so could you > advice > > me on this. > > > > There are four functions which needs fixing: > > > > glmMatInverse2f > > glmMatInverse3f > > glmMatRotateYPR3f > > glmMatLookAt4f > > > > I would like to set a tracker for them so anyone willing to contribute > could > > take a look at them and I could myself move into other matters. Which > > tracker should I use? Bug tracker, patch tracker? > > > > -- > > 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 18:32:52
|
Yes. I think we should create a LICENSE file in the root directory and perhaps list copyrights for each library in the README along with contributors? Or should we choose a separate file for the copyrights and contributes from the README? I can do this minor task. I will also setup some SF.net tracker issues for the GLM (see my other post). On Thu, Aug 28, 2008 at 7:55 PM, Branan Riley <br...@gm...> wrote: > Since the zlib license we're using requires the copyright notice be > duplicated, we should have a centralized file with the license and a > copyright listing for all contributors. It's also nice to credit each > person in the file so there's a better idea of who did what. > > If we were on a self-hosted SVN, we could just put copyright notices > in the files and use a hook script to generate the global license > file. Unfortunately, I can't do that on SF.net. > > I'd say we create a global copyright file, and do credits in each file. > > On Thu, Aug 28, 2008 at 9:48 AM, Henri Häkkinen <hen...@gm...> > wrote: > > There has been one contribution so far which I have accepted to our code > > base and others who have offered their work for our use. The contribution > > was Orhun Birsoy's glmMatInverse4f implementation which was very good and > he > > may contribute more for the GLM. > > > > We need to write some sort of guidelines for patch submission. What > issues > > should these guidelines address? Code conventions, styles, line endings > etc. > > > > Also how are we going to give credit for the contributors? Should we > create > > some file where we list each contributor and his/her effort or should I > list > > the people in the source files? ATM I have not yet written Orhun's name > into > > anywhere until we get these issues decided. > > > > We should probably start using Sourceforge's tracker systems for feature > > requests and bugs so that people could see what kind of patches we need. > > > > -- > > 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: Branan R. <br...@gm...> - 2008-08-28 18:30:39
|
Probably the bug tracker. Branan On Thu, Aug 28, 2008 at 11:26 AM, Henri Häkkinen <hen...@gm...> wrote: > I have not used the Sourceforge tracker services much, so could you advice > me on this. > > There are four functions which needs fixing: > > glmMatInverse2f > glmMatInverse3f > glmMatRotateYPR3f > glmMatLookAt4f > > I would like to set a tracker for them so anyone willing to contribute could > take a look at them and I could myself move into other matters. Which > tracker should I use? Bug tracker, patch tracker? > > -- > 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 18:26:34
|
I have not used the Sourceforge tracker services much, so could you advice me on this. There are four functions which needs fixing: glmMatInverse2f glmMatInverse3f glmMatRotateYPR3f glmMatLookAt4f I would like to set a tracker for them so anyone willing to contribute could take a look at them and I could myself move into other matters. Which tracker should I use? Bug tracker, patch tracker? -- Henri 'henux' Häkkinen |
|
From: <gl...@mo...> - 2008-08-28 17:59:17
|
Yes, I'm sure that OpenGL code snipplet I posted is correct. That's what I've been doing for every car/aircraft/boat "simulation" I've created so far. Let's take aircraft for example. First you roll it (-180...+180 deg.). During this operation it's Z axis (points forward) remains unchanged. Now you apply pitch (-90...+90 deg.) - Z axis points a bit more up or down, but it keeps it's heading. Finally you apply heading (0...360 deg.). To apply such sequential operation to a mesh in OpenGL you need to call glRotatef in exactly the opposite order. So "heading" is issued first and "roll" is the last glRotatef issued. > Are you certain about this? In OpenGL matrices are transformed by "Mv". > That > is, matrix multiplied by vertex? > > On Thu, Aug 28, 2008 at 11:41 AM, <gl...@mo...> wrote: > >> > The function 'glmMatRotateYPR3f' calculates a combined rotation matrix >> > that >> > rotates a vector around the Y-axis (yaw), followed by X-axis (pitch), >> > followed by Z-axis (roll). In the actual code, the matrix needs to be >> > created in reverse? That, the matrix is Z*X*Y? Am I correct with this? >> >> >> It should be equivalent to: >> >> glRotatef(yaw, 0, 1, 0); >> glRotatef(pitch, 1, 0, 0); >> glRotatef(roll, 0, 0, 1); |
|
From: H. H. <hen...@gm...> - 2008-08-28 17:05:32
|
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 |
|
From: Branan R. <br...@gm...> - 2008-08-28 16:55:36
|
Since the zlib license we're using requires the copyright notice be duplicated, we should have a centralized file with the license and a copyright listing for all contributors. It's also nice to credit each person in the file so there's a better idea of who did what. If we were on a self-hosted SVN, we could just put copyright notices in the files and use a hook script to generate the global license file. Unfortunately, I can't do that on SF.net. I'd say we create a global copyright file, and do credits in each file. On Thu, Aug 28, 2008 at 9:48 AM, Henri Häkkinen <hen...@gm...> wrote: > There has been one contribution so far which I have accepted to our code > base and others who have offered their work for our use. The contribution > was Orhun Birsoy's glmMatInverse4f implementation which was very good and he > may contribute more for the GLM. > > We need to write some sort of guidelines for patch submission. What issues > should these guidelines address? Code conventions, styles, line endings etc. > > Also how are we going to give credit for the contributors? Should we create > some file where we list each contributor and his/her effort or should I list > the people in the source files? ATM I have not yet written Orhun's name into > anywhere until we get these issues decided. > > We should probably start using Sourceforge's tracker systems for feature > requests and bugs so that people could see what kind of patches we need. > > -- > 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 16:52:10
|
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 |
|
From: H. H. <hen...@gm...> - 2008-08-28 16:48:08
|
There has been one contribution so far which I have accepted to our code base and others who have offered their work for our use. The contribution was Orhun Birsoy's glmMatInverse4f implementation which was very good and he may contribute more for the GLM. We need to write some sort of guidelines for patch submission. What issues should these guidelines address? Code conventions, styles, line endings etc. Also how are we going to give credit for the contributors? Should we create some file where we list each contributor and his/her effort or should I list the people in the source files? ATM I have not yet written Orhun's name into anywhere until we get these issues decided. We should probably start using Sourceforge's tracker systems for feature requests and bugs so that people could see what kind of patches we need. -- Henri 'henux' Häkkinen |
|
From: H. H. <hen...@gm...> - 2008-08-28 16:41:05
|
The other functions that he provides can be useful for us too, at some point. However we must channel our time to get it done what we are now working on. On Thu, Aug 28, 2008 at 7:29 PM, Branan Riley <br...@gm...> wrote: > Right now I'm working on sphere, cone, and cylinder generation > functions. If you have generators that can create positions, normals, > and texture coordinates for other interesting shapes and equations, I > don't see why the couldn't be integrated. > > Branan > > On Thu, Aug 28, 2008 at 3:03 AM, v71 <mj...@ti...> wrote: > > I have written some code generation functions in the past . > > This library is made of many different geometric object, classic shapes, > > platonic , and extruded polygons, and a lathe generator. > > If you are interested in the code , i can post it . > > it uses my own classes for vertex and surfaces storing , so this maybe an > > issue, but > > the code is pretty straightfoward to look at > > ------------------------------------------------------------------------- > > 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: Branan R. <br...@gm...> - 2008-08-28 16:29:33
|
Right now I'm working on sphere, cone, and cylinder generation functions. If you have generators that can create positions, normals, and texture coordinates for other interesting shapes and equations, I don't see why the couldn't be integrated. Branan On Thu, Aug 28, 2008 at 3:03 AM, v71 <mj...@ti...> wrote: > I have written some code generation functions in the past . > This library is made of many different geometric object, classic shapes, > platonic , and extruded polygons, and a lathe generator. > If you are interested in the code , i can post it . > it uses my own classes for vertex and surfaces storing , so this maybe an > issue, but > the code is pretty straightfoward to look at > ------------------------------------------------------------------------- > 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 16:26:21
|
A matrix stack would require re-implementing many of the matrix functions to work on the stack variable, rather than an arbitrary matrix. Not difficult, but still a bit of a pain Branan On Thu, Aug 28, 2008 at 9:08 AM, <gl...@mo...> wrote: >> For point #3, a solution may be to create two versions of many of the >> matrix >> functions: >> >> *GLMmat3f *glmMatTranslate3f (GLMmat3f *out, GLfloat x, GLfloat y); >> GLMmat3f *glmMatTranslate3f (GLMmat3f *out, GLMmat3f *in, GLfloat x, >> GLfloat >> y);* > > I don't think we're doing any function overriding :) > > *IF* we're going to have both, then my proposal would be: > 1. > glmMatTranslate - creates matrix > glmMulMatTranslate - translates (multiplies by translation matrix) > > 2. > glmMatOfTranslation | glmMatTranslation (confusing) | glmTranslationMat > Last one is nice, but in conflict with our current naming convention. > > glmMatTranslate - translates matrix > > > I thought glm<type><action> naming convention is nice. Now I have my > doubts :P - glmTranslateMat and glmTranslationMat seem pretty distinct, > while having "Mat" at beginning requires some gymnastics later. > > > >> As for the matrix stack, it almost seems like it needs a separate library > > Perspective, LookAt, etc. functions should be in GLU (and they are), since > they're related to graphics. > > Matrix stack is not related to graphics actually. We have similar stack in > FPU, but FPU needed it because it was separate from CPU. With OpenGL we > have similar case (it can't access matrices stored in system memory - it > has it's own storage). > > Actually, for SDK we don't really need matrix stack :) Just think of it - > each function in the program has it's own local variables (so local > matrices, too). If we could design our examples in a way that matrix stack > matches function stack... :) > Yeah, I know - I'm a heretic ;) > > I didn't give it any serious thought - tus idea just popped up a moment > ago. Perhaps it's a good design pattern, perhaps it's not. > > > ------------------------------------------------------------------------- > 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 16:22:45
|
I believe this belongs to GLS and therefore Branan. On Thu, Aug 28, 2008 at 1:03 PM, v71 <mj...@ti...> wrote: > I have written some code generation functions in the past . > This library is made of many different geometric object, classic shapes, > platonic , and extruded polygons, and a lathe generator. > If you are interested in the code , i can post it . > it uses my own classes for vertex and surfaces storing , so this maybe an > issue, but > the code is pretty straightfoward to look at > > ------------------------------------------------------------------------- > 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 16:21:38
|
Are you certain about this? In OpenGL matrices are transformed by "Mv". That is, matrix multiplied by vertex? On Thu, Aug 28, 2008 at 11:41 AM, <gl...@mo...> wrote: > > The function 'glmMatRotateYPR3f' calculates a combined rotation matrix > > that > > rotates a vector around the Y-axis (yaw), followed by X-axis (pitch), > > followed by Z-axis (roll). In the actual code, the matrix needs to be > > created in reverse? That, the matrix is Z*X*Y? Am I correct with this? > > > It should be equivalent to: > > glRotatef(yaw, 0, 1, 0); > glRotatef(pitch, 1, 0, 0); > glRotatef(roll, 0, 0, 1); > > > > ------------------------------------------------------------------------- > 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: <gl...@mo...> - 2008-08-28 16:09:00
|
> For point #3, a solution may be to create two versions of many of the > matrix > functions: > > *GLMmat3f *glmMatTranslate3f (GLMmat3f *out, GLfloat x, GLfloat y); > GLMmat3f *glmMatTranslate3f (GLMmat3f *out, GLMmat3f *in, GLfloat x, > GLfloat > y);* I don't think we're doing any function overriding :) *IF* we're going to have both, then my proposal would be: 1. glmMatTranslate - creates matrix glmMulMatTranslate - translates (multiplies by translation matrix) 2. glmMatOfTranslation | glmMatTranslation (confusing) | glmTranslationMat Last one is nice, but in conflict with our current naming convention. glmMatTranslate - translates matrix I thought glm<type><action> naming convention is nice. Now I have my doubts :P - glmTranslateMat and glmTranslationMat seem pretty distinct, while having "Mat" at beginning requires some gymnastics later. > As for the matrix stack, it almost seems like it needs a separate library Perspective, LookAt, etc. functions should be in GLU (and they are), since they're related to graphics. Matrix stack is not related to graphics actually. We have similar stack in FPU, but FPU needed it because it was separate from CPU. With OpenGL we have similar case (it can't access matrices stored in system memory - it has it's own storage). Actually, for SDK we don't really need matrix stack :) Just think of it - each function in the program has it's own local variables (so local matrices, too). If we could design our examples in a way that matrix stack matches function stack... :) Yeah, I know - I'm a heretic ;) I didn't give it any serious thought - tus idea just popped up a moment ago. Perhaps it's a good design pattern, perhaps it's not. |
|
From: Andrew G. <and...@gm...> - 2008-08-28 14:53:46
|
For point #3, a solution may be to create two versions of many of the matrix functions: *GLMmat3f *glmMatTranslate3f (GLMmat3f *out, GLfloat x, GLfloat y); GLMmat3f *glmMatTranslate3f (GLMmat3f *out, GLMmat3f *in, GLfloat x, GLfloat y);* The first one creates a translation matrix (overwrites *out) and the second one multiplies *in by a rotation matrix and saves the result in *out. It isn't technically necessary as you can still do: *glmMatMult3f( &myMatrix, glmMatTranslate( &tmp, x, y ) );* The only disadvantage is the usage of a tmp variable. As for the matrix stack, it almost seems like it needs a separate library because it maintains state which GLM doesn't do (so far). I was wondering, are there any issues with creating our own version of GLU? The GLU spec was written against GL1.1. Seems like it's time to rewrite it. Otherwise we have to come up with another library name that means GL utility library, or GL matrix stack library (GLMS?). It is our own SDK so, as long as we don't use the official GLU library, I don't think there's any reason not to create our own. pudman |
|
From: v71 <mj...@ti...> - 2008-08-28 10:09:20
|
I have written some code generation functions in the past . This library is made of many different geometric object, classic shapes, platonic , and extruded polygons, and a lathe generator. If you are interested in the code , i can post it . it uses my own classes for vertex and surfaces storing , so this maybe an issue, but the code is pretty straightfoward to look at |
|
From: Jason M. <ko...@gm...> - 2008-08-28 09:32:15
|
So, I've taken a little time and looked at the current version of the math library. It seems to be coming along quite well, but I do have some suggestions for improvement. - 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. - 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. - 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 is more something that bugs me than something I think is wrong. - 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. - BTW, is the math library going to provide a matrix stack, or is that something for a higher-level library? |
|
From: <gl...@mo...> - 2008-08-28 08:41:44
|
> The function 'glmMatRotateYPR3f' calculates a combined rotation matrix > that > rotates a vector around the Y-axis (yaw), followed by X-axis (pitch), > followed by Z-axis (roll). In the actual code, the matrix needs to be > created in reverse? That, the matrix is Z*X*Y? Am I correct with this? It should be equivalent to: glRotatef(yaw, 0, 1, 0); glRotatef(pitch, 1, 0, 0); glRotatef(roll, 0, 0, 1); |
|
From: Branan R. <br...@gm...> - 2008-08-28 05:16:32
|
I think the compiler should optimize for the best assignment method, whether it's memcpy-based or something else. I'd just do a standard assignment. Branan On Wed, Aug 27, 2008 at 9:44 PM, Henri Häkkinen <hen...@gm...> wrote: > Is there any benefits of using memcpy instead of regular assingments? That > is, > > GLMmat4f a, b; > > a = b; > vs. > memcpy (&a, &b, sizeof (GLMmat4f)); > > -- > 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 04:44:44
|
Is there any benefits of using memcpy instead of regular assingments? That is, GLMmat4f a, b; a = b; vs. memcpy (&a, &b, sizeof (GLMmat4f)); -- Henri 'henux' Häkkinen |
|
From: Orhun B. <orh...@gm...> - 2008-08-28 04:15:29
|
As far as I know there is no way to automatically to checkout the files with the correct line endings. They have to be set in the repository. The article I send describes how to set the correct line endings of a text file that is to be added (or imported) to the repository. You (meaning people who have commit access to glsdk repository) have to make the changes mentioned in the article, not the users. svn book describes auto-props like this, enable-auto-props This instructs Subversion to automatically set properties on newly added or imported files. The default value is no, so set this to yes to enable Auto-props. -- Orhun Birsoy |
|
From: Branan R. <br...@gm...> - 2008-08-28 03:31:36
|
Yup, the same article has instructions on how to set that. I can add it to the FAQ, if that's what we want to do Branan On Wed, Aug 27, 2008 at 8:29 PM, Branan Riley <br...@gm...> wrote: > I believe there's a way to set SVN to automatically use native line > endings on checkout. We should probably just ask developers to set > that, rather than set a property for every single file. > > Branan > > On Wed, Aug 27, 2008 at 8:13 PM, Orhun Birsoy <orh...@gm...> wrote: >> I believe it would be best if svn:eol-style property is set for all the text >> files in the glsdk repository. >> >> http://www.zope.org/DevHome/Subversion/SubversionConfigurationForLineEndings >> >> -- >> 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 03:29:12
|
I believe there's a way to set SVN to automatically use native line endings on checkout. We should probably just ask developers to set that, rather than set a property for every single file. Branan On Wed, Aug 27, 2008 at 8:13 PM, Orhun Birsoy <orh...@gm...> wrote: > I believe it would be best if svn:eol-style property is set for all the text > files in the glsdk repository. > > http://www.zope.org/DevHome/Subversion/SubversionConfigurationForLineEndings > > -- > 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: Orhun B. <orh...@gm...> - 2008-08-28 03:13:25
|
I believe it would be best if svn:eol-style property is set for all the text files in the glsdk repository. http://www.zope.org/DevHome/Subversion/SubversionConfigurationForLineEndings -- Orhun Birsoy |
1 message has been excluded from this view by a project administrator.
