glsdk-devel — Main development list for the OpenGL SDK

Re: [Glsdk-devel] [GLM] open questions with the matrix api

[H. H. <hen...@gm...>]

Good.

I will be making the changes in the upcoming commits, and updating the test
cases for them.

I have also added some explaining comments for the matrix layouts in my last
commit:

typedef struct {
  union {
    /* Matrix layout:
       | data[0] data[2] |
       | data[1] data[3] |
    */
    GLfloat data[4];
    struct {
      /* Matrix layout:
         | m00 m01 |
         | m10 m11 |
      */
      GLfloat m00, m10, m01, m11;
    };
  };
} GLMmat2f;

All this will of course need to go to the GLM API documentation also, in
time.


On Sun, Aug 24, 2008 at 10:50 PM, Jason McKesson <ko...@gm...> wrote:

> Henri Häkkinen wrote:
> > Another open issues has came up:
> >
> > Do you think we should allow something like this:
> >
> > glmMatInverse2f (&mat, &mat);
> > glmMatTranspose2f (&mat, &mat);
> > glmVecAdd2f (&vec, &vec, &vec);
> >
> > For some functions, this add some additional processing since it needs
> > to store temporary values of matrix members before performing an
> > operation, such as:
> >
> > ...
> >
> > My proposal is that we allow glmMatInverse2f (&mat, &mat) and live
> > with the additional overhead. -Self funcs may still be included for
> > convenience (at some later GLM versions).
> Agreed. It adheres to the principle of least surprise. The less-careful
> user will expect to be able to pass the same parameter, or outputs as
> inputs, and we should allow it.
>
> -------------------------------------------------------------------------
> 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

Re: [Glsdk-devel] [GLM] open questions with the matrix api

[Jason M. <ko...@gm...>]

Henri Häkkinen wrote:
> Another open issues has came up:
>
> Do you think we should allow something like this:
>
> glmMatInverse2f (&mat, &mat);
> glmMatTranspose2f (&mat, &mat);
> glmVecAdd2f (&vec, &vec, &vec);
>
> For some functions, this add some additional processing since it needs 
> to store temporary values of matrix members before performing an 
> operation, such as:
>
> ...
>
> My proposal is that we allow glmMatInverse2f (&mat, &mat) and live 
> with the additional overhead. -Self funcs may still be included for 
> convenience (at some later GLM versions).
Agreed. It adheres to the principle of least surprise. The less-careful 
user will expect to be able to pass the same parameter, or outputs as 
inputs, and we should allow it.

Re: [Glsdk-devel] [GLM] open questions with the matrix api

[H. H. <hen...@gm...>]

Another open issues has came up:

Do you think we should allow something like this:

glmMatInverse2f (&mat, &mat);
glmMatTranspose2f (&mat, &mat);
glmVecAdd2f (&vec, &vec, &vec);

For some functions, this add some additional processing since it needs to
store temporary values of matrix members before performing an operation,
such as:

GLMmat2f *
glmMatInverse2f (GLMmat2f *out, const GLMmat2f *m)
{
  GLfloat m00, m01, m10, m11;
  GLfloat inv_det;

  assert (out);
  assert (m);

  inv_det = 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;
}

We could allows this for simplicity or we could provide additional
entry-points such as:

glmMatInverseSelf2f (&mat);
glmVecAddSelf2f (&vec1, &vec2); // vec1 += vec2

// not allowed and undefined:
glmMatInverse2f (&mat, &mat);
...


My proposal is that we allow glmMatInverse2f (&mat, &mat) and live with the
additional overhead. -Self funcs may still be included for convenience (at
some later GLM versions).


On Sun, Aug 24, 2008 at 9:32 PM, Henri Häkkinen <hen...@gm...> wrote:

