glsdk-devel Mailing List for OpenGL Software Development Kit

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

Hullo,

How are things going with GLSDK?  I see stuff happen in the source tree
but nothing either here or in #glsdk.

Regards,
elmindreda

...is now supported by the head of the 2.x-lite branch.

Regards,
elmindreda

> The biggest issue I see is with the large amount of "stuff" that has
> to be taught before a working application can be created.

We have shape library. If we had shader library (we need just one shader
at first), then we could leave teaching shaders and buffer objects for
later, and focus on translation, rotation and projection at first. Just
tell the user to load one of predefined shaders and don't bother for now.

Then we could introduce buffer objects, which will allow creating custom
shapes, but still with predefined shaders.

Finally custome shaders would be introduced.

> I'm not sure if we should include tutorials on various techniques or
> not - there are many different lighting equations, should be include a
> tutorial on Lighting, or leave that to the outside world?

I think lighting tutorials should be included.
I think lighting is what shader tutorials should actually start from (we
would do no lighting up to this point, just coloured polygons).
How about this list of lighting shaders:
-pass a color and interpolate it
-directional, unattenuaded diffuse lighting
-point light, diffuse only
-point light, diffuse + specular
-spot light, diffuse + specular
-shader with two lights (directional + interactive controlled spotlight +
a few moving objects in the scene)

All lighting tutorials would use some ambient or emissive lighting.
Then we could go to texturing.

By the way - it would be good if we had following objects in shape library:
-"spotlight" (I propose a flashlight, since it visualises direction nicely)
-"pointlight" (a lightbulb?)
-flat arrow
-3D arrow

I could make models with Blender and convert to .c files if necessary.

OK, it's time to start thinking about the tutorials, an how they
should be implemented.

The biggest issue I see is with the large amount of "stuff" that has
to be taught before a working application can be created. At a
minimum, context creation, vertex buffers, and shaders need to be
taught all at once. After that, there are a number of options. I think
3D transformations needs to be covered early, followed by texturing
and then off-screen rendering (FBOs). I also think we should have
tutorials on GLX, WGL, and whatever the Mac OS X interface to OpenGL
is called.

I'm not sure if we should include tutorials on various techniques or
not - there are many different lighting equations, should be include a
tutorial on Lighting, or leave that to the outside world?

Here's my proposed progression so far:
Tutorial 0: Introduction to OpenGL, introduction to the boilerplate code
Tutorial 1: Buffer Objects, Shaders, Projection matrices (can just be
mentioned, doesn't need to be explained)
Tutorial 2: Rotation, Translation, Scaling
Tutorial 3: Texturing
Tutorial 4: FBOs and Offscreen Rendering

Tutorial A: GLX
Tutorial B: WGL
Tutorial C: OSX

Branan

You still have my support, but I will not be active until beginning of 2009.

I will contribute C++ math library candidate and very likely one or two
tech demos.

Still, our main effort should now go towards tutorials. I think we need
strong organisation of work here.

What I propose:
1. Choose one person to be "leader of tutorial team"
2. Prepare a list of tutorials to be made - each one with short
description of scope (list remains open)
3. Expose such list via web page

Anyone could request to be assigned to selected tutorial(s). Once accepted
by "leader", he would be officially assigned to tutorial. If he does not
provide it withon month, tutorial is opened again.

The most important thing is that someone has to take control of the
process of implementing tutorials.

If no one else would tae the position of "tutorial team leader", I could,
but right now I don't have time for it. As soon as I get back home I would
be happy to provide tutorials, too.

>> The GLX extension for GL3 was finally released,
>
> Oh?  Yay!
>
>> so I'm going to try and work with the GLFW people to get
>> GL3 on Linux working.
>
> Looking into it now.  Will try to get it done as soon as possible.

OK. Let me know when it's working and I'll install the GL3 beta
drivers from NVIDIA and test it out.

Branan

Branan Riley wrote:
> The GLX extension for GL3 was finally released,

Oh?  Yay!

> so I'm going to try and work with the GLFW people to get
> GL3 on Linux working.

Looking into it now.  Will try to get it done as soon as possible.

Regards,
elmindreda

The GLX extension for GL3 was finally released, so I'm going to try
and work with the GLFW people to get GL3 on Linux working. Once that's
all set, I'll try to get shapelib finished (I've been waiting for GL3
support so I could make sure my rendering code in shapelib is GL3
compatible).

