Re: [Glsdk-devel] Geometry generation

[Jason M. <ko...@gm...>]

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.