> Actually, yes, you are absolutely correct. So
>
>   glmMatSet3f (&mat, &a, &b, &c);
>
> should construct
>
>   | a.x b.x c.x |
>   | a.y b.y c.y |
>   | a.z b.z c.z |
>
> Got it!
>
>
>
> On Sun, Aug 24, 2008 at 8:47 PM, Branan Riley <br...@gm...> wrote:
>
>> I believe OpenGL defines a matrix constructed from vectors like this:
>> | a.x b.x c.x |
>> | a.y b.y c.y |
>> | a.z b.z c.z |
>>
>> We should do the same for consistency.
>>
>> Branan
>>
>> On Sun, Aug 24, 2008 at 9:27 AM, Henri Häkkinen <hen...@gm...>
>> wrote:
>> > There are some open questions in the mathlib's matrix api and I would
>> like
>> > to hear your opinions.
>> >
>> > Do the matrices need member-wise constructors? For example, do we need
>> > something like this:
>> >
>> > GLMmat2f mat;
>> > glmMatSet2f (&mat, 1.0f, 2.0f, 3.0f, 4.0f);
>> >
>> > I suppose the user never needs to do anything like this, instead they
>> use th
>> > higher level entry-point such as Identity and Rotate.
>> >
>> > However, there might be a need for constructing matrices from vectors.
>> >
>> > GLMvec3f a, b, c;
>> > GLMmat3f mat;
>> > glmMatSet3f (&mat, &a, &b, &c);
>> >
>> > At the moment, I have these entry-points and the matrices are
>> constructed
>> > 'column-wise'. For example, the previous code creates this kind of
>> matrix:
>> >
>> > | a.x a.y a.z |
>> > | b.x b.y b.z |
>> > | c.x c.y c.z |
>> >
>> > Should the matrices be build row-wise instead? There is an advantage in
>> > this, as matrix rows define the coordinate axes in a 3D coordinate
>> space.
>> > However, OpenGL defines the matrix memory layout as column-wise, so I
>> guess
>> > it is a kind of more logical to build them column-wise from the vectors.
>> >
>> > --
>> > 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

Re: [Glsdk-devel] util. lib brainstorming

[H. H. <hen...@gm...>]

I think having a simple menu bar would also be beneficial for the demos, as
you could change some of the demo parameters from that interface. Such as,
back face culling, front face winding etc. This is open for a debate.

On Sun, Aug 24, 2008 at 9:22 PM, Jason McKesson <ko...@gm...> wrote:

> Henri Häkkinen wrote:
> > Here are some general ideas for GLSDK utility libraries.
> >
> > What libraries do we need?
> >
> > - OpenGL Math Library (GLM, nicknamed 'mathlib') for 3d math, under
> > development by me...
> >
> > - OpenGL Shape Library (GLS, nicknamed 'shapelib') for basic 3d
> > geometry drawing and perhaps model loading, under development by
> branan...
> >
> > - OpenGL Extension Library (GLE, nicknamed 'extlib') for GL3 context
> > creation and API loading, under development by korval...
> >
> > - texture loading? I know two libraries for this; developer's image
> > library (devil) and freeimage.
> >
> > FreeImage is a C library, but does not have OpenGL look & feel
> > DevIL is a C library too and has somewhat OpenGL look & feel
> I tried to use DevIL once, but I was unable to make it work. Also, until
> litterally yesterday, DevIL hadn't had a release in 2 years. FreeImage
> seems much more in development.
> >
> > I am thinking that we might also want to develop imagelib of our own,
> > which would just contain entry points that just simple load an image
> > from a file and return it as GL texture:
> >
> > // load image and return it as texture
> > GLuint gltLoadTexture (const char *filename);
> >
> > // load image, convert it to the given format and return as texture
> > GLuint gltLoadTexture2 (const char *filename, GLenum format);
> >
> > // load from a buffer
> > GLuint gltLoadBuf (const GLvoid *buf, GLsizei size);
> These loading functions are convenience functions, after all. Whether we
> internally use FreeImage, DevIL, or libpng directly is not something
> that should be exposed to the user. That's an implementation detail, and
> so it should be hidden from the user.
> >
> > (the entry point names are debatable) DevIL has some nasties; it does
> > not return textures directly etc.
> >
> > - windowing system abstraction? Candidates; GLUT and GLFW. we could
> > also choose to implement our own windowlib that woudl integrate into
> > our GLE. This library would have features for opening windows,
> > creating simple menu bars, input processing etc.
> Creating a window with an OpenGL context is the limit of what we should
> provide.
>
> Now, that being said, there is something to be said for being able to
> handle input to some degree. This is mostly for examples and demos, so
> it can wait.
>
>
> -------------------------------------------------------------------------
> 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

Re: [Glsdk-devel] [GLM] open questions with the matrix api

[H. H. <hen...@gm...>]

Actually, yes, you are absolutely correct. So

  glmMatSet3f (&mat, &a, &b, &c);

should construct

  | a.x b.x c.x |
  | a.y b.y c.y |
  | a.z b.z c.z |

Got it!


On Sun, Aug 24, 2008 at 8:47 PM, Branan Riley <br...@gm...> wrote:

> I believe OpenGL defines a matrix constructed from vectors like this:
> | a.x b.x c.x |
> | a.y b.y c.y |
> | a.z b.z c.z |
>
> We should do the same for consistency.
>
> Branan
>
> On Sun, Aug 24, 2008 at 9:27 AM, Henri Häkkinen <hen...@gm...>
> wrote:
> > There are some open questions in the mathlib's matrix api and I would
> like
> > to hear your opinions.
> >
> > Do the matrices need member-wise constructors? For example, do we need
> > something like this:
> >
> > GLMmat2f mat;
> > glmMatSet2f (&mat, 1.0f, 2.0f, 3.0f, 4.0f);
> >
> > I suppose the user never needs to do anything like this, instead they use
> th
> > higher level entry-point such as Identity and Rotate.
> >
> > However, there might be a need for constructing matrices from vectors.
> >
> > GLMvec3f a, b, c;
> > GLMmat3f mat;
> > glmMatSet3f (&mat, &a, &b, &c);
> >
> > At the moment, I have these entry-points and the matrices are constructed
> > 'column-wise'. For example, the previous code creates this kind of
> matrix:
> >
> > | a.x a.y a.z |
> > | b.x b.y b.z |
> > | c.x c.y c.z |
> >
> > Should the matrices be build row-wise instead? There is an advantage in
> > this, as matrix rows define the coordinate axes in a 3D coordinate space.
> > However, OpenGL defines the matrix memory layout as column-wise, so I
> guess
> > it is a kind of more logical to build them column-wise from the vectors.
> >
> > --
> > 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

Re: [Glsdk-devel] The use of anonymous structures

[Jason M. <ko...@gm...>]

Stefanos A. wrote:
> On Sun, Aug 24, 2008 at 6:31 AM, Branan Riley <br...@gm...> wrote:
>   
>>         Could be a different version of MSVC giving different
>>         warnings.
>>     
>
> Actually no, just stricter warnings (warning level 4, where the default
> is 3). GCC doesn't produce any warnings even with -Wall.
>
> However, please note that the anonymous union is *not* valid C89 (fails
> to compile with "gcc -ansi"). I'm not saying this is a problem (//-style
> comments aren't valid C89 either), just something to keep in mind and
> document.
>
> // Not valid C89
> union
> {
>     float data[2];
>     struct { float x, y; };
> };
>
> /* Valid C89 */
> union foo_union
> {
>     float data[2];
>     struct bar_struct { float x, y; } bar;
> } foo;
>
> Anyone knows if these have been standardized in C99?
>   
Hmm, I did a test with VC7.1, and he's right: on warning level 4, it 
does produce a warning. Even when compiled as C++, it produces a warning.

So this kind of anonymous structure is widely supported but invalid C89 
behavior. I suppose you could pragma around it.

Re: [Glsdk-devel] util. lib brainstorming

[Jason M. <ko...@gm...>]

Henri Häkkinen wrote:
> Here are some general ideas for GLSDK utility libraries.
>
> What libraries do we need?
>
> - OpenGL Math Library (GLM, nicknamed 'mathlib') for 3d math, under 
> development by me...
>
> - OpenGL Shape Library (GLS, nicknamed 'shapelib') for basic 3d 
> geometry drawing and perhaps model loading, under development by branan...
>
> - OpenGL Extension Library (GLE, nicknamed 'extlib') for GL3 context 
> creation and API loading, under development by korval...
>
> - texture loading? I know two libraries for this; developer's image 
> library (devil) and freeimage.
>
> FreeImage is a C library, but does not have OpenGL look & feel
> DevIL is a C library too and has somewhat OpenGL look & feel
I tried to use DevIL once, but I was unable to make it work. Also, until 
litterally yesterday, DevIL hadn't had a release in 2 years. FreeImage 
seems much more in development.
>
> I am thinking that we might also want to develop imagelib of our own, 
> which would just contain entry points that just simple load an image 
> from a file and return it as GL texture:
>
> // load image and return it as texture
> GLuint gltLoadTexture (const char *filename);
>
> // load image, convert it to the given format and return as texture
> GLuint gltLoadTexture2 (const char *filename, GLenum format);
>
> // load from a buffer
> GLuint gltLoadBuf (const GLvoid *buf, GLsizei size);
These loading functions are convenience functions, after all. Whether we 
internally use FreeImage, DevIL, or libpng directly is not something 
that should be exposed to the user. That's an implementation detail, and 
so it should be hidden from the user.
>
> (the entry point names are debatable) DevIL has some nasties; it does 
> not return textures directly etc.
>
> - windowing system abstraction? Candidates; GLUT and GLFW. we could 
> also choose to implement our own windowlib that woudl integrate into 
> our GLE. This library would have features for opening windows, 
> creating simple menu bars, input processing etc.
Creating a window with an OpenGL context is the limit of what we should 
provide.

Now, that being said, there is something to be said for being able to 
handle input to some degree. This is mostly for examples and demos, so 
it can wait.

Re: [Glsdk-devel] Geometry generation

[Jason M. <ko...@gm...>]