Once that's all set, and I get a CMake template for example code in
place, we can start soliciting example code from the community.

Tutorials will need more cohesion than examples, so developing a plan
for those needs to be high on the priority list at this point. With
the drop of fixed functionality, lots of stuff needs to be explained
before even a simple program can be run, making tutorial cohesion even
more important.

Branan

On Tue, Oct 28, 2008 at 12:30 PM, Henri Häkkinen <hen...@gm...> wrote:
> Hello to you all.
>
> Our GLSDK project has now been up for two months. Our repository contains
> 33,388 lines of source code, consisting of three libraries. The math library
> is mostly done, except for the quaternion algebra code. Korval's code
> generator is up and running.  Branan's shapelib is a good start.
>
> But things have been quiet for some time now... The communication in this
> mailing list has stopped. The IRC channel has been quiet for a long time and
> also the OpenGL forum on this project. The last commit was four weeks ago.
> The SDK is completely lacking the main thing we originally set up to do --
> the tutorials, samples and documentation in general -- and nobody has been
> actively pushing in this area.
>
> The question arises:
>
> --- What is the future of the OpenGL SDK project? ---
>
> --
> Henri 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=/
>

Hello to you all.

Our GLSDK project has now been up for two months. Our repository contains
33,388 lines of source code, consisting of three libraries. The math library
is mostly done, except for the quaternion algebra code. Korval's code
generator is up and running.  Branan's shapelib is a good start.

But things have been quiet for some time now... The communication in this
mailing list has stopped. The IRC channel has been quiet for a long time and
also the OpenGL forum on this project. The last commit was four weeks ago.
The SDK is completely lacking the main thing we originally set up to do --
the tutorials, samples and documentation in general -- and nobody has been
actively pushing in this area.

The question arises:

--- What is the future of the OpenGL SDK project? ---

-- 
Henri Häkkinen
On Sun, 2008-10-05 at 15:31 -0700, Jason McKesson wrote:
> Stefanos A. wrote:
> >>>> gleLoadFunctions(GLint majorVersion, GLint minorVersion);
> >>>>         
> >>>> This will load all functions and extensions up to the given GL version.
> >>>>         
> >>> What about non-core functions? Things like ARB, EXT, etc.
> >>>
> >>>       
> >> "will load all functions and extensions". That includes extensions.
> >>     
> >
> > Have you found any reliable way to group extensions by version? Looking
> > at the gl.spec, many interesting extensions miss the "version"
> > directive...
> I'm not sure that there is a need to group extensions by version. Either 
> the extension is in the extension string or it is not. If it is 
> supported, then it is supported and you can use it. And if it's not 
> supported, then its not supported and you can't use it. It's up to the 
> IHVs to not expose inappropriate extensions (extensions that don't make 
> sense with a particular version).
> 

Makes sense, grouping provides no benefit here.

BTW, I've had some users mention that they were able to load and use
specific extensions, even when they were not present in the extension
string (nvidia hardware, old drivers). Anyone knows what's the matter
with that?

Stefanos A. wrote:
>>>> gleLoadFunctions(GLint majorVersion, GLint minorVersion);
>>>>         
>>>> This will load all functions and extensions up to the given GL version.
>>>>         
>>> What about non-core functions? Things like ARB, EXT, etc.
>>>
>>>       
>> "will load all functions and extensions". That includes extensions.
>>     
>
> Have you found any reliable way to group extensions by version? Looking
> at the gl.spec, many interesting extensions miss the "version"
> directive...
I'm not sure that there is a need to group extensions by version. Either 
the extension is in the extension string or it is not. If it is 
supported, then it is supported and you can use it. And if it's not 
supported, then its not supported and you can't use it. It's up to the 
IHVs to not expose inappropriate extensions (extensions that don't make 
sense with a particular version).

