Re: [Glsdk-devel] Geometry generation

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

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