Henri Häkkinen wrote:
>
>     I see your point. At the correct point, we can crack open the shape
>     functions and to show the user what's inside, but there's no need
>     to bog
>     down e.g. a lighting tutorial with vertex uploading.
>
>     On the other hand, having a "standardized" format for communicating
>     vertex attributes to the user could be useful. That way, a future
>     model
>     loader would be able to provide data in the same way as the shape
>     functions do. But that's not really pertinent right now (just
>     expressing
>     an idea oft-discussed at the OpenTK forums).
>
>
> Yes, I see the idea. If we declare the GLSshape struct as open, we can 
> allow third party geometry importers and have the geometry drawn with 
> DrawShape.
However, we could also just provide accessor functions to get at those 
attributes.

The internal structure of GLSshape does not need to be exposed to user 
to be able to provide loading support. If we need to expose the ability 
to create a GLSshape from arbitrary data, we can add a function to do 
that. In short, we do not /need/ to make it a public struct in order to 
provide this functionality.

Re: [Glsdk-devel] [GLM] open questions with the matrix api

[Branan R. <br...@gm...>]

I believe OpenGL defines a matrix constructed from vectors like this:
| a.x b.x c.x |
| a.y b.y c.y |
| a.z b.z c.z |

We should do the same for consistency.

Branan

On Sun, Aug 24, 2008 at 9:27 AM, Henri Häkkinen <hen...@gm...> wrote:
> There are some open questions in the mathlib's matrix api and I would like
> to hear your opinions.
>
> Do the matrices need member-wise constructors? For example, do we need
> something like this:
>
> GLMmat2f mat;
> glmMatSet2f (&mat, 1.0f, 2.0f, 3.0f, 4.0f);
>
> I suppose the user never needs to do anything like this, instead they use th
> higher level entry-point such as Identity and Rotate.
>
> However, there might be a need for constructing matrices from vectors.
>
> GLMvec3f a, b, c;
> GLMmat3f mat;
> glmMatSet3f (&mat, &a, &b, &c);
>
> At the moment, I have these entry-points and the matrices are constructed
> 'column-wise'. For example, the previous code creates this kind of matrix:
>
> | a.x a.y a.z |
> | b.x b.y b.z |
> | c.x c.y c.z |
>
> Should the matrices be build row-wise instead? There is an advantage in
> this, as matrix rows define the coordinate axes in a 3D coordinate space.
> However, OpenGL defines the matrix memory layout as column-wise, so I guess
> it is a kind of more logical to build them column-wise from the vectors.
>
> --
> 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
>
>

Re: [Glsdk-devel] The use of anonymous structures

[H. H. <hen...@gm...>]

That is also what I think too.

On Sun, Aug 24, 2008 at 8:06 PM, Branan Riley <br...@gm...> wrote:

> Sounds good. Having names for the internal types in there makes it
> harder to read, IMHO.
>
> On Sun, Aug 24, 2008 at 9:14 AM, Henri Häkkinen <hen...@gm...>
> wrote:
> > Yes. I hope we have reached a some sort of consensus that struct-unions
> are
> > the way to go. For now, I will define the math types with anonymous
> unions
> > and structures. We can use compiler magic to suppress warnings if need
> be.
> >
> > typedef struct {
> >   union {
> >     GLfloat data[2];
> >     struct {
> >       GLfloat x, y;
> >     };
> >   };
> > } GLMvec2f;
> >
> >
> > On Sun, Aug 24, 2008 at 5:16 PM, Stefanos A. <sta...@gm...>
> wrote:
> >>
> >>
> >> On Sun, Aug 24, 2008 at 6:31 AM, Branan Riley <br...@gm...> wrote:
> >> >         Could be a different version of MSVC giving different
> >> >         warnings.
> >>
> >> Actually no, just stricter warnings (warning level 4, where the default
> >> is 3). GCC doesn't produce any warnings even with -Wall.
> >>
> >> However, please note that the anonymous union is *not* valid C89 (fails
> >> to compile with "gcc -ansi"). I'm not saying this is a problem (//-style
> >> comments aren't valid C89 either), just something to keep in mind and
> >> document.
> >>
> >> // Not valid C89
> >> union
> >> {
> >>    float data[2];
> >>    struct { float x, y; };
> >> };
> >>
> >> /* Valid C89 */
> >> union foo_union
> >> {
> >>    float data[2];
> >>    struct bar_struct { float x, y; } bar;
> >> } foo;
> >>
> >> Anyone knows if these have been standardized in C99?
> >>
> >>
> >>
> -------------------------------------------------------------------------
> >> 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

Re: [Glsdk-devel] The use of anonymous structures

[Branan R. <br...@gm...>]

Sounds good. Having names for the internal types in there makes it
harder to read, IMHO.

