Re: [Glsdk-devel] Geometry generation

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

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
>