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 01:06:56
|
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? -- Henri 'henux' Häkkinen |
|
From: Andrew G. <and...@gm...> - 2008-08-27 21:18:33
|
> > The current implementation holds that the behavior is undefined if you pass > NULL as function arguments: > > glmMatInverse2f (&foo, NULL); // BOOM If the behavior (in DEBUG mode) is for this function to cause an assertion then that behavior IS in fact defined. If this function is called without assertions enabled then, while the behavior is definitely undefined, it will also likely crash the app (dereferencing null). Differences in behavior between debug and optimized mode can be toxic. I think a lot of the time when developers indicate behavior is "undefined" that the behavior is actually well defined for a particular build but should be relied on as it may change. When I say "build" here I do not mean the difference between a debug and release build. Which would be preferred? Invalid results (a call to MatInverse that seems to do nothing) or an app crash? I realize that I'm just babbling and not offering a solution. I think I would prefer a null or singular matrix to return NULL and not modify *out. That behavior is at least testable with unit testing. The disadvantage is that it may be difficult under normal circumstances to detect the root cause of a bug if a null or singular matrix doesn't cause an instant failure. However this function would not affect the stability of the app. Looking at the #ifndef's in MatInverse2f and 3f (missing in 4f) I see a reliance on assert() in release code. When compiled with NDEBUG the *assert( fabs( det ) < GLM_ERROR_TOLERANCE )* will be absent. Is this this (undefined) behavior what you expect? pudman |
|
From: H. H. <hen...@gm...> - 2008-08-27 20:01:10
|
... and GLM is compiled as a static lib and linked with glmtest.
On Wed, Aug 27, 2008 at 11:00 PM, Henri Häkkinen <hen...@gm...> wrote:
> ATM I am still in the process of writing test cases and correcting minor
> bugs in the GLM. The current implementation holds that the behavior is
> undefined if you pass NULL as function arguments:
>
> glmMatInverse2f (&foo, NULL); // BOOM
>
> I use assert's in the implementation to test this. However CUnit does not
> have a way to override the assert inside the function glmMatInverse2f:
>
> GLMmat2f *
> glmMatInverse2f (GLMmat2f *out, const GLMmat2f *m)
> {
> ...
> assert (out);
> assert (m);
> ...
> }
>
> And there cannot be because assert is usually defined as a macro.
>
> On Wed, Aug 27, 2008 at 8:22 PM, Orhun Birsoy <orh...@gm...>wrote:
>
>> pudman
>> OK, you convinced me for including such cases (asserts) in unit tests.
>> Thanks...
>>
>> One question though, will CUnit be able to override the assert in that
>> function so that the tests can continue?
>>
>> --
>> 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
>>
>>
>
>
> --
> Henri 'henux' Häkkinen
>
>
--
Henri 'henux' Häkkinen |
|
From: H. H. <hen...@gm...> - 2008-08-27 19:59:54
|
ATM I am still in the process of writing test cases and correcting minor
bugs in the GLM. The current implementation holds that the behavior is
undefined if you pass NULL as function arguments:
glmMatInverse2f (&foo, NULL); // BOOM
I use assert's in the implementation to test this. However CUnit does not
have a way to override the assert inside the function glmMatInverse2f:
GLMmat2f *
glmMatInverse2f (GLMmat2f *out, const GLMmat2f *m)
{
...
assert (out);
assert (m);
...
}
And there cannot be because assert is usually defined as a macro.
On Wed, Aug 27, 2008 at 8:22 PM, Orhun Birsoy <orh...@gm...> wrote:
> pudman
> OK, you convinced me for including such cases (asserts) in unit tests.
> Thanks...
>
> One question though, will CUnit be able to override the assert in that
> function so that the tests can continue?
>
> --
> 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
>
>
--
Henri 'henux' Häkkinen |
|
From: Orhun B. <orh...@gm...> - 2008-08-27 17:22:31
|
pudman OK, you convinced me for including such cases (asserts) in unit tests. Thanks... One question though, will CUnit be able to override the assert in that function so that the tests can continue? -- Orhun Birsoy |
|
From: Andrew G. <and...@gm...> - 2008-08-27 17:14:24
|
Re: Is assert a code path? In my opinion "error behavior" qualifies as a code path. If you submit a null to a function and "expect" it to fail assertion then you should be testing for that behavior. I bring it up because yesterday I found a typo in a GLM function which would have been caught if the unit tests tested for error behavior. That said, either test for it (assertions) or don't use them. I think it's perfectly acceptable to say functions will produce undefined results given null input. If that's not acceptable, create some reasonable error behavior *and test for that behavior*. This should be true whether the behavior is an assertion or a "return null and don't modify *out". pudman |
|
From: H. H. <hen...@gm...> - 2008-08-27 17:08:17
|
FAQ updated here: http://glsdk.sourceforge.net/index2.html On Wed, Aug 27, 2008 at 7:45 PM, Henri Häkkinen <hen...@gm...> wrote: > Will do. Also, please proof-read my FAQ until you do the operation. > > > On Wed, Aug 27, 2008 at 7:41 PM, Branan Riley <br...@gm...> wrote: > >> Sorry, I didn't check the default permissions on the sourceforge shell >> server. >> >> I can't fix it until I get home tonight (another 7 hours) >> >> Why don't you copy it and work on a copy, and I'll just delete the old >> one when I can. >> >> Branan >> >> On Wed, Aug 27, 2008 at 8:53 AM, Henri Häkkinen <hen...@gm...> >> wrote: >> > To Branan: >> > >> > You seem to have the ownership of the file /htdocs/index.html and it has >> no >> > g+w flag set. I am not able to edit this file. When you have some time, >> > could you fix this? >> > >> > On Wed, Aug 27, 2008 at 6:24 PM, Henri Häkkinen <hen...@gm...> >> wrote: >> >> >> >> I will be updating the FAQ sometime soon and adding instructions for >> >> people who may want to contribute and get involved... >> >> see >> >> On Tue, Aug 26, 2008 at 5:25 AM, Henri Häkkinen <hen...@gm...> >> >> wrote: >> >>> >> >>> 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 >> >>> >> >> >> >> >> >> >> >> -- >> >> 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 >> > >> > >> >> ------------------------------------------------------------------------- >> 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-27 16:45:04
|
Will do. Also, please proof-read my FAQ until you do the operation. On Wed, Aug 27, 2008 at 7:41 PM, Branan Riley <br...@gm...> wrote: > Sorry, I didn't check the default permissions on the sourceforge shell > server. > > I can't fix it until I get home tonight (another 7 hours) > > Why don't you copy it and work on a copy, and I'll just delete the old > one when I can. > > Branan > > On Wed, Aug 27, 2008 at 8:53 AM, Henri Häkkinen <hen...@gm...> > wrote: > > To Branan: > > > > You seem to have the ownership of the file /htdocs/index.html and it has > no > > g+w flag set. I am not able to edit this file. When you have some time, > > could you fix this? > > > > On Wed, Aug 27, 2008 at 6:24 PM, Henri Häkkinen <hen...@gm...> > wrote: > >> > >> I will be updating the FAQ sometime soon and adding instructions for > >> people who may want to contribute and get involved... > >> see > >> On Tue, Aug 26, 2008 at 5:25 AM, Henri Häkkinen <hen...@gm...> > >> wrote: > >>> > >>> 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 > >>> > >> > >> > >> > >> -- > >> 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 > > > > > > ------------------------------------------------------------------------- > 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-27 16:42:22
|
More on the invert: A generic 4x4 invert matrix routine is not actually even very usable or needed routine. You get better performance by noting on special matrix types. For example, inverse of rotation is negative rotation or transpose of the 3x3 matrix and it is faster to calculate inverse of a perspective projection than inverse of generic 4x4 matrix. The reason I included the MatInverse in the API is that people would always ask us "where is the inverse?". Generic inverse is nice to have and "necessary" but usually it is better to do a specialized inverse. On Wed, Aug 27, 2008 at 7:37 PM, Henri Häkkinen <hen...@gm...> wrote: > Well no it does not but is that assert even necessary in tutorials? > > On Wed, Aug 27, 2008 at 7:00 PM, Orhun Birsoy <orh...@gm...>wrote: > >> Is assert a code path? I think it is not. I mean that`s the whole point, >> the code should have a single path. I always thought unit tests are for >> release (i.e production), so there will be no error behavior (i.e. assert) >> in release builds. If this is a problem then I would suggest to remove the >> assert all together. >> >> More on removing the assert: >> Inverse operation is not something you use when you are a newbie (drawing >> a cube does not require one or at least not in CPU). When you start using >> matrix inverses, a well placed, briefly commented assert(glmMatDeterm4f (m) >> != 0) [or something similar] in a glsdk tutorial will not confuse anybody. >> Or will it? >> >> -- >> 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 >> >> > > > -- > Henri 'henux' Häkkinen > > -- Henri 'henux' Häkkinen |
|
From: Branan R. <br...@gm...> - 2008-08-27 16:41:05
|
Sorry, I didn't check the default permissions on the sourceforge shell server. I can't fix it until I get home tonight (another 7 hours) Why don't you copy it and work on a copy, and I'll just delete the old one when I can. Branan On Wed, Aug 27, 2008 at 8:53 AM, Henri Häkkinen <hen...@gm...> wrote: > To Branan: > > You seem to have the ownership of the file /htdocs/index.html and it has no > g+w flag set. I am not able to edit this file. When you have some time, > could you fix this? > > On Wed, Aug 27, 2008 at 6:24 PM, Henri Häkkinen <hen...@gm...> wrote: >> >> I will be updating the FAQ sometime soon and adding instructions for >> people who may want to contribute and get involved... >> see >> On Tue, Aug 26, 2008 at 5:25 AM, Henri Häkkinen <hen...@gm...> >> wrote: >>> >>> 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 >>> >> >> >> >> -- >> 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-27 16:36:51
|
Well no it does not but is that assert even necessary in tutorials? On Wed, Aug 27, 2008 at 7:00 PM, Orhun Birsoy <orh...@gm...> wrote: > Is assert a code path? I think it is not. I mean that`s the whole point, > the code should have a single path. I always thought unit tests are for > release (i.e production), so there will be no error behavior (i.e. assert) > in release builds. If this is a problem then I would suggest to remove the > assert all together. > > More on removing the assert: > Inverse operation is not something you use when you are a newbie (drawing a > cube does not require one or at least not in CPU). When you start using > matrix inverses, a well placed, briefly commented assert(glmMatDeterm4f (m) > != 0) [or something similar] in a glsdk tutorial will not confuse anybody. > Or will it? > > -- > 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 > > -- Henri 'henux' Häkkinen |
|
From: Orhun B. <orh...@gm...> - 2008-08-27 16:00:23
|
Is assert a code path? I think it is not. I mean that`s the whole point, the code should have a single path. I always thought unit tests are for release (i.e production), so there will be no error behavior (i.e. assert) in release builds. If this is a problem then I would suggest to remove the assert all together. More on removing the assert: Inverse operation is not something you use when you are a newbie (drawing a cube does not require one or at least not in CPU). When you start using matrix inverses, a well placed, briefly commented assert(glmMatDeterm4f (m) != 0) [or something similar] in a glsdk tutorial will not confuse anybody. Or will it? -- Orhun Birsoy |
|
From: H. H. <hen...@gm...> - 2008-08-27 15:53:35
|
To Branan: You seem to have the ownership of the file /htdocs/index.html and it has no g+w flag set. I am not able to edit this file. When you have some time, could you fix this? On Wed, Aug 27, 2008 at 6:24 PM, Henri Häkkinen <hen...@gm...> wrote: > I will be updating the FAQ sometime soon and adding instructions for people > who may want to contribute and get involved... > > see > On Tue, Aug 26, 2008 at 5:25 AM, Henri Häkkinen <hen...@gm...>wrote: > >> 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 >> >> > > > -- > Henri 'henux' Häkkinen > > -- Henri 'henux' Häkkinen |
|
From: H. H. <hen...@gm...> - 2008-08-27 15:24:37
|
I will be updating the FAQ sometime soon and adding instructions for people who may want to contribute and get involved... On Tue, Aug 26, 2008 at 5:25 AM, Henri Häkkinen <hen...@gm...> wrote: > 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 > > -- Henri 'henux' Häkkinen |
|
From: Andrew G. <and...@gm...> - 2008-08-27 15:18:35
|
A note about unit testing: If you are going to provide error behavior (in
this case 'assert()') you should provide test cases that verify correct
error behavior ("test all code paths").
pudman
On Wed, Aug 27, 2008 at 11:14 AM, Henri Häkkinen <hen...@gm...> wrote:
> Yes. I think this is a good point. We do an assert check in debug version,
> but otherwise continue. I vote for this.
>
> On Tue, Aug 26, 2008 at 11:36 PM, Orhun Birsoy <orh...@gm...>wrote:
>
>> I'll ask a question from a completely different view. Note that I am not
>> excatly proposing this, I am just mentioning it so that we can discuss...
>>
>> Do we need to check for a tolerance? In debug, we can do whatever we want
>> (i.e. assert etc) but for release I don't believe we have to check anything.
>> Just continue the calculations as if nothing happened.
>>
>> What happens when you load a singular matrix to OpenGL with
>> glLoadMatrix(or glMultMatrix)? Spec mentions singular matrices several times
>> and it basically says the results are undefined.
>>
>> From OpenGL Spec 3.0 page 58
>> If the GL implementation determines that the modelview
>> matrix is uninvertible, then the entries in the inverted matrix are
>> arbitrary. In
>> any case, neither normal transformation nor use of the transformed normal
>> may
>> lead to GL interruption or termination.
>>
>> Why should glmMatInverse be any different? Such low level functions should
>> not have such checks (or such behaviours defined). Higher level code should
>> check whether the matrices they generate are well conditioned.
>>
>> <semiserious>
>> We can always provide "safe" versions, which will have more defined
>> behaviours. glmMatInverse4f_s anyone?
>> </semiserious>
>>
>> --
>> 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
>>
>>
>
>
> --
> 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-27 15:14:14
|
Yes. I think this is a good point. We do an assert check in debug version, but otherwise continue. I vote for this. On Tue, Aug 26, 2008 at 11:36 PM, Orhun Birsoy <orh...@gm...>wrote: > I'll ask a question from a completely different view. Note that I am not > excatly proposing this, I am just mentioning it so that we can discuss... > > Do we need to check for a tolerance? In debug, we can do whatever we want > (i.e. assert etc) but for release I don't believe we have to check anything. > Just continue the calculations as if nothing happened. > > What happens when you load a singular matrix to OpenGL with glLoadMatrix(or > glMultMatrix)? Spec mentions singular matrices several times and it > basically says the results are undefined. > > From OpenGL Spec 3.0 page 58 > If the GL implementation determines that the modelview > matrix is uninvertible, then the entries in the inverted matrix are > arbitrary. In > any case, neither normal transformation nor use of the transformed normal > may > lead to GL interruption or termination. > > Why should glmMatInverse be any different? Such low level functions should > not have such checks (or such behaviours defined). Higher level code should > check whether the matrices they generate are well conditioned. > > <semiserious> > We can always provide "safe" versions, which will have more defined > behaviours. glmMatInverse4f_s anyone? > </semiserious> > > -- > 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 > > -- Henri 'henux' Häkkinen |
|
From: Orhun B. <orh...@gm...> - 2008-08-26 20:35:56
|
I'll ask a question from a completely different view. Note that I am not excatly proposing this, I am just mentioning it so that we can discuss... Do we need to check for a tolerance? In debug, we can do whatever we want (i.e. assert etc) but for release I don't believe we have to check anything. Just continue the calculations as if nothing happened. What happens when you load a singular matrix to OpenGL with glLoadMatrix(or glMultMatrix)? Spec mentions singular matrices several times and it basically says the results are undefined. >From OpenGL Spec 3.0 page 58 If the GL implementation determines that the modelview matrix is uninvertible, then the entries in the inverted matrix are arbitrary. In any case, neither normal transformation nor use of the transformed normal may lead to GL interruption or termination. Why should glmMatInverse be any different? Such low level functions should not have such checks (or such behaviours defined). Higher level code should check whether the matrices they generate are well conditioned. <semiserious> We can always provide "safe" versions, which will have more defined behaviours. glmMatInverse4f_s anyone? </semiserious> -- Orhun Birsoy |
|
From: H. H. <hen...@gm...> - 2008-08-26 19:28:32
|
The current implementation of glmMatInverse2f is defined thus:
GLMmat2f *
glmMatInverse2f (GLMmat2f *out, const GLMmat2f *m)
{
GLfloat m00, m01, m10, m11;
GLfloat inv_det;
assert (out);
assert (m);
inv_det = 1.0f / glmMatDeterm2f (m);
m00 = m->m00;
m01 = m->m01;
m10 = m->m10;
m11 = m->m11;
out->m00 = m11 * inv_det;
out->m01 = - m01 * inv_det;
out->m10 = - m10 * inv_det;
out->m11 = m00 * inv_det;
return out;
}
(with similar implementations for GLMmat3f and GLMmat4f)
The problem here is that the implementation is incomplete and contains a
bug. Consider the case when determinant is 0. For matrices that have det ==
0 inverses are non-existing. Therefore we will need to include a test to
check whether that is the case:
det = glmMatDeterm2f (m);
if (fabs (det) < error_tolerance)
...
Now two issues arise:
1) What should be the value of error_tolerance? Should we set it up as a
constant or something that the caller provides?
My thoughts: we should set it up as a constant as we want to keep thing
simple. I propose the value of 0.0005
2) What should the routine do if det == 0? Return NULL or do we just do
assertion failure?
My thoughts: we should return NULL and the out matrix is unaffected
--
Henri 'henux' Häkkinen |
|
From: H. H. <hen...@gm...> - 2008-08-26 19:19:42
|
We can do this at some revision. This is no big deal nor a matter of importance. On Tue, Aug 26, 2008 at 5:44 PM, Branan Riley <br...@gm...> wrote: > 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 > > > > > > ------------------------------------------------------------------------- > 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 18:27:18
|
Thanks. That is absolutely true. I would have missed that without your post. Will be fixed in the next commit. On Tue, Aug 26, 2008 at 9:24 PM, Andrew Gajda <and...@gm...>wrote: > Just glancing at GLM src and noticed in glmMatDeterm4f that assert(m) > should be assert(m_). > > pudman > > > On Tue, Aug 26, 2008 at 10:24 AM, Henri Häkkinen <hen...@gm...>wrote: > >> 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 >> >> >> ------------------------------------------------------------------------- >> 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: Jason M. <ko...@gm...> - 2008-08-26 18:24:54
|
Actually, that reminds me (I generated that list basically off the cuff). Rather than a "my first cube", we should do a whole tutorial on the different kinds of primitives: triangle strips, lists, fans, etc. Also, we should have a tutorial on map buffer (specifically map buffer range, once conformant drivers are more prevelant), for dealing with dynamic geometry. This would probably be after Transform&Camera, but before normals and per-vertex lighting. On Tue, Aug 26, 2008 at 11:11 AM, Andrew Gajda <and...@gm...> wrote: > I would insert either after #1 or after #2: > My first cube: Hello 3D world! > > It's the perfect lead-in to camera/perspective/normals but (slightly) more > complicated than a single triangle. Might be good to note when the GLShape > library starts to be used. Right after getting a triangle displayed? Once > texture mapping is involved? Maybe the cube tutorial explains what's > involved in a cube (beyond the triangle tutorial) then shows the beginner > how to do the same thing using the GLShape library. > > pudman > > On Tue, Aug 26, 2008 at 1:59 PM, Jason McKesson <ko...@gm...> wrote: >> >> To me, the most important thing about tutorials is this: they're tools >> for teaching. Which means that they need to be laid out in a specific >> order (increasing complexity) and with specific intents in mind. Which >> means that for the initial tutorials, we should sit down and decide >> what the initial tutorials ought to be. We don't necessarily have to >> write them ourselves, but we should define what their topics are. >> >> I was thinking something on the order of this: >> >> 1: My first triangle: Hello-world for graphics. >> 2: Transformation and Camera >> 3: Normals and Per-vertex lighting >> 4: Per-fragment lighting >> 5: Texture mapping >> 6: Framebuffer blending >> 7: Point-sprites >> 8: Render-to-texture >> 9: Depth, order, and blending: Introducing the depth buffer and >> dealing with alpha blending with lots of objects. >> >> The idea being that each tutorial builds on the other, introducing new >> complexity to the previous one. |
|
From: Andrew G. <and...@gm...> - 2008-08-26 18:24:50
|
Just glancing at GLM src and noticed in glmMatDeterm4f that assert(m) should be assert(m_). pudman On Tue, Aug 26, 2008 at 10:24 AM, Henri Häkkinen <hen...@gm...> wrote: > 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 > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Glsdk-devel mailing list > Gls...@li... > https://lists.sourceforge.net/lists/listinfo/glsdk-devel > > |
|
From: Andrew G. <and...@gm...> - 2008-08-26 18:11:32
|
I would insert either after #1 or after #2:
My first cube: Hello 3D world!
It's the perfect lead-in to camera/perspective/normals but (slightly) more
complicated than a single triangle. Might be good to note when the GLShape
library starts to be used. Right after getting a triangle displayed? Once
texture mapping is involved? Maybe the cube tutorial explains what's
involved in a cube (beyond the triangle tutorial) then shows the beginner
how to do the same thing using the GLShape library.
pudman
On Tue, Aug 26, 2008 at 1:59 PM, Jason McKesson <ko...@gm...> wrote:
> To me, the most important thing about tutorials is this: they're tools
> for teaching. Which means that they need to be laid out in a specific
> order (increasing complexity) and with specific intents in mind. Which
> means that for the initial tutorials, we should sit down and decide
> what the initial tutorials ought to be. We don't necessarily have to
> write them ourselves, but we should define what their topics are.
>
> I was thinking something on the order of this:
>
> 1: My first triangle: Hello-world for graphics.
> 2: Transformation and Camera
> 3: Normals and Per-vertex lighting
> 4: Per-fragment lighting
> 5: Texture mapping
> 6: Framebuffer blending
> 7: Point-sprites
> 8: Render-to-texture
> 9: Depth, order, and blending: Introducing the depth buffer and
> dealing with alpha blending with lots of objects.
>
> The idea being that each tutorial builds on the other, introducing new
> complexity to the previous one.
>
> On Tue, Aug 26, 2008 at 8:53 AM, Henri Häkkinen <hen...@gm...>
> wrote:
> > Maybe. There is no need to have them opengl_ prefix and the functions
> should
> > be declared static.
> >
> > On Tue, Aug 26, 2008 at 5:49 PM, Branan Riley <br...@gm...> wrote:
> >>
> >> 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
> >> >
> >> >
> >>
> >>
> -------------------------------------------------------------------------
> >> 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: Jason M. <ko...@gm...> - 2008-08-26 17:59:31
|
To me, the most important thing about tutorials is this: they're tools
for teaching. Which means that they need to be laid out in a specific
order (increasing complexity) and with specific intents in mind. Which
means that for the initial tutorials, we should sit down and decide
what the initial tutorials ought to be. We don't necessarily have to
write them ourselves, but we should define what their topics are.
I was thinking something on the order of this:
1: My first triangle: Hello-world for graphics.
2: Transformation and Camera
3: Normals and Per-vertex lighting
4: Per-fragment lighting
5: Texture mapping
6: Framebuffer blending
7: Point-sprites
8: Render-to-texture
9: Depth, order, and blending: Introducing the depth buffer and
dealing with alpha blending with lots of objects.
The idea being that each tutorial builds on the other, introducing new
complexity to the previous one.
On Tue, Aug 26, 2008 at 8:53 AM, Henri Häkkinen <hen...@gm...> wrote:
> Maybe. There is no need to have them opengl_ prefix and the functions should
> be declared static.
>
> On Tue, Aug 26, 2008 at 5:49 PM, Branan Riley <br...@gm...> wrote:
>>
>> 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
>> >
>> >
>>
>> -------------------------------------------------------------------------
>> 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 15:53:46
|
Maybe. There is no need to have them opengl_ prefix and the functions should
be declared static.
On Tue, Aug 26, 2008 at 5:49 PM, Branan Riley <br...@gm...> wrote:
> 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
> >
> >
>
> -------------------------------------------------------------------------
> 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 |
1 message has been excluded from this view by a project administrator.