On Sun, Aug 24, 2008 at 9:14 AM, Henri Häkkinen <hen...@gm...> wrote:
> Yes. I hope we have reached a some sort of consensus that struct-unions are
> the way to go. For now, I will define the math types with anonymous unions
> and structures. We can use compiler magic to suppress warnings if need be.
>
> typedef struct {
>   union {
>     GLfloat data[2];
>     struct {
>       GLfloat x, y;
>     };
>   };
> } GLMvec2f;
>
>
> On Sun, Aug 24, 2008 at 5:16 PM, Stefanos A. <sta...@gm...> wrote:
>>
>>
>> On Sun, Aug 24, 2008 at 6:31 AM, Branan Riley <br...@gm...> wrote:
>> >         Could be a different version of MSVC giving different
>> >         warnings.
>>
>> Actually no, just stricter warnings (warning level 4, where the default
>> is 3). GCC doesn't produce any warnings even with -Wall.
>>
>> However, please note that the anonymous union is *not* valid C89 (fails
>> to compile with "gcc -ansi"). I'm not saying this is a problem (//-style
>> comments aren't valid C89 either), just something to keep in mind and
>> document.
>>
>> // Not valid C89
>> union
>> {
>>    float data[2];
>>    struct { float x, y; };
>> };
>>
>> /* Valid C89 */
>> union foo_union
>> {
>>    float data[2];
>>    struct bar_struct { float x, y; } bar;
>> } foo;
>>
>> Anyone knows if these have been standardized in C99?
>>
>>
>> -------------------------------------------------------------------------
>> 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
>
>

[Glsdk-devel] [GLM] open questions with the matrix api

[H. H. <hen...@gm...>]

There are some open questions in the mathlib's matrix api and I would like
to hear your opinions.

Do the matrices need member-wise constructors? For example, do we need
something like this:

GLMmat2f mat;
glmMatSet2f (&mat, 1.0f, 2.0f, 3.0f, 4.0f);

I suppose the user never needs to do anything like this, instead they use th
higher level entry-point such as Identity and Rotate.

However, there might be a need for constructing matrices from vectors.

GLMvec3f a, b, c;
GLMmat3f mat;
glmMatSet3f (&mat, &a, &b, &c);

At the moment, I have these entry-points and the matrices are constructed
'column-wise'. For example, the previous code creates this kind of matrix:

| a.x a.y a.z |
| b.x b.y b.z |
| c.x c.y c.z |

Should the matrices be build row-wise instead? There is an advantage in
this, as matrix rows define the coordinate axes in a 3D coordinate space.
However, OpenGL defines the matrix memory layout as column-wise, so I guess
it is a kind of more logical to build them column-wise from the vectors.

-- 
Henri 'henux' Häkkinen

Re: [Glsdk-devel] The use of anonymous structures

[H. H. <hen...@gm...>]

Yes. I hope we have reached a some sort of consensus that struct-unions are
the way to go. For now, I will define the math types with anonymous unions
and structures. We can use compiler magic to suppress warnings if need be.

typedef struct {
  union {
    GLfloat data[2];
    struct {
      GLfloat x, y;
    };
  };
} GLMvec2f;


On Sun, Aug 24, 2008 at 5:16 PM, Stefanos A. <sta...@gm...> wrote:

>
>
> On Sun, Aug 24, 2008 at 6:31 AM, Branan Riley <br...@gm...> wrote:
> >         Could be a different version of MSVC giving different
> >         warnings.
>
> Actually no, just stricter warnings (warning level 4, where the default
> is 3). GCC doesn't produce any warnings even with -Wall.
>
> However, please note that the anonymous union is *not* valid C89 (fails
> to compile with "gcc -ansi"). I'm not saying this is a problem (//-style
> comments aren't valid C89 either), just something to keep in mind and
> document.
>
> // Not valid C89
> union
> {
>    float data[2];
>    struct { float x, y; };
> };
>
> /* Valid C89 */
> union foo_union
> {
>    float data[2];
>    struct bar_struct { float x, y; } bar;
> } foo;
>
> Anyone knows if these have been standardized in C99?
>
>
> -------------------------------------------------------------------------
> 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

Re: [Glsdk-devel] Geometry generation

[H. H. <hen...@gm...>]

On Sun, Aug 24, 2008 at 5:34 PM, Stefanos A. <sta...@gm...> wrote:

> > >>> While it's good to have functions that *generate* this data, is it
> really
> > >>> a good idea to hide the *drawing* part behind a glsDrawShape
> function?
> > >>> Maybe it would be better to simply return these four arrays and
> handle the
> > >>> drawing inside the tutorial?
> > >>>
> > >>> Just trying to understand the focus of the shape functions. What do
> you
> > >>> say?
> > >>>
> > >> Well, the problem with any form of generation of that type is this:
> > >> where are you going to put it? You can't put it into a user-supplied
> > >> buffer object because it might be too big (and having a query for the
> > >> size makes creating them very complex). And if you have it create the
> > >> buffer, how do you communicate the data format to the user?
>
> I see your point. At the correct point, we can crack open the shape
> functions and to show the user what's inside, but there's no need to bog
> down e.g. a lighting tutorial with vertex uploading.
>
> On the other hand, having a "standardized" format for communicating
> vertex attributes to the user could be useful. That way, a future model
> loader would be able to provide data in the same way as the shape
> functions do. But that's not really pertinent right now (just expressing
> an idea oft-discussed at the OpenTK forums).
>
>
Yes, I see the idea. If we declare the GLSshape struct as open, we can allow
third party geometry importers and have the geometry drawn with DrawShape.