> >
> > > gleLoadFunctions(GLint majorVersion, GLint minorVersion);
> >
> > > This will load all functions and extensions up to the given GL version.
> >
> > What about non-core functions? Things like ARB, EXT, etc.
> >
> "will load all functions and extensions". That includes extensions.
> >

Have you found any reliable way to group extensions by version? Looking
at the gl.spec, many interesting extensions miss the "version"
directive...

Camilla Berglund wrote:
> StApostol wrote:
>   
>>> No, it won't.  GLFW doesn't allow that call unless it owns the context.
>>>       
>> Really? All I can think is why was it implemented like this? As long as
>> [wgl/glx/agl]GetCurrentContext returns something, [wgl/glx/agl]GetAddress
>> should be safe to call.
>>     
>
> Yup, it should.  I would assume it was because no one thought of it
> being used that way (it was before my time).  I guess I could change
> it if you want to call it that way.
>
> Regards,
> elmindreda
I don't know why I'm getting all of these e-mails now, but it would be 
useful to have a GetAddress function that someone who actually can use 
non-Windows platforms can assure me actually works. So yes, it wouldn't 
be a bad idea to call glfwGetAddress, if it could be called from an 
arbitrary GL context.

StApostol wrote:
> > Windows defines its function entrypoints for the
> > stuff in gl.h, not as function pointers, but as live functions. I doubt
> > that wglGetExtension will work for them. So I'm not entirely sure how to
> > go about handling this part. Any suggestions?
>
> You are right regarding wglGetExtension not working with these 
> functions (or at least not consistently). To make matters worse, 
> different platforms expose different subsets dynamically, making 
> things tricky.
>
> Solution:
>
> 0. Define all signatures. Define static imports for all core functions 
> (i.e. versions 1.0-3.0). These are not exposed to the user.
>
> 1. Define all functions as function pointers. This is the public API.
>
> 2. Load each function dynamically (wgl/glx/aglGetAddress). If the 
> function pointer is *not* -1, 0, 1, 2 or 3 use it. If it is and the 
> function is core, use the relevant static export instead. Otherwise 
> "arm" the pointer with NULL.
>
> I am using this method in Tao/OpenTK with success. It works on all 
> platforms and is reliable.
>
Sounds good. I'll do that once I get the platform-specific stuff working.

BTW, I didn't get this e-mail until today. Something strange with the 
mailing-list server, perhaps?
>
> Notes:
>
> a. Some nvidia drivers return invalid function pointers (-1, 1, 2, 3), 
> so you have to take this into account.
>
> b. On windows, different contexts may return different function 
> pointers. This is normally not an issue, as it only happens between 
> different renderers (e.g. microsoft GDI and an accelerated context). 
> Still, I prefer to provide a "reload" function to the user in case 
> it's needed.
>
The load function already starts by clearing all of the function pointers.

