Re: [Glsdk-devel] Geometry generation

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

Just realized I forgot something in my last message:

While I like the opaque data structure, I don't like the long names.
They might be slightly more clear, but they're longer and slightly
harder to type, and I just don't like them. For now, it's 2-1 for the
short names, and I say we end the discussion on them unless someone
else chimes in and messes up the vote. Agreed?

Branan

On Sat, Aug 23, 2008 at 8:14 PM, Branan Riley <br...@gm...> wrote:
> I have to agree with Jason on this one. If the user wants custom
> geometry, they need to learn how to deal with drawing it. For the sake
> of tutorials, we just need objects to show off transformations and
> shaders with. An opaque format reduces the risk of abuse not only by
> newbies, but also by people coding SDK examples.
>
> One thing that does need to be clear is how vertex attributes map to
> the arrays generated by the shape function. Something like:
>
> Attrib 0 is the position (vec4)
> Attrib 1 is the normal (vec3)
> Attrib 2 is the texcoord (vec2)
>
> That way shaders can always get the correct variables. I think I'll
> add preprocessor defines for this - GLS_POSITION_ATTRIBUTE,
> GLS_NORMAL_ATTRIBUTE, and GLS_TEXCOORD_ATTRIBUTE, so that there are no
> magic numbers floating around.
>
> On Sat, Aug 23, 2008 at 8:00 PM, Jason McKesson <ko...@gm...> wrote:
>> Stefanos A. wrote:
>>> If I understand correctly, what we actually need is a way to generate
>>> geometry for the tutorials. Which means we just need the
>>> vertex/texcoord/normal/element arrays.
>>>
>>> While it's good to have functions that *generate* this data, is it really
>>> a good idea to hide the *drawing* part behind a glsDrawShape function?
>>> Maybe it would be better to simply return these four arrays and handle the
>>> drawing inside the tutorial?
>>>
>>> Just trying to understand the focus of the shape functions. What do you
>>> say?
>>>
>> Well, the problem with any form of generation of that type is this:
>> where are you going to put it? You can't put it into a user-supplied
>> buffer object because it might be too big (and having a query for the
>> size makes creating them very complex). And if you have it create the
>> buffer, how do you communicate the data format to the user?
>>
>> Basically, we want these things to be as simple as possible for the user
>> to use. This isn't production code, so flexibility is not a concern. We
>> want them to be able to go:
>>
>> //initialize GL/create window.
>> GLSshape myBox = glsCreateShapeBox(params);
>>
>> while(true)
>> {
>>  //setup context.
>>  glsShapeDraw(myBox);
>> }
>>
>> glsDestroyShape(param);
>>
>> The goal being that you can't make that fail. The user can't do
>> something wrong. And it's immediately obvious how it works.
>>
>> -------------------------------------------------------------------------
>> 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
>>
>