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: Branan R. <br...@gm...> - 2008-08-26 14:48:56
|
As far as code structure goes, I was thinking something like this for tutorials: void opengl_init() { } void opengl_draw() { } void opengl_deinit() { } int main(int argc, char** argv) { // GLFW init stuff opengl_init(); while(running) { // Check for events opengl_draw(); } opengl_deinit(); } It's simple, and it's easy to get started on tutorial content before our basecode is written - as long as you have the three core functions, you can port it to our basecode easily. Branan On Tue, Aug 26, 2008 at 7:05 AM, Henri Häkkinen <hen...@gm...> wrote: > Okay we will need to discuss about the actual tutorial content at some > point. I consider that we would need 'samples' and 'tutorials'. Samples are > complete demos with comments. Tutorials would be documents, explaining one > concept with source code snippets scattered around. We should focus on the > tutorials. > > For the initial SDK release I think we should include stuff for beginner > level. That is, stuff of basic workings of OpenGL3. The use of VBOs, vertex > arrays, shaders, FBOs, matrices... There should also be sections for > different operating systems about basic context creation, maybe. Tutorial > focus should be about explaining basics and why something is done in some > way. Beginners may be puzzled about the complexities of OpenGL3 context > creation or the matrix layout of OpenGL. These things and many more needs to > be explained. > > Also we may want to distinguish what goes into tutorials and what goes into > programming guide. Should we have programming guide? Any ideas what kind of > guide that should be? > > Other issues: > > 1. What is the basic tutorial structure? Every tutorial should follow some > coherent structure. > > 2. What will the actual tutorials be? Titles... > > 3. What coding convention are we going to use for the source code snippets? > I propose we use GNU-like style, as we have been using it for the baselibs. > Like this, > > void > some_func (int a, int b) > { > // 2 space for tabs > int x; > for (x = 0; x < 10; ++x) > { > } > } > > If somebody does not want to write tutorials in our convention, that is > cool, we may do the conversion once you submit the tutorial for us. (the > tutorials don't actually have to be written yet) > > Once we get these things decided upon, a sort of tutorial convention > document should be made (nothing fancy, just outlining the general style). > > -- > 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: Branan R. <br...@gm...> - 2008-08-26 14:44:12
|
Jaseon, Henri: If one of you has time, could you take care of that? I think last night proved I get pissy when I do admin work. Andrew: You could do it, too. Just email the files to the ML and someone will commit (or if you plan on contributing a lot, get a SF.net account and we can get you SVN access) Branan On Tue, Aug 26, 2008 at 6:49 AM, Andrew Gajda <and...@gm...> wrote: > I would suggest that minor documentation redundancy is not a real concern, > such that you have in the root directory: README, README.txt, and > README.html. README's are small and should point out where to go for the > real documentation anyway. > > On Tue, Aug 26, 2008 at 4:50 AM, Henri Häkkinen <hen...@gm...> wrote: >> >> That is a mighty idea, but I would perhaps suggest that we use HTML >> instead of plain text files. My rationale for this is that HTML offers >> better formatting capabilities and we don't have the issue of line endings. >> >> On Tue, Aug 26, 2008 at 9:29 AM, Jason McKesson <ko...@gm...> wrote: >>> >>> I've used enough UNIX-based tools to know that there is a general >>> convention to have a README file named "README" in the root directory of >>> an installed application or library. However, this is slightly annoying >>> for Windows users, as the OS is not really designed to frequently use >>> files without an extension. Giving these files a .txt extension would be >>> a small-but-valued convenience for Windows users. >>> >>> ------------------------------------------------------------------------- >>> 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-26 14:23:51
|
Okay. I think I can say that the GLM API is more or less "set". This does not mean that there won't be any additions or modifications to it but the general look of it is fine with me and it has been open for discussion for some time. So if Korval could at some point take it to his tasks to write the API reference outline in DocBook which I could fill in with the actual docs. The 'docs/sdk_reference/glm-apiref' file may also be removed in the process. On Tue, Aug 26, 2008 at 5:16 PM, Henri Häkkinen <hen...@gm...> wrote: > Okay I see what you mean by that. However I think our mathlib is intended > mainly to be used for OpenGL (a matrix based system), so mul and div feels a > bit redundant atm. > > > On Tue, Aug 26, 2008 at 1:20 AM, <gl...@mo...> wrote: > >> > What do you mean 'mathematical operations or software operations'? >> >> In math we can graphically represent vectors as arrows pointing form >> (point A to B. It's hard to imagine how we could visualize Mul operation >> in such form. >> >> In graphics library we often use vectors to represent size or other >> things. Especially when comes to 2D rendering, transforming vectors by >> means of Add/Mul is more common than transforming my multiplying (x, y, >> 1.0) vector by 3x3 matrix for the sake of both simplicity and performance. >> >> Even in 3D space. Imagine a volume defined as a box with origin at point A >> and a size of S. If point B lays within this box then C = (B - A) / S >> gives texture-space coordinate for point B. An alternative would be to >> define a 4x4 transformation matrix that transforms point B into texture >> space. Such matrix would be defined as conjunction of glmMatTranslate and >> glmMatScale. >> >> >> These are the kind of examples showing that even if something is useless >> in math, it's useful in programming. >> Sorry for speaking in riddles the first time ;) >> >> It's bed time for me. Cheers. >> >> >> ------------------------------------------------------------------------- >> 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 > > -- Henri 'henux' Häkkinen |
From: H. H. <hen...@gm...> - 2008-08-26 14:16:19
|
Okay I see what you mean by that. However I think our mathlib is intended mainly to be used for OpenGL (a matrix based system), so mul and div feels a bit redundant atm. On Tue, Aug 26, 2008 at 1:20 AM, <gl...@mo...> wrote: > > What do you mean 'mathematical operations or software operations'? > > In math we can graphically represent vectors as arrows pointing form > (point A to B. It's hard to imagine how we could visualize Mul operation > in such form. > > In graphics library we often use vectors to represent size or other > things. Especially when comes to 2D rendering, transforming vectors by > means of Add/Mul is more common than transforming my multiplying (x, y, > 1.0) vector by 3x3 matrix for the sake of both simplicity and performance. > > Even in 3D space. Imagine a volume defined as a box with origin at point A > and a size of S. If point B lays within this box then C = (B - A) / S > gives texture-space coordinate for point B. An alternative would be to > define a 4x4 transformation matrix that transforms point B into texture > space. Such matrix would be defined as conjunction of glmMatTranslate and > glmMatScale. > > > These are the kind of examples showing that even if something is useless > in math, it's useful in programming. > Sorry for speaking in riddles the first time ;) > > It's bed time for me. Cheers. > > > ------------------------------------------------------------------------- > 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-26 14:05:48
|
Okay we will need to discuss about the actual tutorial content at some point. I consider that we would need 'samples' and 'tutorials'. Samples are complete demos with comments. Tutorials would be documents, explaining one concept with source code snippets scattered around. We should focus on the tutorials. For the initial SDK release I think we should include stuff for beginner level. That is, stuff of basic workings of OpenGL3. The use of VBOs, vertex arrays, shaders, FBOs, matrices... There should also be sections for different operating systems about basic context creation, maybe. Tutorial focus should be about explaining basics and why something is done in some way. Beginners may be puzzled about the complexities of OpenGL3 context creation or the matrix layout of OpenGL. These things and many more needs to be explained. Also we may want to distinguish what goes into tutorials and what goes into programming guide. Should we have programming guide? Any ideas what kind of guide that should be? Other issues: 1. What is the basic tutorial structure? Every tutorial should follow some coherent structure. 2. What will the actual tutorials be? Titles... 3. What coding convention are we going to use for the source code snippets? I propose we use GNU-like style, as we have been using it for the baselibs. Like this, void some_func (int a, int b) { // 2 space for tabs int x; for (x = 0; x < 10; ++x) { } } If somebody does not want to write tutorials in our convention, that is cool, we may do the conversion once you submit the tutorial for us. (the tutorials don't actually have to be written yet) Once we get these things decided upon, a sort of tutorial convention document should be made (nothing fancy, just outlining the general style). -- Henri 'henux' Häkkinen |
From: Andrew G. <and...@gm...> - 2008-08-26 13:49:04
|
I would suggest that minor documentation redundancy is not a real concern, such that you have in the root directory: README, README.txt, and README.html. README's are small and should point out where to go for the real documentation anyway. On Tue, Aug 26, 2008 at 4:50 AM, Henri Häkkinen <hen...@gm...> wrote: > That is a mighty idea, but I would perhaps suggest that we use HTML instead > of plain text files. My rationale for this is that HTML offers better > formatting capabilities and we don't have the issue of line endings. > > > On Tue, Aug 26, 2008 at 9:29 AM, Jason McKesson <ko...@gm...> wrote: > >> I've used enough UNIX-based tools to know that there is a general >> convention to have a README file named "README" in the root directory of >> an installed application or library. However, this is slightly annoying >> for Windows users, as the OS is not really designed to frequently use >> files without an extension. Giving these files a .txt extension would be >> a small-but-valued convenience for Windows users. >> >> ------------------------------------------------------------------------- >> 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-26 08:50:07
|
That is a mighty idea, but I would perhaps suggest that we use HTML instead of plain text files. My rationale for this is that HTML offers better formatting capabilities and we don't have the issue of line endings. On Tue, Aug 26, 2008 at 9:29 AM, Jason McKesson <ko...@gm...> wrote: > I've used enough UNIX-based tools to know that there is a general > convention to have a README file named "README" in the root directory of > an installed application or library. However, this is slightly annoying > for Windows users, as the OS is not really designed to frequently use > files without an extension. Giving these files a .txt extension would be > a small-but-valued convenience for Windows users. > > ------------------------------------------------------------------------- > 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-26 06:29:47
|
I've used enough UNIX-based tools to know that there is a general convention to have a README file named "README" in the root directory of an installed application or library. However, this is slightly annoying for Windows users, as the OS is not really designed to frequently use files without an extension. Giving these files a .txt extension would be a small-but-valued convenience for Windows users. |
From: H. H. <hen...@gm...> - 2008-08-26 04:29:30
|
I don't think the web site is our priority at this moment at all. We can keep the FAQ on the front page as it is, maybe add new entries as we go, but a CMS/front page needs to get established only when we are close to alpha release and even then it can look unprofessional and quick hack. When we get something out and people see we have the capability, we can get more people involved. A dedicated webmaster is something we should definitely have at some point, but this can wait. Our priorities are the libs at this moment foremost. Also we should keep cool in general. What people may argue in the OpenGL forums is not our concern either IMO. The mailing lists is our shared voice not the forum. We are all doing this as a sort of hobby not as a work. It should be fun to do and an interesting techinical challenge not something which is an utter responsibility that must come first before anything else in our personal lives. So my opinion is; lets leave the web as it is. On Tue, Aug 26, 2008 at 7:11 AM, Branan Riley <br...@gm...> wrote: > I have no desire to be the webmaster right now. There's a bunch of > stuff that we've talked about on the mailing list that needs to be put > up there. A Proper front page should probably be made, too. I can do > it, but I'd rather not spend the time on it. > > I'm looking for volunteers to take care of web stuff. > > Thanks in advance, > Branan > > ------------------------------------------------------------------------- > 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-26 04:11:32
|
I have no desire to be the webmaster right now. There's a bunch of stuff that we've talked about on the mailing list that needs to be put up there. A Proper front page should probably be made, too. I can do it, but I'd rather not spend the time on it. I'm looking for volunteers to take care of web stuff. Thanks in advance, Branan |
From: H. H. <hen...@gm...> - 2008-08-26 02:24:51
|
Yes, a simple FAQ would be fine for the time being. On Tue, Aug 26, 2008 at 5:23 AM, Branan Riley <br...@gm...> wrote: > Really, we need an entire website. I need to do some research on a > good CMS that will fit in our sourceforge space, and will be simple > for our purposes. I hate coding HTML. > > I can start a FAQ, though, and get that up on the index page. > > Branan > > On Mon, Aug 25, 2008 at 7:11 PM, Henri Häkkinen <hen...@gm...> > wrote: > > Thats nice. > > > > I think we should do a FAQ into this page and explain why we are using C > for > > our libraries. The subject seems to pop up in the forums quite often and > > people are sending me suggestions and links into their C++ mathlibs. > > > > On Tue, Aug 26, 2008 at 1:26 AM, Branan Riley <br...@gm...> wrote: > >> > >> The DNS and directory structure for glsdk.sourceforge.net are finally > >> finished. I have a placeholder page that I'll copy in as soon as I get > >> home (1.5 to 2 hours). > >> > >> Branan > >> > >> > ------------------------------------------------------------------------- > >> 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: Branan R. <br...@gm...> - 2008-08-26 02:23:09
|
Really, we need an entire website. I need to do some research on a good CMS that will fit in our sourceforge space, and will be simple for our purposes. I hate coding HTML. I can start a FAQ, though, and get that up on the index page. Branan On Mon, Aug 25, 2008 at 7:11 PM, Henri Häkkinen <hen...@gm...> wrote: > Thats nice. > > I think we should do a FAQ into this page and explain why we are using C for > our libraries. The subject seems to pop up in the forums quite often and > people are sending me suggestions and links into their C++ mathlibs. > > On Tue, Aug 26, 2008 at 1:26 AM, Branan Riley <br...@gm...> wrote: >> >> The DNS and directory structure for glsdk.sourceforge.net are finally >> finished. I have a placeholder page that I'll copy in as soon as I get >> home (1.5 to 2 hours). >> >> Branan >> >> ------------------------------------------------------------------------- >> 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-26 02:11:45
|
Thats nice. I think we should do a FAQ into this page and explain why we are using C for our libraries. The subject seems to pop up in the forums quite often and people are sending me suggestions and links into their C++ mathlibs. On Tue, Aug 26, 2008 at 1:26 AM, Branan Riley <br...@gm...> wrote: > The DNS and directory structure for glsdk.sourceforge.net are finally > finished. I have a placeholder page that I'll copy in as soon as I get > home (1.5 to 2 hours). > > Branan > > ------------------------------------------------------------------------- > 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-25 22:26:37
|
The DNS and directory structure for glsdk.sourceforge.net are finally finished. I have a placeholder page that I'll copy in as soon as I get home (1.5 to 2 hours). Branan |
From: <gl...@mo...> - 2008-08-25 22:20:48
|
> What do you mean 'mathematical operations or software operations'? In math we can graphically represent vectors as arrows pointing form (point A to B. It's hard to imagine how we could visualize Mul operation in such form. In graphics library we often use vectors to represent size or other things. Especially when comes to 2D rendering, transforming vectors by means of Add/Mul is more common than transforming my multiplying (x, y, 1.0) vector by 3x3 matrix for the sake of both simplicity and performance. Even in 3D space. Imagine a volume defined as a box with origin at point A and a size of S. If point B lays within this box then C = (B - A) / S gives texture-space coordinate for point B. An alternative would be to define a 4x4 transformation matrix that transforms point B into texture space. Such matrix would be defined as conjunction of glmMatTranslate and glmMatScale. These are the kind of examples showing that even if something is useless in math, it's useful in programming. Sorry for speaking in riddles the first time ;) It's bed time for me. Cheers. |
From: H. H. <hen...@gm...> - 2008-08-25 22:14:28
|
> > 1) Should we provide -Mul and -Div for vectors? > Depends if this math library is graphics-related ;) > It also depends on whenever we're defining matmemathical operations or > software functions in this library. > This mathlib is graphics related. What do you mean 'mathematical operations or software operations'? Isn't glmMatRotateYPR3 obsolete since there are glmMatRotate[X|Y|Z]3 > functions defined? > No. RotateYPR is a convenience function, meaning that it is easier for the user to set up a complicated rotation matrix in this way. It is also faster to calculate a yaw-pitch-roll rotation matrix in one go than constructing each rotation independently and then multiplying them together. The current implementation thought does it just this way, but the function needs a cleanup. Will only Mat3 have Scale and ScaleUniform defined? 3D scaling matrices are natively 3x3 matrices. There could be a 4x4 version of it and there definelty should be 2x2 version of it (this will be added). > Vector's Scale function is actually equivalent to ScaleUniform function > for matrix. MatScale* creates 3x3 scaling matrices while VecScale multiplies each vector member by a scalar. They are two different things. > Should vectors have both Scale and ScaleUniform functions > defined instead? If yes, then Mul and Div become obsolete. Vectors could have ScaleUniform also for a convenience, but currently they don't have. Vector mul and div are not part of the current API for reasons stated in my previous posts. > Should we have: > glmMatRotate3f(GLMmat3f *out, const GLMvec3f* axis, GLfloat angle); > or rather: > glmMatRotate3f(GLMmat3f *out, GLfloat angle, GLfloat x, GLfloat y, GLfloat > z); > ? > Please note that these questions are not in our issue list unless Henri H. > sees them as worth considering. Your points are very well worth considering. Currently the API has only Rotate(out, axis, angle). I think it is bad idea to bloat the API needlesly and we should choose only one of the two. The real question is which is better. The matter is open for discussion. > > 2) Should we use short naming convention or is the current convention > fine? > Full operation names are better (subjective opinion), with the exception > of "Subtract" :) > Okay, I gather you support the current API effort. > > 4) Should we have the dimension of the type in the end of the entry-point > > (like in OpenGL) or in the middle? > > Both are equally fine and referring either to Vec<n> data type or function > operating on <n> components, but dimension placed at end makes for a nice > separator between operation name and data type postfix. > That is how I feel also. This is also the OpenGL convention of operations which we would like to conform to. My current GLM efforts revolve around stabilizing and writing test cases for the current API. This will take time, as matrix test cases are complicated to write. Once this is done, I will continue on adding new entry-points (such as the above suggested 2x2 scaling matrix constructor). -- Henri 'henux' Häkkinen |
From: H. H. <hen...@gm...> - 2008-08-25 21:54:13
|
On Tue, Aug 26, 2008 at 12:39 AM, <gl...@mo...> wrote: > > 1) Should we provide -Mul and -Div for vectors? > Depends if this math library is graphics-related ;) > It also depends on whenever we're defining matmemathical operations or > software functions in this library. This mathlib is graphics related. What do you mean 'mathematical operations or software operations'? > > > Isn't glmMatRotateYPR3 obsolete since there are glmMatRotate[X|Y|Z]3 > functions defined? No. glmMatRotateYPR is a convenience function, meaning that it is easier for the user to set up a complicated rotation matrix in this way. Also, it is also faster to calculate a yaw-pitch-roll rotation matrix in one go than constructing each rotation in separate phase and then multiplying them together. The current implementation thought, does it just this way, but this function needs to be cleanup and fixed in time. Will only Mat3 have Scale and ScaleUniform defined? > MatScale3 and -ScalingUniform3 functions constructs a 3x3 scaling matrix. It might be useful for the API to have equivalent 4x4 matrix constructors too, thought. The API is not yet set in stone. My current effort includes writing test cases for the current API, and when this is done, I will continue on adding more functionality. > > Vector's Scale function is actually equivalent to ScaleUniform function > for matrix. Should vectors have both Scale and ScaleUniform functions > defined instead? If yes, then Mul and Div become obsolete. > Yes and no. The vector scale function multiplies each vector member by scalar. Matrix scale constructors create scaling matrices. They do different things. VecScaleUniform is an entry-point which could be included for convenience thought, true. Mul and div for vectors are not part of the API for reasons stated in my previous posts (they are not defined in vector calculus). > > Should we have: > glmMatRotate3f(GLMmat3f *out, const GLMvec3f* axis, GLfloat angle); > or rather: > glmMatRotate3f(GLMmat3f *out, GLfloat angle, GLfloat x, GLfloat y, GLfloat > z); > ? > > Please note that these questions are not in our issue list unless Henri H. > sees them as worth considering. > Of course, your points are very worth of considering :) At the moment I have only MatRotate (out, axis, angle). I think we don't want to bloat the API any more than we actually need. Which version of the above functions we should actually have, is a valid question indeed. Providing them both, IMO, is redundant. This is open for discussion. > > > > 2) Should we use short naming convention or is the current convention > fine? > > Full operation names are better (subjective opinion), with the exception > of "Subtract" :) > Okay so I gather you support the current API convention. > > > > > 4) Should we have the dimension of the type in the end of the entry-point > > (like in OpenGL) or in the middle? > > Both are equally fine and referring either to Vec<n> data type or function > operating on <n> components, but dimension placed at end makes for a nice > separator between operation name and data type postfix. > That is my opinion too and that is also the OpenGL convention of operations and we would like to conform with 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: <gl...@mo...> - 2008-08-25 21:39:07
|
> 1) Should we provide -Mul and -Div for vectors? Depends if this math library is graphics-related ;) It also depends on whenever we're defining matmemathical operations or software functions in this library. Isn't glmMatRotateYPR3 obsolete since there are glmMatRotate[X|Y|Z]3 functions defined? Will only Mat3 have Scale and ScaleUniform defined? Vector's Scale function is actually equivalent to ScaleUniform function for matrix. Should vectors have both Scale and ScaleUniform functions defined instead? If yes, then Mul and Div become obsolete. Should we have: glmMatRotate3f(GLMmat3f *out, const GLMvec3f* axis, GLfloat angle); or rather: glmMatRotate3f(GLMmat3f *out, GLfloat angle, GLfloat x, GLfloat y, GLfloat z); ? Please note that these questions are not in our issue list unless Henri H. sees them as worth considering. > 2) Should we use short naming convention or is the current convention fine? Full operation names are better (subjective opinion), with the exception of "Subtract" :) > 4) Should we have the dimension of the type in the end of the entry-point > (like in OpenGL) or in the middle? Both are equally fine and referring either to Vec<n> data type or function operating on <n> components, but dimension placed at end makes for a nice separator between operation name and data type postfix. |
From: Mars_999 <ma...@si...> - 2008-08-25 21:32:50
|
Good you read my mind then. And the short form is preferred IMO. ----- Original Message ----- From: Henri Häkkinen To: gls...@li... Sent: Monday, August 25, 2008 4:08 PM Subject: Re: [Glsdk-devel] [GLm] api Mul and div for colors: I have the idea of implementing colors as different types altogether: typedef ... GLMcol3f; typedef ... GLMcol4f; glmColSet3f glmColAdd3f ... So in this respect, mul and div for vectors are redundant. About glmVecScale: yes that is already in the current API. About doubles: yes, doubles are not yet supported in the GL (afaik), but they will be probably included when the hardware supports them. So we can prepare for this and use the -f prefix. Also, for colors we might want to have things like -ub also. So including the type postfix makes sense. We also had an earlier short discussion in #glsdk if we should have: glmVectorSet2f glmMatrixSet2f glmMatrixIdentity2f instead of glmVecSet2f glmMatSet2f ... But we decided to keep the short ones. Also this is open for discussion, as is everything dealing with the GLM API. Comments are most welcome. On Mon, Aug 25, 2008 at 11:53 PM, Mars_999 <ma...@si...> wrote: Oops I should have said Mul, and Div aren't defined for vectors. Just clearing up my posting. ----- Original Message ----- From: Mars_999 To: gls...@li... Sent: Monday, August 25, 2008 3:44 PM Subject: Re: [Glsdk-devel] [GLm] api glmVecSet2f glmVecAdd2f glmVecLength2f glmVecTransform2f glmMatSet2f glmMatIdentity2f I vote for this. Correct, in mathematics vectors aren't defined, but I was thinking ahead for colors or other uses, having these would be nice, but anyone who is coding graphics should understand this already? Also don't forget to put in a glmVecScale2f? I guess we could put double in but, IIRC double was going to get dropped? And we aren't doing OpenCL or CUDA here AFAIK, so double would kind of wasteful in terms of time spent. ----- Original Message ----- From: Henri Häkkinen To: gls...@li... Sent: Monday, August 25, 2008 3:17 PM Subject: Re: [Glsdk-devel] [GLm] api We are currently using floats, but may want to reserve the possibility of havings doubles too. Therefore we use the -f postfix. This is also the GL convention of doing things: glVertex2f and therefore we have: glmVecSet2f instead of: glmVec2Set Also, we don't have glmVecDiv or glmVecMul. Why? Because vector division or multiplication are not defined in linear-algebra. There are two kinds of vector products: cross and dot. These are handled by the -Cross and -Dot entry points. Member-wise div or mul are not mathemtically defined operations in vector calculus AFAIK. We have now several open issues with the GLM API: 1) Should we provide -Mul and -Div for vectors? My opinion: no, as they are not defined in mathematics and they generally are not needed 2) Should we use short naming convention or is the current convention fine? The current convention is, for example: glmVecSet2f glmVecAdd2f glmVecLength2f glmVecTransform2f glmMatSet2f glmMatIdentity2f The proposed short convention would be, for example: glmVecLen2f glmVecTrans2f glmMatIdent2f glmMatDet2f 3) Should we drop the -f postfix, or should we keep it for future possible double types?, glmVecSet2f (the current API) vs. glmVecSet2 (the proposed) My opinion: we should keep the -f, it is more OpenGL-like and we reserve the possibility of -d 4) Should we have the dimension of the type in the end of the entry-point (like in OpenGL) or in the middle? glmVecSet2f (the current API) vs. glmVec2Setf (the proposed) My opinion: glmVecSet2f, it is more OpenGL-like Issues are open for discussion. Please comment. On Mon, Aug 25, 2008 at 10:10 PM, Mars_999 <ma...@si...> wrote: I haven't looked at the lib yet, but aren't we just going to work with floats all the time? glmVec2Sub glmVec3Sub glmVec4Sub glmVec2Add glmVec3Add glmVec4Add glmVec2Mul glmVec2Div glmVec2Norm glmVec2Transf glmVec3Cross glmVec3Dot I like that format... ----- Original Message ----- From: Henri Häkkinen To: glsdk-devel Sent: Monday, August 25, 2008 2:04 PM Subject: [Glsdk-devel] [GLm] api The GLM API seems at this moment to use two sets of naming styles. Compare these two for example: glmVecSub2f glmVecLength2f The first function is using a short form for the operation ('sub' as from 'substract') while the other is using long form. Should we simplify the API to look like this: glmVecSub2f glmVecLen2f Althought on the other hand, how do we shorten such stuff as Normalize, Transform, Identity, Inverse? This does not necessary look good: glmVecNorm glmVecTrans glmMatTrans glmMatInv glmMatIdent Is this even a big issue? Comments? If we decide to keep the API as it is now, I think we should lock it in and begin to outline the API reference for it. For later versions, I would like to implement such stuff as colors, quaternions and maybe planes and matrix stacks but this can wait. Bigger priority is to get the current version working and tested for. For Korval: I outlined some API ref in a plain text format. You may find it in 'docs/sdk_reference/glm-apiref' in the latest revision. You may use this as ideas for the DocBook API ref and this file needs to get removed once you migrate it into DocBook. -- 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 ------------------------------------------------------------------------- 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-25 21:07:56
|
Mul and div for colors: I have the idea of implementing colors as different types altogether: typedef ... GLMcol3f; typedef ... GLMcol4f; glmColSet3f glmColAdd3f ... So in this respect, mul and div for vectors are redundant. About glmVecScale: yes that is already in the current API. About doubles: yes, doubles are not yet supported in the GL (afaik), but they will be probably included when the hardware supports them. So we can prepare for this and use the -f prefix. Also, for colors we might want to have things like -ub also. So including the type postfix makes sense. We also had an earlier short discussion in #glsdk if we should have: glmVectorSet2f glmMatrixSet2f glmMatrixIdentity2f instead of glmVecSet2f glmMatSet2f ... But we decided to keep the short ones. Also this is open for discussion, as is everything dealing with the GLM API. Comments are most welcome. On Mon, Aug 25, 2008 at 11:53 PM, Mars_999 <ma...@si...> wrote: > Oops I should have said Mul, and Div aren't defined for vectors. Just > clearing up my posting. > > ----- Original Message ----- > *From:* Mars_999 <ma...@si...> > *To:* gls...@li... > *Sent:* Monday, August 25, 2008 3:44 PM > *Subject:* Re: [Glsdk-devel] [GLm] api > > glmVecSet2f > glmVecAdd2f > glmVecLength2f > glmVecTransform2f > glmMatSet2f > glmMatIdentity2f > > I vote for this. > > Correct, in mathematics vectors aren't defined, but I was thinking ahead > for colors or other uses, having these would be nice, but anyone who is > coding graphics should understand this already? > > Also don't forget to put in a glmVecScale2f? I guess we could put double in > but, IIRC double was going to get dropped? And we aren't doing OpenCL or > CUDA here AFAIK, so double would kind of wasteful in terms of time spent. > > ----- Original Message ----- > *From:* Henri Häkkinen <hen...@gm...> > *To:* gls...@li... > *Sent:* Monday, August 25, 2008 3:17 PM > *Subject:* Re: [Glsdk-devel] [GLm] api > > We are currently using floats, but may want to reserve the possibility of > havings doubles too. Therefore we use the -f postfix. This is also the GL > convention of doing things: > > glVertex2f > > and therefore we have: > > glmVecSet2f > > instead of: > > glmVec2Set > > Also, we don't have glmVecDiv or glmVecMul. Why? Because vector division or > multiplication are not defined in linear-algebra. There are two kinds of > vector products: cross and dot. These are handled by the -Cross and -Dot > entry points. Member-wise div or mul are not mathemtically defined > operations in vector calculus AFAIK. > > We have now several open issues with the GLM API: > > 1) Should we provide -Mul and -Div for vectors? > My opinion: no, as they are not defined in mathematics and they generally > are not needed > > 2) Should we use short naming convention or is the current convention fine? > > The current convention is, for example: > > glmVecSet2f > glmVecAdd2f > glmVecLength2f > glmVecTransform2f > glmMatSet2f > glmMatIdentity2f > > The proposed short convention would be, for example: > > glmVecLen2f > glmVecTrans2f > glmMatIdent2f > glmMatDet2f > > 3) Should we drop the -f postfix, or should we keep it for future possible > double types?, > > glmVecSet2f (the current API) vs. glmVecSet2 (the proposed) > > My opinion: we should keep the -f, it is more OpenGL-like and we reserve > the possibility of -d > > 4) Should we have the dimension of the type in the end of the entry-point > (like in OpenGL) or in the middle? > > glmVecSet2f (the current API) vs. glmVec2Setf (the proposed) > > My opinion: glmVecSet2f, it is more OpenGL-like > > > Issues are open for discussion. Please comment. > > > > On Mon, Aug 25, 2008 at 10:10 PM, Mars_999 <ma...@si...> wrote: > >> I haven't looked at the lib yet, but aren't we just going to work with >> floats all the time? >> >> glmVec2Sub >> glmVec3Sub >> glmVec4Sub >> >> glmVec2Add >> glmVec3Add >> glmVec4Add >> >> glmVec2Mul >> glmVec2Div >> >> glmVec2Norm >> glmVec2Transf >> glmVec3Cross >> glmVec3Dot >> >> I like that format... >> >> ----- Original Message ----- >> *From:* Henri Häkkinen <hen...@gm...> >> *To:* glsdk-devel <gls...@li...> >> *Sent:* Monday, August 25, 2008 2:04 PM >> *Subject:* [Glsdk-devel] [GLm] api >> >> The GLM API seems at this moment to use two sets of naming styles. Compare >> these two for example: >> >> glmVecSub2f >> glmVecLength2f >> >> The first function is using a short form for the operation ('sub' as from >> 'substract') while the other is using long form. Should we simplify the API >> to look like this: >> >> glmVecSub2f >> glmVecLen2f >> >> Althought on the other hand, how do we shorten such stuff as Normalize, >> Transform, Identity, Inverse? This does not necessary look good: >> >> glmVecNorm >> glmVecTrans >> glmMatTrans >> glmMatInv >> glmMatIdent >> >> Is this even a big issue? Comments? >> >> If we decide to keep the API as it is now, I think we should lock it in >> and begin to outline the API reference for it. For later versions, I would >> like to implement such stuff as colors, quaternions and maybe planes and >> matrix stacks but this can wait. Bigger priority is to get the current >> version working and tested for. >> >> For Korval: I outlined some API ref in a plain text format. You may find >> it in 'docs/sdk_reference/glm-apiref' in the latest revision. You may use >> this as ideas for the DocBook API ref and this file needs to get removed >> once you migrate it into DocBook. >> >> -- >> 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 > > > ------------------------------------------------------------------------- > 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-25 20:53:57
|
Oops I should have said Mul, and Div aren't defined for vectors. Just clearing up my posting. ----- Original Message ----- From: Mars_999 To: gls...@li... Sent: Monday, August 25, 2008 3:44 PM Subject: Re: [Glsdk-devel] [GLm] api glmVecSet2f glmVecAdd2f glmVecLength2f glmVecTransform2f glmMatSet2f glmMatIdentity2f I vote for this. Correct, in mathematics vectors aren't defined, but I was thinking ahead for colors or other uses, having these would be nice, but anyone who is coding graphics should understand this already? Also don't forget to put in a glmVecScale2f? I guess we could put double in but, IIRC double was going to get dropped? And we aren't doing OpenCL or CUDA here AFAIK, so double would kind of wasteful in terms of time spent. ----- Original Message ----- From: Henri Häkkinen To: gls...@li... Sent: Monday, August 25, 2008 3:17 PM Subject: Re: [Glsdk-devel] [GLm] api We are currently using floats, but may want to reserve the possibility of havings doubles too. Therefore we use the -f postfix. This is also the GL convention of doing things: glVertex2f and therefore we have: glmVecSet2f instead of: glmVec2Set Also, we don't have glmVecDiv or glmVecMul. Why? Because vector division or multiplication are not defined in linear-algebra. There are two kinds of vector products: cross and dot. These are handled by the -Cross and -Dot entry points. Member-wise div or mul are not mathemtically defined operations in vector calculus AFAIK. We have now several open issues with the GLM API: 1) Should we provide -Mul and -Div for vectors? My opinion: no, as they are not defined in mathematics and they generally are not needed 2) Should we use short naming convention or is the current convention fine? The current convention is, for example: glmVecSet2f glmVecAdd2f glmVecLength2f glmVecTransform2f glmMatSet2f glmMatIdentity2f The proposed short convention would be, for example: glmVecLen2f glmVecTrans2f glmMatIdent2f glmMatDet2f 3) Should we drop the -f postfix, or should we keep it for future possible double types?, glmVecSet2f (the current API) vs. glmVecSet2 (the proposed) My opinion: we should keep the -f, it is more OpenGL-like and we reserve the possibility of -d 4) Should we have the dimension of the type in the end of the entry-point (like in OpenGL) or in the middle? glmVecSet2f (the current API) vs. glmVec2Setf (the proposed) My opinion: glmVecSet2f, it is more OpenGL-like Issues are open for discussion. Please comment. On Mon, Aug 25, 2008 at 10:10 PM, Mars_999 <ma...@si...> wrote: I haven't looked at the lib yet, but aren't we just going to work with floats all the time? glmVec2Sub glmVec3Sub glmVec4Sub glmVec2Add glmVec3Add glmVec4Add glmVec2Mul glmVec2Div glmVec2Norm glmVec2Transf glmVec3Cross glmVec3Dot I like that format... ----- Original Message ----- From: Henri Häkkinen To: glsdk-devel Sent: Monday, August 25, 2008 2:04 PM Subject: [Glsdk-devel] [GLm] api The GLM API seems at this moment to use two sets of naming styles. Compare these two for example: glmVecSub2f glmVecLength2f The first function is using a short form for the operation ('sub' as from 'substract') while the other is using long form. Should we simplify the API to look like this: glmVecSub2f glmVecLen2f Althought on the other hand, how do we shorten such stuff as Normalize, Transform, Identity, Inverse? This does not necessary look good: glmVecNorm glmVecTrans glmMatTrans glmMatInv glmMatIdent Is this even a big issue? Comments? If we decide to keep the API as it is now, I think we should lock it in and begin to outline the API reference for it. For later versions, I would like to implement such stuff as colors, quaternions and maybe planes and matrix stacks but this can wait. Bigger priority is to get the current version working and tested for. For Korval: I outlined some API ref in a plain text format. You may find it in 'docs/sdk_reference/glm-apiref' in the latest revision. You may use this as ideas for the DocBook API ref and this file needs to get removed once you migrate it into DocBook. -- 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: Branan R. <br...@gm...> - 2008-08-25 20:53:16
|
Double won't be added until the hardware supports it, so there won't be any time wasted. I'm also OK with the longer names. On Mon, Aug 25, 2008 at 1:44 PM, Mars_999 <ma...@si...> wrote: > glmVecSet2f > glmVecAdd2f > glmVecLength2f > glmVecTransform2f > glmMatSet2f > glmMatIdentity2f > > I vote for this. > > Correct, in mathematics vectors aren't defined, but I was thinking ahead for > colors or other uses, having these would be nice, but anyone who is coding > graphics should understand this already? > > Also don't forget to put in a glmVecScale2f? I guess we could put double in > but, IIRC double was going to get dropped? And we aren't doing OpenCL or > CUDA here AFAIK, so double would kind of wasteful in terms of time spent. > > ----- Original Message ----- > From: Henri Häkkinen > To: gls...@li... > Sent: Monday, August 25, 2008 3:17 PM > Subject: Re: [Glsdk-devel] [GLm] api > We are currently using floats, but may want to reserve the possibility of > havings doubles too. Therefore we use the -f postfix. This is also the GL > convention of doing things: > > glVertex2f > > and therefore we have: > > glmVecSet2f > > instead of: > > glmVec2Set > > Also, we don't have glmVecDiv or glmVecMul. Why? Because vector division or > multiplication are not defined in linear-algebra. There are two kinds of > vector products: cross and dot. These are handled by the -Cross and -Dot > entry points. Member-wise div or mul are not mathemtically defined > operations in vector calculus AFAIK. > > We have now several open issues with the GLM API: > > 1) Should we provide -Mul and -Div for vectors? > My opinion: no, as they are not defined in mathematics and they generally > are not needed > > 2) Should we use short naming convention or is the current convention fine? > > The current convention is, for example: > > glmVecSet2f > glmVecAdd2f > glmVecLength2f > glmVecTransform2f > glmMatSet2f > glmMatIdentity2f > > The proposed short convention would be, for example: > > glmVecLen2f > glmVecTrans2f > glmMatIdent2f > glmMatDet2f > > 3) Should we drop the -f postfix, or should we keep it for future possible > double types?, > > glmVecSet2f (the current API) vs. glmVecSet2 (the proposed) > > My opinion: we should keep the -f, it is more OpenGL-like and we reserve the > possibility of -d > > 4) Should we have the dimension of the type in the end of the entry-point > (like in OpenGL) or in the middle? > > glmVecSet2f (the current API) vs. glmVec2Setf (the proposed) > > My opinion: glmVecSet2f, it is more OpenGL-like > > > Issues are open for discussion. Please comment. > > > > On Mon, Aug 25, 2008 at 10:10 PM, Mars_999 <ma...@si...> wrote: >> >> I haven't looked at the lib yet, but aren't we just going to work with >> floats all the time? >> >> glmVec2Sub >> glmVec3Sub >> glmVec4Sub >> >> glmVec2Add >> glmVec3Add >> glmVec4Add >> >> glmVec2Mul >> glmVec2Div >> >> glmVec2Norm >> glmVec2Transf >> glmVec3Cross >> glmVec3Dot >> >> I like that format... >> >> ----- Original Message ----- >> From: Henri Häkkinen >> To: glsdk-devel >> Sent: Monday, August 25, 2008 2:04 PM >> Subject: [Glsdk-devel] [GLm] api >> The GLM API seems at this moment to use two sets of naming styles. Compare >> these two for example: >> >> glmVecSub2f >> glmVecLength2f >> >> The first function is using a short form for the operation ('sub' as from >> 'substract') while the other is using long form. Should we simplify the API >> to look like this: >> >> glmVecSub2f >> glmVecLen2f >> >> Althought on the other hand, how do we shorten such stuff as Normalize, >> Transform, Identity, Inverse? This does not necessary look good: >> >> glmVecNorm >> glmVecTrans >> glmMatTrans >> glmMatInv >> glmMatIdent >> >> Is this even a big issue? Comments? >> >> If we decide to keep the API as it is now, I think we should lock it in >> and begin to outline the API reference for it. For later versions, I would >> like to implement such stuff as colors, quaternions and maybe planes and >> matrix stacks but this can wait. Bigger priority is to get the current >> version working and tested for. >> >> For Korval: I outlined some API ref in a plain text format. You may find >> it in 'docs/sdk_reference/glm-apiref' in the latest revision. You may use >> this as ideas for the DocBook API ref and this file needs to get removed >> once you migrate it into DocBook. >> >> -- >> 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: Mars_999 <ma...@si...> - 2008-08-25 20:44:51
|
glmVecSet2f glmVecAdd2f glmVecLength2f glmVecTransform2f glmMatSet2f glmMatIdentity2f I vote for this. Correct, in mathematics vectors aren't defined, but I was thinking ahead for colors or other uses, having these would be nice, but anyone who is coding graphics should understand this already? Also don't forget to put in a glmVecScale2f? I guess we could put double in but, IIRC double was going to get dropped? And we aren't doing OpenCL or CUDA here AFAIK, so double would kind of wasteful in terms of time spent. ----- Original Message ----- From: Henri Häkkinen To: gls...@li... Sent: Monday, August 25, 2008 3:17 PM Subject: Re: [Glsdk-devel] [GLm] api We are currently using floats, but may want to reserve the possibility of havings doubles too. Therefore we use the -f postfix. This is also the GL convention of doing things: glVertex2f and therefore we have: glmVecSet2f instead of: glmVec2Set Also, we don't have glmVecDiv or glmVecMul. Why? Because vector division or multiplication are not defined in linear-algebra. There are two kinds of vector products: cross and dot. These are handled by the -Cross and -Dot entry points. Member-wise div or mul are not mathemtically defined operations in vector calculus AFAIK. We have now several open issues with the GLM API: 1) Should we provide -Mul and -Div for vectors? My opinion: no, as they are not defined in mathematics and they generally are not needed 2) Should we use short naming convention or is the current convention fine? The current convention is, for example: glmVecSet2f glmVecAdd2f glmVecLength2f glmVecTransform2f glmMatSet2f glmMatIdentity2f The proposed short convention would be, for example: glmVecLen2f glmVecTrans2f glmMatIdent2f glmMatDet2f 3) Should we drop the -f postfix, or should we keep it for future possible double types?, glmVecSet2f (the current API) vs. glmVecSet2 (the proposed) My opinion: we should keep the -f, it is more OpenGL-like and we reserve the possibility of -d 4) Should we have the dimension of the type in the end of the entry-point (like in OpenGL) or in the middle? glmVecSet2f (the current API) vs. glmVec2Setf (the proposed) My opinion: glmVecSet2f, it is more OpenGL-like Issues are open for discussion. Please comment. On Mon, Aug 25, 2008 at 10:10 PM, Mars_999 <ma...@si...> wrote: I haven't looked at the lib yet, but aren't we just going to work with floats all the time? glmVec2Sub glmVec3Sub glmVec4Sub glmVec2Add glmVec3Add glmVec4Add glmVec2Mul glmVec2Div glmVec2Norm glmVec2Transf glmVec3Cross glmVec3Dot I like that format... ----- Original Message ----- From: Henri Häkkinen To: glsdk-devel Sent: Monday, August 25, 2008 2:04 PM Subject: [Glsdk-devel] [GLm] api The GLM API seems at this moment to use two sets of naming styles. Compare these two for example: glmVecSub2f glmVecLength2f The first function is using a short form for the operation ('sub' as from 'substract') while the other is using long form. Should we simplify the API to look like this: glmVecSub2f glmVecLen2f Althought on the other hand, how do we shorten such stuff as Normalize, Transform, Identity, Inverse? This does not necessary look good: glmVecNorm glmVecTrans glmMatTrans glmMatInv glmMatIdent Is this even a big issue? Comments? If we decide to keep the API as it is now, I think we should lock it in and begin to outline the API reference for it. For later versions, I would like to implement such stuff as colors, quaternions and maybe planes and matrix stacks but this can wait. Bigger priority is to get the current version working and tested for. For Korval: I outlined some API ref in a plain text format. You may find it in 'docs/sdk_reference/glm-apiref' in the latest revision. You may use this as ideas for the DocBook API ref and this file needs to get removed once you migrate it into DocBook. -- 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: Branan R. <br...@gm...> - 2008-08-25 20:40:06
|
We can, however, say in plain-text somewhere that our license contains very simmilar terms to the license used by the Khronos group, or some such thing. Get the word in for Google's sake =P Branan On Mon, Aug 25, 2008 at 1:35 PM, Henri Häkkinen <hen...@gm...> wrote: > Khronos license is basically the same as MIT, except it uses the word > 'Material' instead of 'Software' and with Khronos copyright. We can't use > Khronos in the copyright for the obvious reasons (we are not affiliated with > it). > > > On Mon, Aug 25, 2008 at 11:30 PM, Henri Häkkinen <hen...@gm...> wrote: >> >> I have committed changes with the MIT license in each source (perhaps too >> hastly). We can later change it to the Khronos license. >> >> On Mon, Aug 25, 2008 at 10:54 PM, Rick Yorgason <ri...@fi...> wrote: >>> >>> Henri Häkkinen wrote: >>> > Okay good. If anyone else does not have objections or points, can we >>> > conclude we use the MIT license? Someone post a verbatim copy of the >>> > license here so I can include it to my GLM sources, please. >>> >>> Why not the Khronos license? http://glew.sourceforge.net/khronos.txt >>> >>> It's basically just the MIT license, but with a name OpenGL users are >>> familiar with. >>> >>> -Rick- >>> >>> ------------------------------------------------------------------------- >>> 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 >> > > > > -- > 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-25 20:35:13
|
Khronos license is basically the same as MIT, except it uses the word 'Material' instead of 'Software' and with Khronos copyright. We can't use Khronos in the copyright for the obvious reasons (we are not affiliated with it). On Mon, Aug 25, 2008 at 11:30 PM, Henri Häkkinen <hen...@gm...> wrote: > I have committed changes with the MIT license in each source (perhaps too > hastly). We can later change it to the Khronos license. > > > On Mon, Aug 25, 2008 at 10:54 PM, Rick Yorgason <ri...@fi...> wrote: > >> Henri Häkkinen wrote: >> > Okay good. If anyone else does not have objections or points, can we >> > conclude we use the MIT license? Someone post a verbatim copy of the >> > license here so I can include it to my GLM sources, please. >> >> Why not the Khronos license? http://glew.sourceforge.net/khronos.txt >> >> It's basically just the MIT license, but with a name OpenGL users are >> familiar with. >> >> -Rick- >> >> ------------------------------------------------------------------------- >> 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 > > -- Henri 'henux' Häkkinen |