Menu
▾
▴
Re: [Glsdk-devel] Geometry generation
|
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
>
|