>
> -------------------------------------------------------------------------
> 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

[Glsdk-devel] GLSDK packaging

[H. H. <hen...@gm...>]

Some thoughts about GLSDK packaging:

- on Windows; we could distribute GLSDK as .zipped source package and a .msi
installer

- on Linux; as a source tarballs and debian packages

- on Mac OSX: ???

We could split the GLSDK into parts, like this:

- glsdk: the complete SDK, but without dev headers and dev docs
- glsdk-dev: development libraries and headers
- glsdk-doc: development documentation

Also, we could offer an opportunity for the user to just download our libs
as a separate packages:

- glsdk-glm
- glsdk-glm-dev
- glsdk-glm-doc
- glsdk-gls
- glsdk-gls-dev
- glsdk-gls-doc
...

In this way, we allow our libraries to be used in hobby games, demos etc.

Also, should we implement version numbering separate for the libs or just
one version number for the complete SDK?


-- 
Henri 'henux' Häkkinen

[Glsdk-devel] util. lib brainstorming

[H. H. <hen...@gm...>]

Here are some general ideas for GLSDK utility libraries.

What libraries do we need?

- OpenGL Math Library (GLM, nicknamed 'mathlib') for 3d math, under
development by me...

- OpenGL Shape Library (GLS, nicknamed 'shapelib') for basic 3d geometry
drawing and perhaps model loading, under development by branan...

- OpenGL Extension Library (GLE, nicknamed 'extlib') for GL3 context
creation and API loading, under development by korval...

- texture loading? I know two libraries for this; developer's image library
(devil) and freeimage.

FreeImage is a C library, but does not have OpenGL look & feel
DevIL is a C library too and has somewhat OpenGL look & feel

I am thinking that we might also want to develop imagelib of our own, which
would just contain entry points that just simple load an image from a file
and return it as GL texture:

// load image and return it as texture
GLuint gltLoadTexture (const char *filename);

// load image, convert it to the given format and return as texture
GLuint gltLoadTexture2 (const char *filename, GLenum format);

// load from a buffer
GLuint gltLoadBuf (const GLvoid *buf, GLsizei size);

(the entry point names are debatable) DevIL has some nasties; it does not
return textures directly etc.

- windowing system abstraction? Candidates; GLUT and GLFW. we could also
choose to implement our own windowlib that woudl integrate into our GLE.
This library would have features for opening windows, creating simple menu
bars, input processing etc.

- anything else?



-- 
Henri 'henux' Häkkinen

Re: [Glsdk-devel] Geometry generation

[Stefanos A. <sta...@gm...>]

> >>> While it's good to have functions that *generate* this data, is it really
> >>> a good idea to hide the *drawing* part behind a glsDrawShape function?
> >>> Maybe it would be better to simply return these four arrays and handle the
> >>> drawing inside the tutorial?
> >>>
> >>> Just trying to understand the focus of the shape functions. What do you
> >>> say?
> >>>
> >> Well, the problem with any form of generation of that type is this:
> >> where are you going to put it? You can't put it into a user-supplied
> >> buffer object because it might be too big (and having a query for the
> >> size makes creating them very complex). And if you have it create the
> >> buffer, how do you communicate the data format to the user?

I see your point. At the correct point, we can crack open the shape
functions and to show the user what's inside, but there's no need to bog
down e.g. a lighting tutorial with vertex uploading. 

On the other hand, having a "standardized" format for communicating
vertex attributes to the user could be useful. That way, a future model
loader would be able to provide data in the same way as the shape
functions do. But that's not really pertinent right now (just expressing
an idea oft-discussed at the OpenTK forums).

Re: [Glsdk-devel] The use of anonymous structures

[Stefanos A. <sta...@gm...>]

On Sun, Aug 24, 2008 at 6:31 AM, Branan Riley <br...@gm...> wrote:
>         Could be a different version of MSVC giving different
>         warnings.

Actually no, just stricter warnings (warning level 4, where the default
is 3). GCC doesn't produce any warnings even with -Wall.

However, please note that the anonymous union is *not* valid C89 (fails
to compile with "gcc -ansi"). I'm not saying this is a problem (//-style
comments aren't valid C89 either), just something to keep in mind and
document.