Andrew Gajda wrote:
> Just want to re-iterate a list that Rob Barris posted a while ago:
>
> > - how do I establish a context and put it on the screen
> > - make a window, init context, clear, swap
> >
> > - how do I put data in a buffer so GPU can see it
> > - no drawing - just demonstrate the buffer API's
> > - perhaps BufferData some floats into a buffer, then map it and
> > print the values seen
> >
> > - how do I draw the simplest possible triangle
> > - pass-through shader for vert position
> > - "write red" for pixel
> > - constant verts for geometry in a VBO
> >
> > - how can I change the color of the triangle
> > - introduce per vertex color attribute
> > - vertex shader passes it through
> > - alter pixel shader to read it and emit it
> >
> > - introduction to uniforms - communicate to shaders
> > - show color change using uniform (several ways to do this)
> >
> > - how can I move the triangle
> > - see above
> >
> > that's a lot of good tutorial steps before we even start talking
> > about more than one triangle.
>
> That list is perfect for beginners in the Tutorial/Example area.  The 
> goal here being not too general ("Intro to 3D") but specific to what a 
> beginner is trying to do: Code in OpenGL.  There are of course those 
> that need a how-to on 3D, but those are a dime-a-dozen on the web.  
> OpenGL 3.0 (or at least no-FF OpenGL 2.x) are rare to non-existent.
>
> Andrew
Tutorials are the most important part of the SDK in terms of actually 
teaching OpenGL to users. Therefore, we need to actually design the 
tutorials. We need to figure out what each tutorial will be about on our 
own. Tutorials are teaching tools, and teaching is not something that is 
easily done by random data given by a random sampling of GL users. The 
tutorials as a whole are something that someone needs to own.

Demos and examples can be solicited from others just fine.

Just want to re-iterate a list that Rob Barris posted a while ago:

> - how do I establish a context and put it on the screen
> - make a window, init context, clear, swap
>
> - how do I put data in a buffer so GPU can see it
> - no drawing - just demonstrate the buffer API's
> - perhaps BufferData some floats into a buffer, then map it and
> print the values seen
>
> - how do I draw the simplest possible triangle
> - pass-through shader for vert position
> - "write red" for pixel
> - constant verts for geometry in a VBO
>
> - how can I change the color of the triangle
> - introduce per vertex color attribute
> - vertex shader passes it through
> - alter pixel shader to read it and emit it
>
> - introduction to uniforms - communicate to shaders
> - show color change using uniform (several ways to do this)
>
> - how can I move the triangle
> - see above
>
> that's a lot of good tutorial steps before we even start talking
> about more than one triangle.

That list is perfect for beginners in the Tutorial/Example area.  The goal
here being not too general ("Intro to 3D") but specific to what a beginner
is trying to do: Code in OpenGL.  There are of course those that need a
how-to on 3D, but those are a dime-a-dozen on the web.  OpenGL 3.0 (or at
least no-FF OpenGL 2.x) are rare to non-existent.

Andrew

StApostol wrote:
>> No, it won't.  GLFW doesn't allow that call unless it owns the context.
>
> Really? All I can think is why was it implemented like this? As long as
> [wgl/glx/agl]GetCurrentContext returns something, [wgl/glx/agl]GetAddress
> should be safe to call.

Yup, it should.  I would assume it was because no one thought of it
being used that way (it was before my time).  I guess I could change
it if you want to call it that way.

Regards,
elmindreda

I think it's time we make a call for tutorials. Here's a draft message I've
been working on for the OpenGL message boards:

First, a few definitions, in the context of the SDK:

   - A *Tutorial* is mostly text, with some code or pseudocode interspersed.
   - A *Example* is a complete program, with an accompanying document
   explaining how it works.
   - A *Demo* is a complete program without an accompanying document, though
   still well-commented in the source code.

 Our frameworks aren't quite to the point where we can do examples or demos,
but tutorials don't require those frameworks. Beginner tutorials would be
prefered, but we won't turn away more advanced topics.

With all that out of the way, I'd like to suggest that all those interested
in creating tutorials try to get together online, preferably with some of us
already working on the SDK, and work out structure and conventions for all
the tutorials. The other important thing to work out is licensing. The GFDL
or Creative Commons share-alike are the best ones for this situation, in my
opinion. This is something that will need to be discussed, though.

I'd also like to add a list of the* *must-have tutorials. I'm not 100% sure
what those should be, and we may want to ask the OpenGL community at large
what they think.

Here's my initial list:

   - Overview
   - Introduction to 3D Space
   - Vertex specification
   - Introduction to Vectors and Matrices
   - Vertex Shaders
   - Introduction to pixels/fragments
   - Fragment Shaders

