Re: [Glsdk-devel] Geometry generation

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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

Re: [Glsdk-devel] Geometry generation

Utility libraries for working with OpenGL.

Re: [Glsdk-devel] Geometry generation