On Sat, Jan 14, 2012 at 4:23 AM, Brice Thurin <bpsthurin@gmail.com> wrote:
Dear Ian,

Thank you for your reply. What I do not understand is that most of this code work fine when I am using Pyopengl with GLUT but it fails when I use is with a pyglet window?
Dunno.  You probably changed something small, or maybe there are small bugs in the PyOpenGL/PyGlet layers that lead to inconsistencies.  

I am intending to apply a gaussian filter with a shader once I got this bit working. It is why I am using glFloat. I thought the maximum value in that case would be 1.0.
Actually, I'm not sure why it wanted something in the range [0.0,255.0].  Perhaps one of those small bugs, eh?  Anyway, that refers to the datatype of what you pass in.  The texture you got almost certainly only has 8-bits duplicated four times, so you got no extra precision.

You could use GL_LUMINANCE16 or something, but I recommend you look into using the internal format flags GL_RGB[A]{16|32}F_ARB.  These are floating-point texture extensions (import from OpenGL.GL.ARB.texture_float).  Note that, if you want to render to them, you need to either specially set up your rendering context (not sure how in PyGlet) or, the better choice, use a framebuffer object.

-Don't use GL_LUMINANCE.  Use GL_RGB, and GL_RGBA.  If you're all for speed and are feeling up to it, always use GL_BGRA, because that's often how the GPU represents it internally.
- Could you tell me why I should not use GL_LUMINANCE
Well, it's not so much that you shouldn't use it, as there's no real need.  As I said, internally textures are often represented as GL_RGBA (and ALL textures WILL be represented as 4 channels, with almost always 8 bits each).  As per the documentation, GL_LUMINANCE duplicates the values.  So it would be more clear (and a touch faster at runtime) to just use GL_RGB in the first place.  And, if you use GL_RGB, you don't have to worry about writing any extra code when you start wanting to put actual color in your textures.