If anyone has anything to add to that progression, or any comments, they'd
be greatly appreciated.

Branan

PS Sorry about the HTML message, I really think the formatting was needed to
get everything across properly.

On Sun, Sep 28, 2008 at 3:43 PM, Camilla Berglund <
cam...@gm...> wrote:

> StApostol wrote:
> >> I suppose we can determine the version automatically, by checking what
> the
> >> context says.
> >
> > Note that this can be somewhat tricky. For example, most Linux drivers
> > report versions like "1.4 (Mesa 2.1)" - first is GLX, followed by OpenGL.
>
> Actually, the first is OpenGL and the second is the Mesa library,
> analogous to other platforms.  If some distro does it otherwise, it's
> violating the GL spec (section 6.1.11, "Pointer and String Queries").

I stand corrected. Just checked Mesa and the version string is "2.1 Mesa
7.0.3". I am positive that Mesa 6.x returned a string in a different format
(because I had to fix my naive parser), but I don't have a distro at hand to
check.

>
>
> >> > By the way, why not layer GLE on top of GLFW?
> >
> >> What exactly do you mean by layering GLE on top of GLFW? Do you mean
> that
> >> GLE should be called by GLFW? I don't think that's such a good idea.
> >
> > The other way round: have GLE call glfwGetAddress to simplify things.
> Note
> > that this should work even if the context was *not* created through GLFW.
>
> No, it won't.  GLFW doesn't allow that call unless it owns the context.

Really? All I can think is why was it implemented like this? As long as
[wgl/glx/agl]GetCurrentContext returns something, [wgl/glx/agl]GetAddress
should be safe to call.
Ah, anyway, glfwGetAddress should be simple enough to reimplement.

StApostol wrote:
>> I suppose we can determine the version automatically, by checking what the
>> context says.
>
> Note that this can be somewhat tricky. For example, most Linux drivers
> report versions like "1.4 (Mesa 2.1)" - first is GLX, followed by OpenGL.

Actually, the first is OpenGL and the second is the Mesa library,
analogous to other platforms.  If some distro does it otherwise, it's
violating the GL spec (section 6.1.11, "Pointer and String Queries").

>> > By the way, why not layer GLE on top of GLFW?
>
>> What exactly do you mean by layering GLE on top of GLFW? Do you mean that
>> GLE should be called by GLFW? I don't think that's such a good idea.
>
> The other way round: have GLE call glfwGetAddress to simplify things. Note
> that this should work even if the context was *not* created through GLFW.

No, it won't.  GLFW doesn't allow that call unless it owns the context.

Regards,
elmindreda

StApostol wrote:
>
> > I suppose we can determine the version automatically, by checking 
> what the context says.
>
> Note that this can be somewhat tricky. For example, most Linux drivers 
> report versions like "1.4 (Mesa 2.1)" - first is GLX, followed by OpenGL.
>
Then they should be changed. The OpenGL Specification is very clear on 
this matter:

[spec]
The VERSION and SHADING LANGUAGE VERSION strings are laid out as follows:

<version number><space><vendor-specific information>

The version number is either of the form major number.minor number or 
major number.minor number.release number, where the numbers all have one 
or more digits. The release number and vendor specific information are 
optional. However, if present, then they pertain to the server and their 
format and contents are implementation dependent.

GetString returns the version number (in the VERSION string) and the 
extension names (in the EXTENSIONS string) that can be supported by the 
current GL context. Thus, if the client and server support different 
versions and/or extensions, a compatible version and list of extensions 
is returned.
[/spec]

