Menu
▾
▴
glsdk-devel
|
From: Branan R. <br...@gm...> - 2008-08-23 23:20:57
|
I'm going to start on geometry generation functions. I think sphere, cube, cylinder, and cone are good to start with. I do have a couple questions about how we want to use these, though. 1) Should they return data in a pre-defined format, so that the user has to set up the VBOs to send the data (reinforcing the steps needed to get geometry to the GL), or should they handle it automatically (to make things simpler for code that's demonstrating shader effects) 2) What should the prefix be? I'm thinking gls for "OpenGL Shape" 3) If we want to have it return data, what's a good format for the data? Branan |
|
From: H. H. <hen...@gm...> - 2008-08-23 23:37:23
|
On Sun, Aug 24, 2008 at 2:21 AM, Branan Riley <br...@gm...> wrote:
> I'm going to start on geometry generation functions. I think sphere,
> cube, cylinder, and cone are good to start with.
>
> I do have a couple questions about how we want to use these, though.
>
> 1) Should they return data in a pre-defined format, so that the user
> has to set up the VBOs to send the data (reinforcing the steps needed
> to get geometry to the GL), or should they handle it automatically (to
> make things simpler for code that's demonstrating shader effects)
>
> 2) What should the prefix be? I'm thinking gls for "OpenGL Shape"
>
> 3) If we want to have it return data, what's a good format for the data?
>
>
I propose a some sort structure or an object which the functions return.
typedef struct GLSshape_s {
...
} GLSshape;
void glsCreateSphere (GLSshape *out, GLfloat radius);
...
Members are public so that the caller may directly access them. We could
later extend this library to load .obj files.
>
> Branan
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Glsdk-devel mailing list
> Gls...@li...
> https://lists.sourceforge.net/lists/listinfo/glsdk-devel
>
--
Henri 'henux' Häkkinen |
|
From: Branan R. <br...@gm...> - 2008-08-23 23:39:42
|
There's no point passing a *out variable. The generation function has
to allocate memory for the structure members anyway, so it may as well
allocate the whole structure.
And if we return a structure like that, do we have a glsDrawShape()
function, or do we make the user draw it?
On Sat, Aug 23, 2008 at 4:37 PM, Henri Häkkinen <hen...@gm...> wrote:
>
>
> On Sun, Aug 24, 2008 at 2:21 AM, Branan Riley <br...@gm...> wrote:
>>
>> I'm going to start on geometry generation functions. I think sphere,
>> cube, cylinder, and cone are good to start with.
>>
>> I do have a couple questions about how we want to use these, though.
>>
>> 1) Should they return data in a pre-defined format, so that the user
>> has to set up the VBOs to send the data (reinforcing the steps needed
>> to get geometry to the GL), or should they handle it automatically (to
>> make things simpler for code that's demonstrating shader effects)
>>
>> 2) What should the prefix be? I'm thinking gls for "OpenGL Shape"
>>
>> 3) If we want to have it return data, what's a good format for the data?
>>
>
> I propose a some sort structure or an object which the functions return.
>
> typedef struct GLSshape_s {
> ...
> } GLSshape;
>
> void glsCreateSphere (GLSshape *out, GLfloat radius);
> ...
>
> Members are public so that the caller may directly access them. We could
> later extend this library to load .obj files.
>
>>
>> Branan
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Glsdk-devel mailing list
>> Gls...@li...
>> https://lists.sourceforge.net/lists/listinfo/glsdk-devel
>
>
>
> --
> Henri 'henux' Häkkinen
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Glsdk-devel mailing list
> Gls...@li...
> https://lists.sourceforge.net/lists/listinfo/glsdk-devel
>
>
|
|
From: Jason M. <ko...@gm...> - 2008-08-24 00:42:28
|
Branan Riley wrote: > I'm going to start on geometry generation functions. I think sphere, > cube, cylinder, and cone are good to start with. > > I do have a couple questions about how we want to use these, though. > > 1) Should they return data in a pre-defined format, so that the user > has to set up the VBOs to send the data (reinforcing the steps needed > to get geometry to the GL), or should they handle it automatically (to > make things simpler for code that's demonstrating shader effects) > > 2) What should the prefix be? I'm thinking gls for "OpenGL Shape" > > 3) If we want to have it return data, what's a good format for the data? > There are simple parts of this and there are complicated parts of this. The easiest part: the SDK should not promote the use of any 3.0 deprecated functionality. So buffer objects and shaders for everything. Slightly easier: these "shape" generators are convenience functions. Therefore, they should be quick, simple, and not very complicated. So they shouldn't burden the user with unnecessary details (like creating certain GL objects, etc). It should be an object that the user gets with which the user can draw, through a "DrawShape" function. Harder: Unlike C++, C doesn't really have a language concept of data hiding. But data hiding is really important. Accessors are really important. It doesn't add any complexity to make an object opaque, so long as the object has appropriate accessor functions to get at necessary data. In short, I think shapes should be entirely opaque, not exposing the internal data structure to the user. Instead, they should just do their job. My personal preference would be as follows: typedef void* GLSshape; GLSshape glsCreateShapePredefined(params); void glsDestroyShape(GLSshape); void glsDrawShape(GLSshape); The first function uses "predefined" so that later we can add shapes that aren't predefined (loads from a file, user-created somehow, etc). The second function destroys the shape object. And the last binds and renders it using the state currently bound to the context. It has the least chance of breakage (GLSshape is opaque, so the user can't mess with it), and is very self-contained. We may need accessors to query the attribute indices, or an API to specify attribute indices at creation time. But that's about it. |
|
From: Branan R. <br...@gm...> - 2008-08-24 00:49:09
|
OK, that looks pretty good to me. I'd prefer multiple entrypoints, rather than one glsCreateShapePredefined. So I'd rather it be something like: glsCreateShapeShpere(); glsCreateShapeCube(); glsCreateShapeFromOBJ(); // naming convention for models is up for debate On Sat, Aug 23, 2008 at 5:42 PM, Jason McKesson <ko...@gm...> wrote: > Branan Riley wrote: >> I'm going to start on geometry generation functions. I think sphere, >> cube, cylinder, and cone are good to start with. >> >> I do have a couple questions about how we want to use these, though. >> >> 1) Should they return data in a pre-defined format, so that the user >> has to set up the VBOs to send the data (reinforcing the steps needed >> to get geometry to the GL), or should they handle it automatically (to >> make things simpler for code that's demonstrating shader effects) >> >> 2) What should the prefix be? I'm thinking gls for "OpenGL Shape" >> >> 3) If we want to have it return data, what's a good format for the data? >> > There are simple parts of this and there are complicated parts of this. > > The easiest part: the SDK should not promote the use of any 3.0 > deprecated functionality. So buffer objects and shaders for everything. > > Slightly easier: these "shape" generators are convenience functions. > Therefore, they should be quick, simple, and not very complicated. So > they shouldn't burden the user with unnecessary details (like creating > certain GL objects, etc). It should be an object that the user gets with > which the user can draw, through a "DrawShape" function. > > Harder: Unlike C++, C doesn't really have a language concept of data > hiding. But data hiding is really important. Accessors are really > important. It doesn't add any complexity to make an object opaque, so > long as the object has appropriate accessor functions to get at > necessary data. In short, I think shapes should be entirely opaque, not > exposing the internal data structure to the user. Instead, they should > just do their job. > > My personal preference would be as follows: > > typedef void* GLSshape; > > GLSshape glsCreateShapePredefined(params); > void glsDestroyShape(GLSshape); > void glsDrawShape(GLSshape); > > The first function uses "predefined" so that later we can add shapes > that aren't predefined (loads from a file, user-created somehow, etc). > The second function destroys the shape object. And the last binds and > renders it using the state currently bound to the context. > > It has the least chance of breakage (GLSshape is opaque, so the user > can't mess with it), and is very self-contained. We may need accessors > to query the attribute indices, or an API to specify attribute indices > at creation time. But that's about 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 > |
|
From: H. H. <hen...@gm...> - 2008-08-24 01:03:20
|
There are good ideas, but how about this:
The GLSshape is not opaque pointer, but a public structure like this:
typedef struct GLSshape_s {
GLuint vertex_buffer;
GLuint vertex_arrays;
// etc.
} GLSshape;
In this way, the caller could setup the structure himself and pass it on
DrawShape.
Or if we decide to handle GLSshape as opaque, we could also declare it like
this:
typedef struct GLShape_s *GLSshape;
In this way we can get minimal type checking if the user tries to push
something weird.
Also, I like Branan's idea of multiple entry-points. I would prefer their
names to be shorter (glsCreateSphere instead of glsCreateShapeSphere).
On Sun, Aug 24, 2008 at 3:49 AM, Branan Riley <br...@gm...> wrote:
> OK, that looks pretty good to me.
>
> I'd prefer multiple entrypoints, rather than one
> glsCreateShapePredefined. So I'd rather it be something like:
>
> glsCreateShapeShpere();
> glsCreateShapeCube();
> glsCreateShapeFromOBJ(); // naming convention for models is up for debate
>
>
> On Sat, Aug 23, 2008 at 5:42 PM, Jason McKesson <ko...@gm...> wrote:
> > Branan Riley wrote:
> >> I'm going to start on geometry generation functions. I think sphere,
> >> cube, cylinder, and cone are good to start with.
> >>
> >> I do have a couple questions about how we want to use these, though.
> >>
> >> 1) Should they return data in a pre-defined format, so that the user
> >> has to set up the VBOs to send the data (reinforcing the steps needed
> >> to get geometry to the GL), or should they handle it automatically (to
> >> make things simpler for code that's demonstrating shader effects)
> >>
> >> 2) What should the prefix be? I'm thinking gls for "OpenGL Shape"
> >>
> >> 3) If we want to have it return data, what's a good format for the data?
> >>
> > There are simple parts of this and there are complicated parts of this.
> >
> > The easiest part: the SDK should not promote the use of any 3.0
> > deprecated functionality. So buffer objects and shaders for everything.
> >
> > Slightly easier: these "shape" generators are convenience functions.
> > Therefore, they should be quick, simple, and not very complicated. So
> > they shouldn't burden the user with unnecessary details (like creating
> > certain GL objects, etc). It should be an object that the user gets with
> > which the user can draw, through a "DrawShape" function.
> >
> > Harder: Unlike C++, C doesn't really have a language concept of data
> > hiding. But data hiding is really important. Accessors are really
> > important. It doesn't add any complexity to make an object opaque, so
> > long as the object has appropriate accessor functions to get at
> > necessary data. In short, I think shapes should be entirely opaque, not
> > exposing the internal data structure to the user. Instead, they should
> > just do their job.
> >
> > My personal preference would be as follows:
> >
> > typedef void* GLSshape;
> >
> > GLSshape glsCreateShapePredefined(params);
> > void glsDestroyShape(GLSshape);
> > void glsDrawShape(GLSshape);
> >
> > The first function uses "predefined" so that later we can add shapes
> > that aren't predefined (loads from a file, user-created somehow, etc).
> > The second function destroys the shape object. And the last binds and
> > renders it using the state currently bound to the context.
> >
> > It has the least chance of breakage (GLSshape is opaque, so the user
> > can't mess with it), and is very self-contained. We may need accessors
> > to query the attribute indices, or an API to specify attribute indices
> > at creation time. But that's about 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
> >
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Glsdk-devel mailing list
> Gls...@li...
> https://lists.sourceforge.net/lists/listinfo/glsdk-devel
>
--
Henri 'henux' Häkkinen |
|
From: Branan R. <br...@gm...> - 2008-08-24 01:16:23
|
I think an opaque pointer is better. It makes the interface cleaner -
these APIs are meant for simple code, not production-level stuff, so
low-level access isn't needed.
Branan
On Sat, Aug 23, 2008 at 6:03 PM, Henri Häkkinen <hen...@gm...> wrote:
> There are good ideas, but how about this:
>
> The GLSshape is not opaque pointer, but a public structure like this:
>
> typedef struct GLSshape_s {
> GLuint vertex_buffer;
> GLuint vertex_arrays;
> // etc.
> } GLSshape;
>
> In this way, the caller could setup the structure himself and pass it on
> DrawShape.
>
> Or if we decide to handle GLSshape as opaque, we could also declare it like
> this:
>
> typedef struct GLShape_s *GLSshape;
>
> In this way we can get minimal type checking if the user tries to push
> something weird.
>
> Also, I like Branan's idea of multiple entry-points. I would prefer their
> names to be shorter (glsCreateSphere instead of glsCreateShapeSphere).
>
>
> On Sun, Aug 24, 2008 at 3:49 AM, Branan Riley <br...@gm...> wrote:
>>
>> OK, that looks pretty good to me.
>>
>> I'd prefer multiple entrypoints, rather than one
>> glsCreateShapePredefined. So I'd rather it be something like:
>>
>> glsCreateShapeShpere();
>> glsCreateShapeCube();
>> glsCreateShapeFromOBJ(); // naming convention for models is up for debate
>>
>>
>> On Sat, Aug 23, 2008 at 5:42 PM, Jason McKesson <ko...@gm...> wrote:
>> > Branan Riley wrote:
>> >> I'm going to start on geometry generation functions. I think sphere,
>> >> cube, cylinder, and cone are good to start with.
>> >>
>> >> I do have a couple questions about how we want to use these, though.
>> >>
>> >> 1) Should they return data in a pre-defined format, so that the user
>> >> has to set up the VBOs to send the data (reinforcing the steps needed
>> >> to get geometry to the GL), or should they handle it automatically (to
>> >> make things simpler for code that's demonstrating shader effects)
>> >>
>> >> 2) What should the prefix be? I'm thinking gls for "OpenGL Shape"
>> >>
>> >> 3) If we want to have it return data, what's a good format for the
>> >> data?
>> >>
>> > There are simple parts of this and there are complicated parts of this.
>> >
>> > The easiest part: the SDK should not promote the use of any 3.0
>> > deprecated functionality. So buffer objects and shaders for everything.
>> >
>> > Slightly easier: these "shape" generators are convenience functions.
>> > Therefore, they should be quick, simple, and not very complicated. So
>> > they shouldn't burden the user with unnecessary details (like creating
>> > certain GL objects, etc). It should be an object that the user gets with
>> > which the user can draw, through a "DrawShape" function.
>> >
>> > Harder: Unlike C++, C doesn't really have a language concept of data
>> > hiding. But data hiding is really important. Accessors are really
>> > important. It doesn't add any complexity to make an object opaque, so
>> > long as the object has appropriate accessor functions to get at
>> > necessary data. In short, I think shapes should be entirely opaque, not
>> > exposing the internal data structure to the user. Instead, they should
>> > just do their job.
>> >
>> > My personal preference would be as follows:
>> >
>> > typedef void* GLSshape;
>> >
>> > GLSshape glsCreateShapePredefined(params);
>> > void glsDestroyShape(GLSshape);
>> > void glsDrawShape(GLSshape);
>> >
>> > The first function uses "predefined" so that later we can add shapes
>> > that aren't predefined (loads from a file, user-created somehow, etc).
>> > The second function destroys the shape object. And the last binds and
>> > renders it using the state currently bound to the context.
>> >
>> > It has the least chance of breakage (GLSshape is opaque, so the user
>> > can't mess with it), and is very self-contained. We may need accessors
>> > to query the attribute indices, or an API to specify attribute indices
>> > at creation time. But that's about 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
>> >
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Glsdk-devel mailing list
>> Gls...@li...
>> https://lists.sourceforge.net/lists/listinfo/glsdk-devel
>
>
>
> --
> Henri 'henux' Häkkinen
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Glsdk-devel mailing list
> Gls...@li...
> https://lists.sourceforge.net/lists/listinfo/glsdk-devel
>
>
|
|
From: Branan R. <br...@gm...> - 2008-08-24 01:21:04
|
First draft of the GLShape API:
BEGIN FILE gls.h
#ifndef GLSDK_GLS_H
#define GLSDK_GLS_H
#ifdef WIN32
# include <windows.h>
#endif
#include <GL/gl.h>
typedef void* GLSshape;
// Predefined creation functions
GLSshape glsCreateShapeSphere (GLfloat radius, GLuint segments, GLuint rings);
GLSshape glsCreateShapeCylinder (GLfloat radius, GLfloat height,
GLboolean capped, GLuint segments, GLuint rings);
GLSshape glsCreateShapeCone (GLfloat radius, GLfloat height, GLboolean
capped, GLuint segments, GLuing rings);
GLSshape glsCreateShapeCube (GLfloat length, GLfloat width, GLfloat height);
// Cleanup functions
void glsDestroyShape (GLSshape shape);
// Drawing functions
void glsDrawShape(GLSshape shape);
#endif
ENDI FILE gls.h
On Sat, Aug 23, 2008 at 6:16 PM, Branan Riley <br...@gm...> wrote:
> I think an opaque pointer is better. It makes the interface cleaner -
> these APIs are meant for simple code, not production-level stuff, so
> low-level access isn't needed.
>
> Branan
>
> On Sat, Aug 23, 2008 at 6:03 PM, Henri Häkkinen <hen...@gm...> wrote:
>> There are good ideas, but how about this:
>>
>> The GLSshape is not opaque pointer, but a public structure like this:
>>
>> typedef struct GLSshape_s {
>> GLuint vertex_buffer;
>> GLuint vertex_arrays;
>> // etc.
>> } GLSshape;
>>
>> In this way, the caller could setup the structure himself and pass it on
>> DrawShape.
>>
>> Or if we decide to handle GLSshape as opaque, we could also declare it like
>> this:
>>
>> typedef struct GLShape_s *GLSshape;
>>
>> In this way we can get minimal type checking if the user tries to push
>> something weird.
>>
>> Also, I like Branan's idea of multiple entry-points. I would prefer their
>> names to be shorter (glsCreateSphere instead of glsCreateShapeSphere).
>>
>>
>> On Sun, Aug 24, 2008 at 3:49 AM, Branan Riley <br...@gm...> wrote:
>>>
>>> OK, that looks pretty good to me.
>>>
>>> I'd prefer multiple entrypoints, rather than one
>>> glsCreateShapePredefined. So I'd rather it be something like:
>>>
>>> glsCreateShapeShpere();
>>> glsCreateShapeCube();
>>> glsCreateShapeFromOBJ(); // naming convention for models is up for debate
>>>
>>>
>>> On Sat, Aug 23, 2008 at 5:42 PM, Jason McKesson <ko...@gm...> wrote:
>>> > Branan Riley wrote:
>>> >> I'm going to start on geometry generation functions. I think sphere,
>>> >> cube, cylinder, and cone are good to start with.
>>> >>
>>> >> I do have a couple questions about how we want to use these, though.
>>> >>
>>> >> 1) Should they return data in a pre-defined format, so that the user
>>> >> has to set up the VBOs to send the data (reinforcing the steps needed
>>> >> to get geometry to the GL), or should they handle it automatically (to
>>> >> make things simpler for code that's demonstrating shader effects)
>>> >>
>>> >> 2) What should the prefix be? I'm thinking gls for "OpenGL Shape"
>>> >>
>>> >> 3) If we want to have it return data, what's a good format for the
>>> >> data?
>>> >>
>>> > There are simple parts of this and there are complicated parts of this.
>>> >
>>> > The easiest part: the SDK should not promote the use of any 3.0
>>> > deprecated functionality. So buffer objects and shaders for everything.
>>> >
>>> > Slightly easier: these "shape" generators are convenience functions.
>>> > Therefore, they should be quick, simple, and not very complicated. So
>>> > they shouldn't burden the user with unnecessary details (like creating
>>> > certain GL objects, etc). It should be an object that the user gets with
>>> > which the user can draw, through a "DrawShape" function.
>>> >
>>> > Harder: Unlike C++, C doesn't really have a language concept of data
>>> > hiding. But data hiding is really important. Accessors are really
>>> > important. It doesn't add any complexity to make an object opaque, so
>>> > long as the object has appropriate accessor functions to get at
>>> > necessary data. In short, I think shapes should be entirely opaque, not
>>> > exposing the internal data structure to the user. Instead, they should
>>> > just do their job.
>>> >
>>> > My personal preference would be as follows:
>>> >
>>> > typedef void* GLSshape;
>>> >
>>> > GLSshape glsCreateShapePredefined(params);
>>> > void glsDestroyShape(GLSshape);
>>> > void glsDrawShape(GLSshape);
>>> >
>>> > The first function uses "predefined" so that later we can add shapes
>>> > that aren't predefined (loads from a file, user-created somehow, etc).
>>> > The second function destroys the shape object. And the last binds and
>>> > renders it using the state currently bound to the context.
>>> >
>>> > It has the least chance of breakage (GLSshape is opaque, so the user
>>> > can't mess with it), and is very self-contained. We may need accessors
>>> > to query the attribute indices, or an API to specify attribute indices
>>> > at creation time. But that's about 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
>>> >
>>>
>>> -------------------------------------------------------------------------
>>> 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: Stefanos A. <sta...@gm...> - 2008-08-24 02:27:21
|
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? |
|
From: H. H. <hen...@gm...> - 2008-08-24 02:31:07
|
On Sun, Aug 24, 2008 at 5:27 AM, Stefanos A. <sta...@gm...> 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. > We want to support OpenGL3 which only has vertex attributes. > > 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? > Basically, I think, we want a library that easies the drawing of simple objects. We will be having tutorials, of course, of how to draw basic triangles and stuff. But for a slightly more advanced tutorials and samples, we need to have some ready made library for drawing stuff. This is how I see it. > > Just trying to understand the focus of the shape functions. What do you > say? > > ------------------------------------------------------------------------- > 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-24 16:12:34
|
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 |
|
From: Jason M. <ko...@gm...> - 2008-08-24 18:07:25
|
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. |
|
From: Jason M. <ko...@gm...> - 2008-08-24 01:24:40
|
Henri Häkkinen wrote:
> There are good ideas, but how about this:
>
> The GLSshape is not opaque pointer, but a public structure like this:
>
> typedef struct GLSshape_s {
> GLuint vertex_buffer;
> GLuint vertex_arrays;
> // etc.
> } GLSshape;
>
> In this way, the caller could setup the structure himself and pass it
> on DrawShape.
If a user needs to create one of those structs in order to render with
buffer objects and vertex array objects that he has already created,
then our tutorials will have failed miserably. We are talking about an
object that is basically a wrapper around a vertex array object, after
all. It's a "bind" and "glDrawElements" call away from being drawn. The
hard work is in the creation of the various buffers, VAO bindings, and
so forth.
The point of making it an opaque pointer is so that shapes, pre-defined
meshes are protected from user intrusion and alteration. It also allows
us to /change/ the internal representation as the GL API changes and
matures.
>
> Or if we decide to handle GLSshape as opaque, we could also declare it
> like this:
>
> typedef struct GLShape_s *GLSshape;
>
> In this way we can get minimal type checking if the user tries to push
> something weird.
>
> Also, I like Branan's idea of multiple entry-points. I would prefer
> their names to be shorter (glsCreateSphere instead of
> glsCreateShapeSphere).
I can see a need for multiple entrypoints, but the longer names should stay.
The convention should be:
gls - Create (because it is creating an object) - Shape (the object
being created) - etc (for the various different ways of creating a shape).
It would be weird to call glsDestroy/Shape/ on something returned by
glsCreate/Sphere/.
>
> On Sun, Aug 24, 2008 at 3:49 AM, Branan Riley <br...@gm...
> <mailto:br...@gm...>> wrote:
>
> OK, that looks pretty good to me.
>
> I'd prefer multiple entrypoints, rather than one
> glsCreateShapePredefined. So I'd rather it be something like:
>
> glsCreateShapeShpere();
> glsCreateShapeCube();
> glsCreateShapeFromOBJ(); // naming convention for models is up for
> debate
>
>
> On Sat, Aug 23, 2008 at 5:42 PM, Jason McKesson <ko...@gm...
> <mailto:ko...@gm...>> wrote:
> > Branan Riley wrote:
> >> I'm going to start on geometry generation functions. I think
> sphere,
> >> cube, cylinder, and cone are good to start with.
> >>
> >> I do have a couple questions about how we want to use these,
> though.
> >>
> >> 1) Should they return data in a pre-defined format, so that the
> user
> >> has to set up the VBOs to send the data (reinforcing the steps
> needed
> >> to get geometry to the GL), or should they handle it
> automatically (to
> >> make things simpler for code that's demonstrating shader effects)
> >>
> >> 2) What should the prefix be? I'm thinking gls for "OpenGL Shape"
> >>
> >> 3) If we want to have it return data, what's a good format for
> the data?
> >>
> > There are simple parts of this and there are complicated parts
> of this.
> >
> > The easiest part: the SDK should not promote the use of any 3.0
> > deprecated functionality. So buffer objects and shaders for
> everything.
> >
> > Slightly easier: these "shape" generators are convenience functions.
> > Therefore, they should be quick, simple, and not very
> complicated. So
> > they shouldn't burden the user with unnecessary details (like
> creating
> > certain GL objects, etc). It should be an object that the user
> gets with
> > which the user can draw, through a "DrawShape" function.
> >
> > Harder: Unlike C++, C doesn't really have a language concept of data
> > hiding. But data hiding is really important. Accessors are really
> > important. It doesn't add any complexity to make an object
> opaque, so
> > long as the object has appropriate accessor functions to get at
> > necessary data. In short, I think shapes should be entirely
> opaque, not
> > exposing the internal data structure to the user. Instead, they
> should
> > just do their job.
> >
> > My personal preference would be as follows:
> >
> > typedef void* GLSshape;
> >
> > GLSshape glsCreateShapePredefined(params);
> > void glsDestroyShape(GLSshape);
> > void glsDrawShape(GLSshape);
> >
> > The first function uses "predefined" so that later we can add shapes
> > that aren't predefined (loads from a file, user-created somehow,
> etc).
> > The second function destroys the shape object. And the last
> binds and
> > renders it using the state currently bound to the context.
> >
> > It has the least chance of breakage (GLSshape is opaque, so the user
> > can't mess with it), and is very self-contained. We may need
> accessors
> > to query the attribute indices, or an API to specify attribute
> indices
> > at creation time. But that's about 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=/
> <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
> > _______________________________________________
> > Glsdk-devel mailing list
> > Gls...@li...
> <mailto: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=/
> <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
> _______________________________________________
> Glsdk-devel mailing list
> Gls...@li...
> <mailto: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-24 01:35:34
|
On Sun, Aug 24, 2008 at 4:25 AM, Jason McKesson <ko...@gm...> wrote:
> Henri Häkkinen wrote:
>
> There are good ideas, but how about this:
>
> The GLSshape is not opaque pointer, but a public structure like this:
>
> typedef struct GLSshape_s {
> GLuint vertex_buffer;
> GLuint vertex_arrays;
> // etc.
> } GLSshape;
>
> In this way, the caller could setup the structure himself and pass it on
> DrawShape.
>
> If a user needs to create one of those structs in order to render with
> buffer objects and vertex array objects that he has already created, then
> our tutorials will have failed miserably. We are talking about an object
> that is basically a wrapper around a vertex array object, after all. It's a
> "bind" and "glDrawElements" call away from being drawn. The hard work is in
> the creation of the various buffers, VAO bindings, and so forth.
>
Again; I clearly did not say that a user must or need to setup struct on his
own, but pointed out the possibility and the benefits of it.
>
>
> The point of making it an opaque pointer is so that shapes, pre-defined
> meshes are protected from user intrusion and alteration. It also allows us
> to *change* the internal representation as the GL API changes and matures.
>
That is a valid point.
>
>
> Or if we decide to handle GLSshape as opaque, we could also declare it like
> this:
>
> typedef struct GLShape_s *GLSshape;
>
> In this way we can get minimal type checking if the user tries to push
> something weird.
>
> Also, I like Branan's idea of multiple entry-points. I would prefer their
> names to be shorter (glsCreateSphere instead of glsCreateShapeSphere).
>
> I can see a need for multiple entrypoints, but the longer names should
> stay.
>
> The convention should be:
>
> gls - Create (because it is creating an object) - Shape (the object being
> created) - etc (for the various different ways of creating a shape).
>
> It would be weird to call glsDestroy*Shape* on something returned by
> glsCreate*Sphere*.
>
IMO, it would not be that weird; glsCreateShape return GLSshape object.
Shorter names are more convenient, IMO. Either way, I am just trying to be
constructive by giving ideas which you seem to smash first-handedly just
because of your own personal conventions of doing things.
In the long run, shorter names may be more convenient as it is obvious from
the name of the function what kind of thing it is creating.
>
>
> On Sun, Aug 24, 2008 at 3:49 AM, Branan Riley <br...@gm...> wrote:
>
>> OK, that looks pretty good to me.
>>
>> I'd prefer multiple entrypoints, rather than one
>> glsCreateShapePredefined. So I'd rather it be something like:
>>
>> glsCreateShapeShpere();
>> glsCreateShapeCube();
>> glsCreateShapeFromOBJ(); // naming convention for models is up for debate
>>
>>
>> On Sat, Aug 23, 2008 at 5:42 PM, Jason McKesson <ko...@gm...>
>> wrote:
>> > Branan Riley wrote:
>> >> I'm going to start on geometry generation functions. I think sphere,
>> >> cube, cylinder, and cone are good to start with.
>> >>
>> >> I do have a couple questions about how we want to use these, though.
>> >>
>> >> 1) Should they return data in a pre-defined format, so that the user
>> >> has to set up the VBOs to send the data (reinforcing the steps needed
>> >> to get geometry to the GL), or should they handle it automatically (to
>> >> make things simpler for code that's demonstrating shader effects)
>> >>
>> >> 2) What should the prefix be? I'm thinking gls for "OpenGL Shape"
>> >>
>> >> 3) If we want to have it return data, what's a good format for the
>> data?
>> >>
>> > There are simple parts of this and there are complicated parts of this.
>> >
>> > The easiest part: the SDK should not promote the use of any 3.0
>> > deprecated functionality. So buffer objects and shaders for everything.
>> >
>> > Slightly easier: these "shape" generators are convenience functions.
>> > Therefore, they should be quick, simple, and not very complicated. So
>> > they shouldn't burden the user with unnecessary details (like creating
>> > certain GL objects, etc). It should be an object that the user gets with
>> > which the user can draw, through a "DrawShape" function.
>> >
>> > Harder: Unlike C++, C doesn't really have a language concept of data
>> > hiding. But data hiding is really important. Accessors are really
>> > important. It doesn't add any complexity to make an object opaque, so
>> > long as the object has appropriate accessor functions to get at
>> > necessary data. In short, I think shapes should be entirely opaque, not
>> > exposing the internal data structure to the user. Instead, they should
>> > just do their job.
>> >
>> > My personal preference would be as follows:
>> >
>> > typedef void* GLSshape;
>> >
>> > GLSshape glsCreateShapePredefined(params);
>> > void glsDestroyShape(GLSshape);
>> > void glsDrawShape(GLSshape);
>> >
>> > The first function uses "predefined" so that later we can add shapes
>> > that aren't predefined (loads from a file, user-created somehow, etc).
>> > The second function destroys the shape object. And the last binds and
>> > renders it using the state currently bound to the context.
>> >
>> > It has the least chance of breakage (GLSshape is opaque, so the user
>> > can't mess with it), and is very self-contained. We may need accessors
>> > to query the attribute indices, or an API to specify attribute indices
>> > at creation time. But that's about 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
>> >
>>
>> -------------------------------------------------------------------------
>> 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 worldhttp://moblin-contest.org/redirect.php?banner_id=100&url=/
>
> ------------------------------
>
> _______________________________________________
> Glsdk-devel mailing lis...@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-24 02:30:53
|
Henri Häkkinen wrote:
>
>
> On Sun, Aug 24, 2008 at 4:25 AM, Jason McKesson <ko...@gm...
> <mailto:ko...@gm...>> wrote:
>
> Henri Häkkinen wrote:
>> There are good ideas, but how about this:
>>
>> The GLSshape is not opaque pointer, but a public structure like this:
>>
>> typedef struct GLSshape_s {
>> GLuint vertex_buffer;
>> GLuint vertex_arrays;
>> // etc.
>> } GLSshape;
>>
>> In this way, the caller could setup the structure himself and
>> pass it on DrawShape.
> If a user needs to create one of those structs in order to render
> with buffer objects and vertex array objects that he has already
> created, then our tutorials will have failed miserably. We are
> talking about an object that is basically a wrapper around a
> vertex array object, after all. It's a "bind" and "glDrawElements"
> call away from being drawn. The hard work is in the creation of
> the various buffers, VAO bindings, and so forth.
>
>
> Again; I clearly did not say that a user must or need to setup struct
> on his own, but pointed out the possibility and the benefits of it.
Yes, and we have argued that the benefits do not outweigh the costs. I'm
not sure what you're getting at here.
>
>>
>> Or if we decide to handle GLSshape as opaque, we could also
>> declare it like this:
>>
>> typedef struct GLShape_s *GLSshape;
>>
>> In this way we can get minimal type checking if the user tries to
>> push something weird.
>>
>> Also, I like Branan's idea of multiple entry-points. I would
>> prefer their names to be shorter (glsCreateSphere instead of
>> glsCreateShapeSphere).
> I can see a need for multiple entrypoints, but the longer names
> should stay.
>
> The convention should be:
>
> gls - Create (because it is creating an object) - Shape (the
> object being created) - etc (for the various different ways of
> creating a shape).
>
> It would be weird to call glsDestroy/Shape/ on something returned
> by glsCreate/Sphere/.
>
>
> IMO, it would not be that weird; glsCreateShape return GLSshape
> object. Shorter names are more convenient, IMO.
The purpose for having a naming convention is to create a consistency of
naming among all named things. If that means a name gets "too long," so
be it; having inconsistent naming is far worse in the long run than
having to type 5 more characters. I've used many APIs that have
inconsistent naming (hello, Win32), and it's /never/ a good thing, no
matter what the original reason for it was.
> Either way, I am just trying to be constructive by giving ideas which
> you seem to smash first-handedly just because of your own personal
> conventions of doing things.
Just because your ideas are being shot down, or even argued against,
does not make the criticism non-constructive.
This is going to be a long project. People are going to have opinions
and disagree. People are going to argue for their points of view, and
they're going to make arguments against other people's points of view.
Attacking someone for doing so is not conducive to a productive atmosphere.
|
|
From: H. H. <hen...@gm...> - 2008-08-24 02:35:27
|
Fine. You have made good points there and I listen to them. I have brought
up my view which you counter argumented with other points. We both have
brought up points from different angles and this is a good thing. My
intentions are not to be counter-productive.
I think we should let the author of the library to have the final word on
this.
On Sun, Aug 24, 2008 at 5:31 AM, Jason McKesson <ko...@gm...> wrote:
> Henri Häkkinen wrote:
>
>
>
> On Sun, Aug 24, 2008 at 4:25 AM, Jason McKesson <ko...@gm...> wrote:
>
>> Henri Häkkinen wrote:
>>
>> There are good ideas, but how about this:
>>
>> The GLSshape is not opaque pointer, but a public structure like this:
>>
>> typedef struct GLSshape_s {
>> GLuint vertex_buffer;
>> GLuint vertex_arrays;
>> // etc.
>> } GLSshape;
>>
>> In this way, the caller could setup the structure himself and pass it on
>> DrawShape.
>>
>> If a user needs to create one of those structs in order to render with
>> buffer objects and vertex array objects that he has already created, then
>> our tutorials will have failed miserably. We are talking about an object
>> that is basically a wrapper around a vertex array object, after all. It's a
>> "bind" and "glDrawElements" call away from being drawn. The hard work is in
>> the creation of the various buffers, VAO bindings, and so forth.
>>
>
> Again; I clearly did not say that a user must or need to setup struct on
> his own, but pointed out the possibility and the benefits of it.
>
> Yes, and we have argued that the benefits do not outweigh the costs. I'm
> not sure what you're getting at here.
>
>
>>
>> Or if we decide to handle GLSshape as opaque, we could also declare it
>> like this:
>>
>> typedef struct GLShape_s *GLSshape;
>>
>> In this way we can get minimal type checking if the user tries to push
>> something weird.
>>
>> Also, I like Branan's idea of multiple entry-points. I would prefer their
>> names to be shorter (glsCreateSphere instead of glsCreateShapeSphere).
>>
>> I can see a need for multiple entrypoints, but the longer names should
>> stay.
>>
>> The convention should be:
>>
>> gls - Create (because it is creating an object) - Shape (the object being
>> created) - etc (for the various different ways of creating a shape).
>>
>> It would be weird to call glsDestroy*Shape* on something returned by
>> glsCreate*Sphere*.
>>
>
> IMO, it would not be that weird; glsCreateShape return GLSshape object.
> Shorter names are more convenient, IMO.
>
> The purpose for having a naming convention is to create a consistency of
> naming among all named things. If that means a name gets "too long," so be
> it; having inconsistent naming is far worse in the long run than having to
> type 5 more characters. I've used many APIs that have inconsistent naming
> (hello, Win32), and it's *never* a good thing, no matter what the original
> reason for it was.
>
> Either way, I am just trying to be constructive by giving ideas which
> you seem to smash first-handedly just because of your own personal
> conventions of doing things.
>
> Just because your ideas are being shot down, or even argued against, does
> not make the criticism non-constructive.
>
> This is going to be a long project. People are going to have opinions and
> disagree. People are going to argue for their points of view, and they're
> going to make arguments against other people's points of view. Attacking
> someone for doing so is not conducive to a productive atmosphere.
>
> -------------------------------------------------------------------------
> 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-24 03:00:30
|
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.
|
|
From: Branan R. <br...@gm...> - 2008-08-24 03:14:00
|
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
>
|
|
From: Jason M. <ko...@gm...> - 2008-08-24 03:24:27
|
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. |
|
From: Branan R. <br...@gm...> - 2008-08-24 03:26:20
|
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
>>
>
|
|
From: Stefanos A. <sta...@gm...> - 2008-08-24 14:34:21
|
> >>> 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). |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X