// Not valid C89
union
{
    float data[2];
    struct { float x, y; };
};

/* Valid C89 */
union foo_union
{
    float data[2];
    struct bar_struct { float x, y; } bar;
} foo;

Anyone knows if these have been standardized in C99?

Re: [Glsdk-devel] SourceForge permissions

[H. H. <hen...@gm...>]

Well, I am obviously a developer.

On Sun, Aug 24, 2008 at 3:14 AM, Branan Riley <br...@gm...> wrote:

> One more thing: What do you intend to do in the project. Just give me
> a plain-text description, and I'll pick the best match from the
> SourceForge "Role" options. It's not really important (it doesn't
> affect any permissions), but it's an easy reference of who to bug for
> what.
>
> Thanks,
> 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

Re: [Glsdk-devel] The use of anonymous structures

[H. H. <hen...@gm...>]

I think we should just use #pragma disable warning for those.

On Sun, Aug 24, 2008 at 6:31 AM, Branan Riley <br...@gm...> wrote:

> Could be a different version of MSVC giving different warnings.
>
> On Sat, Aug 23, 2008 at 8:25 PM, Henri Häkkinen <hen...@gm...>
> wrote:
> > Right :)
> >
> > Hmm, someone reported that MSVC was giving warnings from anonymous
> > structs... Odd
> >
> >
> > On Sun, Aug 24, 2008 at 6:22 AM, Jason McKesson <ko...@gm...>
> wrote:
> >>
> >> Henri Häkkinen wrote:
> >> > Indeed. At the moment, I don't have an access to a Windows box, but
> >> > could somebody who has, kindly test out the possibility of this.
> >> >
> >> > Does the MSVC produce warnings, when you try to compile something like
> >> > this:
> >> >
> >> > typedef struct FOO_s {
> >> >   union {
> >> >     struct {
> >> >       int di;
> >> >     };
> >> >     in do;
> >> >   };
> >> > } FOO;
> >> >
> >> > int main()
> >> > {
> >> >   FOO f;
> >> >   f.di = 1;
> >> >   f.do = 2;
> >> >   return 0;
> >> > }
> >> No, but I can't imagine GCC does. That's because "do" is a C keyword ;)
> >>
> >> When you change it to be a regular identifier, it compiles fine. I even
> >> switched the order of the struct and the int, and it still works.
> >>
> >>
> -------------------------------------------------------------------------
> >> 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

Re: [Glsdk-devel] The use of anonymous structures

[Branan R. <br...@gm...>]

Could be a different version of MSVC giving different warnings.

On Sat, Aug 23, 2008 at 8:25 PM, Henri Häkkinen <hen...@gm...> wrote:
> Right :)
>
> Hmm, someone reported that MSVC was giving warnings from anonymous
> structs... Odd
>
>
> On Sun, Aug 24, 2008 at 6:22 AM, Jason McKesson <ko...@gm...> wrote:
>>
>> Henri Häkkinen wrote:
>> > Indeed. At the moment, I don't have an access to a Windows box, but
>> > could somebody who has, kindly test out the possibility of this.
>> >
>> > Does the MSVC produce warnings, when you try to compile something like
>> > this:
>> >
>> > typedef struct FOO_s {
>> >   union {
>> >     struct {
>> >       int di;
>> >     };
>> >     in do;
>> >   };
>> > } FOO;
>> >
>> > int main()
>> > {
>> >   FOO f;
>> >   f.di = 1;
>> >   f.do = 2;
>> >   return 0;
>> > }
>> No, but I can't imagine GCC does. That's because "do" is a C keyword ;)
>>
>> When you change it to be a regular identifier, it compiles fine. I even
>> switched the order of the struct and the int, and it still works.
>>
>> -------------------------------------------------------------------------
>> 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
>
>

Re: [Glsdk-devel] Geometry generation

[Branan R. <br...@gm...>]

Just realized I forgot something in my last message:

While I like the opaque data structure, I don't like the long names.
They might be slightly more clear, but they're longer and slightly
harder to type, and I just don't like them. For now, it's 2-1 for the
short names, and I say we end the discussion on them unless someone
else chimes in and messes up the vote. Agreed?

Branan