If they aren't following that, then that's a problem with most Linux 
drivers.
>
> > gleLoadFunctions(GLint majorVersion, GLint minorVersion);
>
> > This will load all functions and extensions up to the given GL version.
>
> What about non-core functions? Things like ARB, EXT, etc.
>
"will load all functions and extensions". That includes extensions.
>
> > > By the way, why not layer GLE on top of GLFW?
>
> > What exactly do you mean by layering GLE on top of GLFW? Do you mean 
> that GLE should be called by GLFW? I don't think that's such a good idea.
>
> The other way round: have GLE call glfwGetAddress to simplify things. 
> Note that this should work even if the context was *not* created 
> through GLFW.
>
That's not a terrible idea, but I would be hesitant to make GLE 
dependent on GLFW. Even in that small way. It would be better to bring 
the glfwGetAddress function into GLE itself.

> Windows defines its function entrypoints for the
> stuff in gl.h, not as function pointers, but as live functions. I doubt
> that wglGetExtension will work for them. So I'm not entirely sure how to
> go about handling this part. Any suggestions?

You are right regarding wglGetExtension not working with these functions (or
at least not consistently). To make matters worse, different platforms
expose different subsets dynamically, making things tricky.

Solution:

0. Define all signatures. Define static imports for all core functions (i.e.
versions 1.0-3.0). These are not exposed to the user.

1. Define all functions as function pointers. This is the public API.

2. Load each function dynamically (wgl/glx/aglGetAddress). If the function
pointer is *not* -1, 0, 1, 2 or 3 use it. If it is and the function is core,
use the relevant static export instead. Otherwise "arm" the pointer with
NULL.

I am using this method in Tao/OpenTK with success. It works on all platforms
and is reliable.

Notes:

a. Some nvidia drivers return invalid function pointers (-1, 1, 2, 3), so
you have to take this into account.

b. On windows, different contexts may return different function pointers.
This is normally not an issue, as it only happens between different
renderers (e.g. microsoft GDI and an accelerated context). Still, I prefer
to provide a "reload" function to the user in case it's needed.

> I suppose we can determine the version automatically, by checking what the
context says.

Note that this can be somewhat tricky. For example, most Linux drivers
report versions like "1.4 (Mesa 2.1)" - first is GLX, followed by OpenGL.

> gleLoadFunctions(GLint majorVersion, GLint minorVersion);

> This will load all functions and extensions up to the given GL version.

What about non-core functions? Things like ARB, EXT, etc.

> > By the way, why not layer GLE on top of GLFW?

> What exactly do you mean by layering GLE on top of GLFW? Do you mean that
GLE should be called by GLFW? I don't think that's such a good idea.

The other way round: have GLE call glfwGetAddress to simplify things. Note
that this should work even if the context was *not* created through GLFW.

Yes, those are different. I am generating my code based on the .spec and 
.tm files. For glGetAttribLocation, the second parameter is defined as a 
"Char" in the .spec file, which the .tm file says maps to a "GLchar".

I don't know where glext.h is getting that "const" from.

Orhun Birsoy wrote:
> There are some function signature differences between glext.h (from
> khronos) and gle_func_3_0.h, mostly functions that have const
> parameters.
>
> For example
>
> glext.h
> typedef GLint (APIENTRYP PFNGLGETATTRIBLOCATIONPROC) (GLuint program,
> const GLchar *name);
>
> gle_func_3_0.h
> typedef GLint (GLE_FUNCPTR * PFNGLGETATTRIBLOCATIONPROC)(GLuint
> program, GLchar *name);
>
>   

There are some function signature differences between glext.h (from
khronos) and gle_func_3_0.h, mostly functions that have const
parameters.

For example

glext.h
typedef GLint (APIENTRYP PFNGLGETATTRIBLOCATIONPROC) (GLuint program,
const GLchar *name);

gle_func_3_0.h
typedef GLint (GLE_FUNCPTR * PFNGLGETATTRIBLOCATIONPROC)(GLuint
program, GLchar *name);

-- 
Orhun Birsoy

2008	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (248)	Sep (51)	Oct (9)	Nov (3)	Dec
2009	Jan	Feb (1)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (1)	Nov	Dec

glsdk-devel Mailing List for OpenGL Software Development Kit

Utility libraries for working with OpenGL.

glsdk-devel — Main development list for the OpenGL SDK