Menu
▾
▴
Re: [Glsdk-devel] Geometry generation
|
From: Branan R. <br...@gm...> - 2008-08-24 01:21:04
|
First draft of the GLShape API:
BEGIN FILE gls.h
#ifndef GLSDK_GLS_H
#define GLSDK_GLS_H
#ifdef WIN32
# include <windows.h>
#endif
#include <GL/gl.h>
typedef void* GLSshape;
// Predefined creation functions
GLSshape glsCreateShapeSphere (GLfloat radius, GLuint segments, GLuint rings);
GLSshape glsCreateShapeCylinder (GLfloat radius, GLfloat height,
GLboolean capped, GLuint segments, GLuint rings);
GLSshape glsCreateShapeCone (GLfloat radius, GLfloat height, GLboolean
capped, GLuint segments, GLuing rings);
GLSshape glsCreateShapeCube (GLfloat length, GLfloat width, GLfloat height);
// Cleanup functions
void glsDestroyShape (GLSshape shape);
// Drawing functions
void glsDrawShape(GLSshape shape);
#endif
ENDI FILE gls.h
On Sat, Aug 23, 2008 at 6:16 PM, Branan Riley <br...@gm...> wrote:
> I think an opaque pointer is better. It makes the interface cleaner -
> these APIs are meant for simple code, not production-level stuff, so
> low-level access isn't needed.
>
> Branan
>
> On Sat, Aug 23, 2008 at 6:03 PM, Henri Häkkinen <hen...@gm...> 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.
>>
>> 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
>>
>>
>> -------------------------------------------------------------------------
>> 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
>>
>>
>
|