On Sat, Aug 23, 2008 at 8:14 PM, Branan Riley <br...@gm...> wrote:
> I have to agree with Jason on this one. If the user wants custom
> geometry, they need to learn how to deal with drawing it. For the sake
> of tutorials, we just need objects to show off transformations and
> shaders with. An opaque format reduces the risk of abuse not only by
> newbies, but also by people coding SDK examples.
>
> One thing that does need to be clear is how vertex attributes map to
> the arrays generated by the shape function. Something like:
>
> Attrib 0 is the position (vec4)
> Attrib 1 is the normal (vec3)
> Attrib 2 is the texcoord (vec2)
>
> That way shaders can always get the correct variables. I think I'll
> add preprocessor defines for this - GLS_POSITION_ATTRIBUTE,
> GLS_NORMAL_ATTRIBUTE, and GLS_TEXCOORD_ATTRIBUTE, so that there are no
> magic numbers floating around.
>
> On Sat, Aug 23, 2008 at 8:00 PM, Jason McKesson <ko...@gm...> wrote:
>> Stefanos A. wrote:
>>> If I understand correctly, what we actually need is a way to generate
>>> geometry for the tutorials. Which means we just need the
>>> vertex/texcoord/normal/element arrays.
>>>
>>> While it's good to have functions that *generate* this data, is it really
>>> a good idea to hide the *drawing* part behind a glsDrawShape function?
>>> Maybe it would be better to simply return these four arrays and handle the
>>> drawing inside the tutorial?
>>>
>>> Just trying to understand the focus of the shape functions. What do you
>>> say?
>>>
>> Well, the problem with any form of generation of that type is this:
>> where are you going to put it? You can't put it into a user-supplied
>> buffer object because it might be too big (and having a query for the
>> size makes creating them very complex). And if you have it create the
>> buffer, how do you communicate the data format to the user?
>>
>> Basically, we want these things to be as simple as possible for the user
>> to use. This isn't production code, so flexibility is not a concern. We
>> want them to be able to go:
>>
>> //initialize GL/create window.
>> GLSshape myBox = glsCreateShapeBox(params);
>>
>> while(true)
>> {
>>  //setup context.
>>  glsShapeDraw(myBox);
>> }
>>
>> glsDestroyShape(param);
>>
>> The goal being that you can't make that fail. The user can't do
>> something wrong. And it's immediately obvious how it works.
>>
>> -------------------------------------------------------------------------
>> 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
>>
>

Re: [Glsdk-devel] The use of anonymous structures

[H. H. <hen...@gm...>]

Right :)

Hmm, someone reported that MSVC was giving warnings from anonymous
structs... Odd


On Sun, Aug 24, 2008 at 6:22 AM, Jason McKesson <ko...@gm...> wrote:

> Henri Häkkinen wrote:
> > Indeed. At the moment, I don't have an access to a Windows box, but
> > could somebody who has, kindly test out the possibility of this.
> >
> > Does the MSVC produce warnings, when you try to compile something like
> > this:
> >
> > typedef struct FOO_s {
> >   union {
> >     struct {
> >       int di;
> >     };
> >     in do;
> >   };
> > } FOO;
> >
> > int main()
> > {
> >   FOO f;
> >   f.di = 1;
> >   f.do = 2;
> >   return 0;
> > }
> No, but I can't imagine GCC does. That's because "do" is a C keyword ;)
>
> When you change it to be a regular identifier, it compiles fine. I even
> switched the order of the struct and the int, and it still works.
>
> -------------------------------------------------------------------------
> 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

Re: [Glsdk-devel] Geometry generation

[Jason M. <ko...@gm...>]

Branan Riley wrote:
> I have to agree with Jason on this one. If the user wants custom
> geometry, they need to learn how to deal with drawing it. For the sake
> of tutorials, we just need objects to show off transformations and
> shaders with. An opaque format reduces the risk of abuse not only by
> newbies, but also by people coding SDK examples.
>
> One thing that does need to be clear is how vertex attributes map to
> the arrays generated by the shape function. Something like:
>
> Attrib 0 is the position (vec4)
> Attrib 1 is the normal (vec3)
> Attrib 2 is the texcoord (vec2)
>
> That way shaders can always get the correct variables. I think I'll
> add preprocessor defines for this - GLS_POSITION_ATTRIBUTE,
> GLS_NORMAL_ATTRIBUTE, and GLS_TEXCOORD_ATTRIBUTE, so that there are no
> magic numbers floating around.
>   
Initially, I was thinking that we'd specify in our documentation 
somewhere what the attribute indices were, but the #define is better. Of 
course, the /types/ of those attributes should be well documented.

Re: [Glsdk-devel] The use of anonymous structures

[Jason M. <ko...@gm...>]

Henri Häkkinen wrote:
> Indeed. At the moment, I don't have an access to a Windows box, but 
> could somebody who has, kindly test out the possibility of this.
>
> Does the MSVC produce warnings, when you try to compile something like 
> this:
>
> typedef struct FOO_s {
>   union {
>     struct {
>       int di;
>     };
>     in do;
>   };
> } FOO;
>
> int main()
> {
>   FOO f;
>   f.di = 1;
>   f.do = 2;
>   return 0;
> }
No, but I can't imagine GCC does. That's because "do" is a C keyword ;)

When you change it to be a regular identifier, it compiles fine. I even 
switched the order of the struct and the int, and it still works.