pyopengl-users — Discussion of all PyOpenGL matters.

[PyOpenGL-Users] ATI Card Flipping FBO Texture

[Ian M. <geo...@gm...>]

Hello,

I have an NVidia GeForce 8400M GS.  I have recently implemented an
application that uses FBOs extensively.  The application is available here:
http://www.mediafire.com/download.php?z2xkwyjmmzm.  It works excellently for
me.  It should look like: http://img7.imageshack.us/img7/6495/image1gsh.png.
My friend, on an ATI Mobility Radeon HD 2300, is getting the texture
vertically flipped: http://img3.imageshack.us/img3/3637/image2sle.png.  I
have no idea why it is happening.  As a check, I had him manually flip the
texture, which visually fixed the problem:
vec2 coords = coord.st/coord.q;
value = (coord.p/coord.q<=texture2D(shadtex,vec2(coords.x,1.0-coords.y)).r)
? 1.0:0.0;
instead of:
value = (coord.p/coord.q<=texture2DProj(shadtex,coord).r) ? 1.0:0.0;
The issue is annoying me.  How can it be "fixed" the real way--e.g., not a
hack?

Thanks,
Ian

Re: [PyOpenGL-Users] glGetUniformLocation causes segmentation faults

[Ian M. <geo...@gm...>]

Hello,

If you haven't already, try:

glGetProgramInfoLog(program)
glGetInfoLogARB(program)

Also, wx might be confounding your results.  If you're just trying to learn
shaders, I recommend
http://bazaar.launchpad.net/~mcfletch/pyopengl-demo/trunk/annotate/2?file_id=shader_test.py-20080923005140-67c17kywpwxa2usj-25<http://bazaar.launchpad.net/%7Emcfletch/pyopengl-demo/trunk/annotate/2?file_id=shader_test.py-20080923005140-67c17kywpwxa2usj-25>

This might be a good time to bring up a long standing issue.  Personally,
I'm getting null function errors--the only way I've gotten shaders to work
is with ARB, and I'm not sure why.

Ian

Re: [PyOpenGL-Users] glGetUniformLocation causes segmentation faults

[richard h. <rha...@cs...>]

I moved over to my desktop which has a  GeForce GTX 260, and is also
running 64 bit Ubuntu 9.04.  This machine also segfaults when I call
glGetUniformLocation.  As I expected, the enumeration of the uniform
resources changed between my Intel card and this GeForce.  The GeForce
enumerates as follows for me:

glUniform3f(0, 1.0, 0.3, 0.2)
glUniform3f(4, 0.85, 0.86, 0.84)
glUniform2f(2, 0.30, 0.15)
glUniform2f(1, 0.90, 0.85)
glUniform3f(3, 0.0, 0.0, 4.0)

Also I installed pyopengl using the python-opengl package in apt if
that might help at all.

I also added calls to glGetError, but it appears that nothing is
failing.  Below is an excerpt of my changes:

------------------------------------
...
vert = glCreateShader(GL_VERTEX_SHADER)
print "glGetError - glCreateShader: ", glGetError()
frag = glCreateShader(GL_FRAGMENT_SHADER)
print "glGetError - glCreateShader: ", glGetError()

glShaderSource(vert, self.vert_src)
print "glGetError - glShaderSource: ", glGetError()
glShaderSource(frag, self.frag_src)
print "glGetError - glShaderSource: ", glGetError()

glCompileShader(vert)
print "glGetError - glCompileShader: ", glGetError()
glCompileShader(frag)
print "glGetError - glCompileShader: ", glGetError()

program = glCreateProgram()
print "glGetError - glCreateProgram: ", glGetError()
glAttachShader(program, vert)
print "glGetError - glAttachShader: ", glGetError()
glAttachShader(program, frag)
print "glGetError - glAttachShader: ", glGetError()

glValidateProgram(program)
print "glGetError - glValidateProgram: ", glGetError()
glLinkProgram(program)
print "glGetError - glLinkProgram: ", glGetError()
glUseProgram(program)
print "glGetError - glUseProgram: ", glGetError()

# Any of the following will cause a segmentation
# fault.  (due to the call to glGetUniformLocation)
glUniform3f(self.getUniLoc(program, "BrickColor"), 1.0, 0.3, 0.2)
...
------------------------------------

which now gives me the output:
GL_VENDOR:  NVIDIA Corporation
GL_RENDERER:  GeForce GTX 260/PCI/SSE2
GL_VERSION:  3.0.0 NVIDIA 180.44
...
glGetError - glCreateShader:  0
glGetError - glCreateShader:  0
glGetError - glShaderSource:  0
glGetError - glShaderSource:  0
glGetError - glCompileShader:  0
glGetError - glCompileShader:  0
glGetError - glCreateProgram:  0
glGetError - glAttachShader:  0
glGetError - glAttachShader:  0
glGetError - glValidateProgram:  0
glGetError - glLinkProgram:  0
glGetError - glUseProgram:  0
Segmentation fault

Thanks for the help,
Richard

On Thu, Jun 25, 2009 at 10:24 AM, Mike C.
Fletcher<mcf...@vr...> wrote:
> richard hawkins wrote:
>> Hello all,
>>
>> I am having some trouble with a simple test application.  I am mixing
>> one of the nehe tutorials with the brick example from the OpenGL
>> orange book.
>>
>> Here is my problem, all calls to glGetUniformLocation result in a
>> segmentation fault.  I removed all calls to glGetUniformLocation, and
>> played around with guessing the appropriate values.  Doing this I was
>> able to get the shader to render correctly, but is not a good way to
>> do things.
>>
> Interesting, my machine bombs out (not a segfault, just an invalid
> operation) when trying to do glUseProgram.  I'd suspect that something
> is failing during compilation and you just aren't retrieving a
> compilation error message to see the failure?  Don't have time to track
> it down this morning (already late for meeting).  (Tested on an Ubuntu
> 9.04 64-bit with AMD Radeon, btw).
>
> Good luck,
> Mike
>
> --
> ________________________________________________
>  Mike C. Fletcher
>  Designer, VR Plumber, Coder
>  http://www.vrplumber.com
>  http://blog.vrplumber.com
>
>



-- 
"People who think they know everything really annoy those of us who
know we don't" - Bjarne Stroustrup

Re: [PyOpenGL-Users] glGetUniformLocation causes segmentation faults

[Mike C. F. <mcf...@vr...>]

richard hawkins wrote:
> Hello all,
>
> I am having some trouble with a simple test application.  I am mixing
> one of the nehe tutorials with the brick example from the OpenGL
> orange book.
>
> Here is my problem, all calls to glGetUniformLocation result in a
> segmentation fault.  I removed all calls to glGetUniformLocation, and
> played around with guessing the appropriate values.  Doing this I was
> able to get the shader to render correctly, but is not a good way to
> do things.
>   
Interesting, my machine bombs out (not a segfault, just an invalid
operation) when trying to do glUseProgram.  I'd suspect that something
is failing during compilation and you just aren't retrieving a
compilation error message to see the failure?  Don't have time to track
it down this morning (already late for meeting).  (Tested on an Ubuntu
9.04 64-bit with AMD Radeon, btw).

Good luck,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

[PyOpenGL-Users] glGetUniformLocation causes segmentation faults

[richard h. <rha...@cs...>]

Hello all,

I am having some trouble with a simple test application.  I am mixing
one of the nehe tutorials with the brick example from the OpenGL
orange book.

Here is my problem, all calls to glGetUniformLocation result in a
segmentation fault.  I removed all calls to glGetUniformLocation, and
played around with guessing the appropriate values.  Doing this I was
able to get the shader to render correctly, but is not a good way to
do things.

I am running Ubuntu 9.04 64bit

uname -a output: Linux starscream 2.6.28-11-generic #42-Ubuntu SMP Fri
Apr 17 01:58:03 UTC 2009 x86_64 GNU/Linux

Below I have listed the output from calling glGetString on my box, I
have also included my version of the program.

Any assistance would be appreciated.

Thanks,
Richard


GL_VENDOR:  Tungsten Graphics, Inc
GL_RENDERER:  Mesa DRI Intel(R) 965GM GEM 20090326 2009Q1 RC2
GL_VERSION:  2.0 Mesa 7.4
GL_EXTENSIONS:  GL_ARB_depth_texture GL_ARB_draw_buffers
GL_ARB_fragment_program GL_ARB_fragment_program_shadow
GL_ARB_fragment_shader GL_ARB_multisample GL_ARB_multitexture
GL_ARB_occlusion_query GL_ARB_pixel_buffer_object
GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shader_objects
GL_ARB_shading_language_100 GL_ARB_shadow GL_ARB_texture_border_clamp
GL_ARB_texture_compression GL_ARB_texture_cube_map
GL_ARB_texture_env_add GL_ARB_texture_env_combine
GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3
GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two
GL_ARB_texture_rectangle GL_ARB_transpose_matrix
GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader
GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color
GL_EXT_blend_equation_separate GL_EXT_blend_func_separate
GL_EXT_blend_logic_op GL_EXT_blend_minmax GL_EXT_blend_subtract
GL_EXT_clip_volume_hint GL_EXT_cull_vertex
GL_EXT_compiled_vertex_array GL_EXT_copy_texture
GL_EXT_draw_range_elements GL_EXT_framebuffer_object GL_EXT_fog_coord
GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil
GL_EXT_packed_pixels GL_EXT_pixel_buffer_object
GL_EXT_point_parameters GL_EXT_polygon_offset GL_EXT_rescale_normal
GL_EXT_secondary_color GL_EXT_separate_specular_color
GL_EXT_shadow_funcs GL_EXT_stencil_wrap GL_EXT_subtexture
GL_EXT_texture GL_EXT_texture3D GL_EXT_texture_edge_clamp
GL_EXT_texture_env_add GL_EXT_texture_env_combine
GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic
GL_EXT_texture_lod_bias GL_EXT_texture_object GL_EXT_texture_rectangle
GL_EXT_texture_sRGB GL_EXT_vertex_array
GL_3DFX_texture_compression_FXT1 GL_APPLE_client_storage
GL_APPLE_packed_pixels GL_ATI_blend_equation_separate
GL_ATI_texture_env_combine3 GL_ATI_separate_stencil
GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat
GL_INGR_blend_func_separate GL_MESA_pack_invert GL_MESA_ycbcr_texture
GL_MESA_window_pos GL_NV_blend_square GL_NV_light_max_exponent
GL_NV_point_sprite GL_NV_texture_rectangle GL_NV_texgen_reflection
GL_NV_vertex_program GL_NV_vertex_program1_1 GL_OES_read_format
GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp
GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SGIX_depth_texture
GL_SUN_multi_draw_arrays

#--- pysqr.py ---------------------------
#!/usr/bin/python

import wx
from wx import glcanvas

from OpenGL.GL import *
from OpenGL.GLU import *
from OpenGL.GLUT import *

from OpenGL.GL.ARB.shader_objects import *
from OpenGL.GL.ARB.vertex_shader import *
from OpenGL.GL.ARB.fragment_shader import *

class GLFrame(wx.Frame):
   """A simple class for using OpenGL with wxPython."""

   vert_src = """
uniform vec3 LightPosition;

const float SpecularContribution = 0.3;
const float DiffuseContribution  = 1.0 - SpecularContribution;

varying float LightIntensity;
varying vec2  MCposition;

void main(void)
{
   vec3 ecPosition = vec3 (gl_ModelViewMatrix * gl_Vertex);
   vec3 tnorm      = normalize(gl_NormalMatrix * gl_Normal);
   vec3 lightVec   = normalize(LightPosition - ecPosition);
   vec3 reflectVec = reflect(-lightVec, tnorm);
   vec3 viewVec    = normalize(-ecPosition);
   float diffuse   = max(dot(lightVec, tnorm), 0.0);
   float spec      = 0.0;

   if (diffuse > 0.0)
   {
       spec = max(dot(reflectVec, viewVec), 0.0);
       spec = pow(spec, 16.0);
   }

   LightIntensity  = DiffuseContribution * diffuse +
                     SpecularContribution * spec;

   MCposition      = gl_Vertex.xy;
   gl_Position     = ftransform();
}"""

   frag_src = """
uniform vec3  BrickColor, MortarColor;
uniform vec2  BrickSize;
uniform vec2  BrickPct;

varying vec2  MCposition;
varying float LightIntensity;

void main(void)
{
   vec3  color;
   vec2  position, useBrick;

   position = MCposition / BrickSize;

   if (fract(position.y * 0.5) > 0.5)
       position.x += 0.5;

   position = fract(position);

   useBrick = step(position, BrickPct);

   color  = mix(MortarColor, BrickColor, useBrick.x * useBrick.y);
   color *= LightIntensity;
   gl_FragColor = vec4 (color, 1.0);
}"""

   def __init__(self, parent, id, title, pos=wx.DefaultPosition,
                size=wx.DefaultSize, style=wx.DEFAULT_FRAME_STYLE,
                name='frame'):
       #
       # Forcing a specific style on the window.
       #   Should this include styles passed?
       style = wx.DEFAULT_FRAME_STYLE | wx.NO_FULL_REPAINT_ON_RESIZE

       super(GLFrame, self).__init__(parent, id, title, pos, size, style, name)

       self.GLinitialized = False
       attribList = (glcanvas.WX_GL_RGBA, # RGBA
                     glcanvas.WX_GL_DOUBLEBUFFER, # Double Buffered
                     glcanvas.WX_GL_DEPTH_SIZE, 24) # 24 bit

       #
       # Create the canvas
       self.canvas = glcanvas.GLCanvas(self, attribList=attribList)

       #
       # Set the event handlers.
       self.canvas.Bind(wx.EVT_ERASE_BACKGROUND,
           self.processEraseBackgroundEvent)
       self.canvas.Bind(wx.EVT_SIZE, self.processSizeEvent)
       self.canvas.Bind(wx.EVT_PAINT, self.processPaintEvent)

   #
   # Canvas Proxy Methods

   def GetGLExtents(self):
       """Get the extents of the OpenGL canvas."""
       return self.canvas.GetClientSize()

   def SwapBuffers(self):
       """Swap the OpenGL buffers."""
       self.canvas.SwapBuffers()

   #
   # wxPython Window Handlers

   def processEraseBackgroundEvent(self, event):
       """Process the erase background event."""
       pass # Do nothing, to avoid flashing on MSWin

   def processSizeEvent(self, event):
       """Process the resize event."""
       if self.canvas.GetContext():
           # Make sure the frame is shown before calling SetCurrent.
           self.Show()
           self.canvas.SetCurrent()

           size = self.GetGLExtents()
           self.OnReshape(size.width, size.height)
           self.canvas.Refresh(False)
       event.Skip()

   def processPaintEvent(self, event):
       """Process the drawing event."""
       self.canvas.SetCurrent()

       # This is a 'perfect' time to initialize OpenGL ... only if we need to
       if not self.GLinitialized:
           self.OnInitGL()
           self.GLinitialized = True

       self.OnDraw()
       event.Skip()

   #
   # GLFrame OpenGL Event Handlers
   def getUniLoc(self, program, name):
       loc = glGetUniformLocation(program, name);
       if (loc == -1):
           print "No such uniform named ", name
       return loc

   def OnInitGL(self):
       """Initialize OpenGL for use in the window."""
       print "GL_VENDOR: ", glGetString(GL_VENDOR)
       print "GL_RENDERER: ", glGetString(GL_RENDERER)
       print "GL_VERSION: ", glGetString(GL_VERSION)
       print "GL_EXTENSIONS: ", glGetString(GL_EXTENSIONS)

       glClearColor(0.0, 0.0, 0.0, 0.0)

       glMatrixMode(GL_PROJECTION)
       glLoadIdentity()
       glOrtho(-1.0, 1.0, -1.0, 1.0, -1.0, 1.0)

       glMatrixMode( GL_MODELVIEW )
       glLoadIdentity()

       vert = glCreateShader(GL_VERTEX_SHADER)
       frag = glCreateShader(GL_FRAGMENT_SHADER)

       glShaderSource(vert, self.vert_src)
       glShaderSource(frag, self.frag_src)

       glCompileShader(vert)
       glCompileShader(frag)

       program = glCreateProgram()
       glAttachShader(program, vert)
       glAttachShader(program, frag)

       glValidateProgram(program)
       glLinkProgram(program)
       glUseProgram(program)

       # Any of the following will cause a segmentation
       # fault.  (due to the call to glGetUniformLocation)
       glUniform3f(self.getUniLoc(program, "BrickColor"), 1.0, 0.3, 0.2)
       glUniform3f(self.getUniLoc(program, "MortarColor"), 0.85, 0.86, 0.84)
       glUniform2f(self.getUniLoc(program, "BrickSize"), 0.30, 0.15)
       glUniform2f(self.getUniLoc(program, "BrickPct"), 0.90, 0.85)
       glUniform3f(self.getUniLoc(program, "LightPosition"), 0.0, 0.0, 4.0)

       # These cause the shader to be rendered properly, but obviously is
       # not the right way to do things. ;)
       #glUniform3f(1, 1.0, 0.3, 0.2)
       #glUniform3f(2, 0.85, 0.86, 0.84)
       #glUniform2f(3, 0.30, 0.15)
       #glUniform2f(4, 0.90, 0.85)
       #glUniform3f(0, 0.0, 0.0, 4.0)

   def OnReshape(self, width, height):
       """Reshape the OpenGL viewport based on the dimensions of the window."""
       glViewport(0, 0, width, height)

   def OnDraw(self, *args, **kwargs):
       "Draw the window."
       glClear(GL_COLOR_BUFFER_BIT)

       glColor3f(1.0, 1.0, 1.0);
       glBegin(GL_POLYGON);
       glVertex2f(-0.5, -0.5);
       glVertex2f(-0.5, 0.5);
       glVertex2f(0.5, 0.5);
       glVertex2f(0.5, -0.5);
       glEnd();

       self.SwapBuffers()

def main():
   app = wx.App()

   frame = GLFrame(None, -1, 'GL Window')
   frame.Show()

   app.MainLoop()
   app.Destroy()

if __name__ == "__main__":
   main()
# --- end of pysqr.py ------------------------

[PyOpenGL-Users] glGetUniformLocation causes segmentation faults

[richard h. <rha...@ri...>]

Hello all,

I am having some trouble with a simple test application.  I am mixing
one of the nehe tutorials with the brick example from the OpenGL
orange book.

Here is my problem, all calls to glGetUniformLocation result in a
segmentation fault.  I removed all calls to glGetUniformLocation, and
played around with guessing the appropriate values.  Doing this I was
able to get the shader to render correctly, but is not a good way to
do things.

I am running Ubuntu 9.04 64bit

uname -a output: Linux starscream 2.6.28-11-generic #42-Ubuntu SMP Fri
Apr 17 01:58:03 UTC 2009 x86_64 GNU/Linux

Below I have listed the output from calling glGetString on my box, I
have also included my version of the program.

Any assistance would be appreciated.

Thanks,
Richard


GL_VENDOR:  Tungsten Graphics, Inc
GL_RENDERER:  Mesa DRI Intel(R) 965GM GEM 20090326 2009Q1 RC2
GL_VERSION:  2.0 Mesa 7.4
GL_EXTENSIONS:  GL_ARB_depth_texture GL_ARB_draw_buffers
GL_ARB_fragment_program GL_ARB_fragment_program_shadow
GL_ARB_fragment_shader GL_ARB_multisample GL_ARB_multitexture
GL_ARB_occlusion_query GL_ARB_pixel_buffer_object
GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shader_objects
GL_ARB_shading_language_100 GL_ARB_shadow GL_ARB_texture_border_clamp
GL_ARB_texture_compression GL_ARB_texture_cube_map
GL_ARB_texture_env_add GL_ARB_texture_env_combine
GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3
GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two
GL_ARB_texture_rectangle GL_ARB_transpose_matrix
GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_vertex_shader
GL_ARB_window_pos GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color
GL_EXT_blend_equation_separate GL_EXT_blend_func_separate
GL_EXT_blend_logic_op GL_EXT_blend_minmax GL_EXT_blend_subtract
GL_EXT_clip_volume_hint GL_EXT_cull_vertex
GL_EXT_compiled_vertex_array GL_EXT_copy_texture
GL_EXT_draw_range_elements GL_EXT_framebuffer_object GL_EXT_fog_coord
GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil
GL_EXT_packed_pixels GL_EXT_pixel_buffer_object
GL_EXT_point_parameters GL_EXT_polygon_offset GL_EXT_rescale_normal
GL_EXT_secondary_color GL_EXT_separate_specular_color
GL_EXT_shadow_funcs GL_EXT_stencil_wrap GL_EXT_subtexture
GL_EXT_texture GL_EXT_texture3D GL_EXT_texture_edge_clamp
GL_EXT_texture_env_add GL_EXT_texture_env_combine
GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic
GL_EXT_texture_lod_bias GL_EXT_texture_object GL_EXT_texture_rectangle
GL_EXT_texture_sRGB GL_EXT_vertex_array
GL_3DFX_texture_compression_FXT1 GL_APPLE_client_storage
GL_APPLE_packed_pixels GL_ATI_blend_equation_separate
GL_ATI_texture_env_combine3 GL_ATI_separate_stencil
GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat
GL_INGR_blend_func_separate GL_MESA_pack_invert GL_MESA_ycbcr_texture
GL_MESA_window_pos GL_NV_blend_square GL_NV_light_max_exponent
GL_NV_point_sprite GL_NV_texture_rectangle GL_NV_texgen_reflection
GL_NV_vertex_program GL_NV_vertex_program1_1 GL_OES_read_format
GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp
GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SGIX_depth_texture
GL_SUN_multi_draw_arrays

#--- pysqr.py ---------------------------
#!/usr/bin/python

import wx
from wx import glcanvas

from OpenGL.GL import *
from OpenGL.GLU import *
from OpenGL.GLUT import *

from OpenGL.GL.ARB.shader_objects import *
from OpenGL.GL.ARB.vertex_shader import *
from OpenGL.GL.ARB.fragment_shader import *

class GLFrame(wx.Frame):
    """A simple class for using OpenGL with wxPython."""

    vert_src = """
uniform vec3 LightPosition;

const float SpecularContribution = 0.3;
const float DiffuseContribution  = 1.0 - SpecularContribution;

varying float LightIntensity;
varying vec2  MCposition;

void main(void)
{
    vec3 ecPosition = vec3 (gl_ModelViewMatrix * gl_Vertex);
    vec3 tnorm      = normalize(gl_NormalMatrix * gl_Normal);
    vec3 lightVec   = normalize(LightPosition - ecPosition);
    vec3 reflectVec = reflect(-lightVec, tnorm);
    vec3 viewVec    = normalize(-ecPosition);
    float diffuse   = max(dot(lightVec, tnorm), 0.0);
    float spec      = 0.0;

    if (diffuse > 0.0)
    {
        spec = max(dot(reflectVec, viewVec), 0.0);
        spec = pow(spec, 16.0);
    }

    LightIntensity  = DiffuseContribution * diffuse +
                      SpecularContribution * spec;

    MCposition      = gl_Vertex.xy;
    gl_Position     = ftransform();
}"""

    frag_src = """
uniform vec3  BrickColor, MortarColor;
uniform vec2  BrickSize;
uniform vec2  BrickPct;

varying vec2  MCposition;
varying float LightIntensity;

void main(void)
{
    vec3  color;
    vec2  position, useBrick;

    position = MCposition / BrickSize;

    if (fract(position.y * 0.5) > 0.5)
        position.x += 0.5;

    position = fract(position);

    useBrick = step(position, BrickPct);

    color  = mix(MortarColor, BrickColor, useBrick.x * useBrick.y);
    color *= LightIntensity;
    gl_FragColor = vec4 (color, 1.0);
}"""

    def __init__(self, parent, id, title, pos=wx.DefaultPosition,
                 size=wx.DefaultSize, style=wx.DEFAULT_FRAME_STYLE,
                 name='frame'):
        #
        # Forcing a specific style on the window.
        #   Should this include styles passed?
        style = wx.DEFAULT_FRAME_STYLE | wx.NO_FULL_REPAINT_ON_RESIZE

        super(GLFrame, self).__init__(parent, id, title, pos, size, style, name)

        self.GLinitialized = False
        attribList = (glcanvas.WX_GL_RGBA, # RGBA
                      glcanvas.WX_GL_DOUBLEBUFFER, # Double Buffered
                      glcanvas.WX_GL_DEPTH_SIZE, 24) # 24 bit

        #
        # Create the canvas
        self.canvas = glcanvas.GLCanvas(self, attribList=attribList)

        #
        # Set the event handlers.
        self.canvas.Bind(wx.EVT_ERASE_BACKGROUND,
            self.processEraseBackgroundEvent)
        self.canvas.Bind(wx.EVT_SIZE, self.processSizeEvent)
        self.canvas.Bind(wx.EVT_PAINT, self.processPaintEvent)

    #
    # Canvas Proxy Methods

    def GetGLExtents(self):
        """Get the extents of the OpenGL canvas."""
        return self.canvas.GetClientSize()

    def SwapBuffers(self):
        """Swap the OpenGL buffers."""
        self.canvas.SwapBuffers()

    #
    # wxPython Window Handlers

    def processEraseBackgroundEvent(self, event):
        """Process the erase background event."""
        pass # Do nothing, to avoid flashing on MSWin

    def processSizeEvent(self, event):
        """Process the resize event."""
        if self.canvas.GetContext():
            # Make sure the frame is shown before calling SetCurrent.
            self.Show()
            self.canvas.SetCurrent()

            size = self.GetGLExtents()
            self.OnReshape(size.width, size.height)
            self.canvas.Refresh(False)
        event.Skip()

    def processPaintEvent(self, event):
        """Process the drawing event."""
        self.canvas.SetCurrent()

        # This is a 'perfect' time to initialize OpenGL ... only if we need to
        if not self.GLinitialized:
            self.OnInitGL()
            self.GLinitialized = True

        self.OnDraw()
        event.Skip()

    #
    # GLFrame OpenGL Event Handlers
    def getUniLoc(self, program, name):
        loc = glGetUniformLocation(program, name);
        if (loc == -1):
            print "No such uniform named ", name
        return loc

    def OnInitGL(self):
        """Initialize OpenGL for use in the window."""
        print "GL_VENDOR: ", glGetString(GL_VENDOR)
        print "GL_RENDERER: ", glGetString(GL_RENDERER)
        print "GL_VERSION: ", glGetString(GL_VERSION)
        print "GL_EXTENSIONS: ", glGetString(GL_EXTENSIONS)

        glClearColor(0.0, 0.0, 0.0, 0.0)

        glMatrixMode(GL_PROJECTION)
        glLoadIdentity()
        glOrtho(-1.0, 1.0, -1.0, 1.0, -1.0, 1.0)

        glMatrixMode( GL_MODELVIEW )
        glLoadIdentity()

        vert = glCreateShader(GL_VERTEX_SHADER)
        frag = glCreateShader(GL_FRAGMENT_SHADER)

        glShaderSource(vert, self.vert_src)
        glShaderSource(frag, self.frag_src)

        glCompileShader(vert)
        glCompileShader(frag)

        program = glCreateProgram()
        glAttachShader(program, vert)
        glAttachShader(program, frag)

        glValidateProgram(program)
        glLinkProgram(program)
        glUseProgram(program)

        # Any of the following will cause a segmentation
        # fault.  (due to the call to glGetUniformLocation)
        glUniform3f(self.getUniLoc(program, "BrickColor"), 1.0, 0.3, 0.2)
        glUniform3f(self.getUniLoc(program, "MortarColor"), 0.85, 0.86, 0.84)
        glUniform2f(self.getUniLoc(program, "BrickSize"), 0.30, 0.15)
        glUniform2f(self.getUniLoc(program, "BrickPct"), 0.90, 0.85)
        glUniform3f(self.getUniLoc(program, "LightPosition"), 0.0, 0.0, 4.0)

        # These cause the shader to be rendered properly, but obviously is
        # not the right way to do things. ;)
        #glUniform3f(1, 1.0, 0.3, 0.2)
        #glUniform3f(2, 0.85, 0.86, 0.84)
        #glUniform2f(3, 0.30, 0.15)
        #glUniform2f(4, 0.90, 0.85)
        #glUniform3f(0, 0.0, 0.0, 4.0)

    def OnReshape(self, width, height):
        """Reshape the OpenGL viewport based on the dimensions of the window."""
        glViewport(0, 0, width, height)

    def OnDraw(self, *args, **kwargs):
        "Draw the window."
        glClear(GL_COLOR_BUFFER_BIT)

        glColor3f(1.0, 1.0, 1.0);
        glBegin(GL_POLYGON);
        glVertex2f(-0.5, -0.5);
        glVertex2f(-0.5, 0.5);
        glVertex2f(0.5, 0.5);
        glVertex2f(0.5, -0.5);
        glEnd();

        self.SwapBuffers()

def main():
    app = wx.App()

    frame = GLFrame(None, -1, 'GL Window')
    frame.Show()

    app.MainLoop()
    app.Destroy()

if __name__ == "__main__":
    main()
# --- end of pysqr.py ------------------------

Re: [PyOpenGL-Users] Textures Different Every Time!

[Ian M. <geo...@gm...>]

Cool thanks,
-I

Re: [PyOpenGL-Users] Textures Different Every Time!

[Mike C. F. <mcf...@vr...>]

Ian Mallett wrote:
> I think I figured out the problem.  The array wasn't defining some of
> the voxels, so they were random (as in empty memory?). 
> glPixelStoref(GL_UNPACK_ALIGNMENT,1) fixes it.
Ah, and I think I know why it only failed with 3-d textures (would have
failed with 1D and 4D too, actually).  The PyOpenGL wrapper was only
setting unpack alignment for the 2D case.  It actually does a lot of
configuration to make the operation "natural" for Python code, but it
wasn't doing this config for the non-2D versions.  I've checked in code
to always do the pack alignment setting in the "traditional" (non-raw)
API.  If you want to test with that, pull from bzr.

HTH,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

Re: [PyOpenGL-Users] Textures Different Every Time!

[Mike C. F. <mcf...@vr...>]

Ian Mallett wrote:
> Hi,
>
> My 3D texture implementation is still messed up.  The current method I
> tried fails when depth != 1.  My new code for making the texture is
> extremely simple:
...
> Yet, when the program is run, the texture is different from the
> previous time it was run!  What is going on?  I've attached the
> program that causes the issue.
I always get exactly the same colours on each run.  I'm on an Radeon HD
3650 on Linux using the proprietary drivers.

Sorry I don't have more advice,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

Re: [PyOpenGL-Users] 3D Textures

[Ian M. <geo...@gm...>]

The issue is caused by texture wrapping (fix by clamping to edge).  Anyone
know where I can get some 3D textures?

Re: [PyOpenGL-Users] 3D Textures

[Ian M. <geo...@gm...>]

I seem to have made an improvement.  There's still weird noise though on the
four sides (texture depth changes).  Here's the updated file, showing the
issue.

Re: [PyOpenGL-Users] 3D Textures

[Ian M. <geo...@gm...>]

Here's a simple example, showing my problem.
Ian

Re: [PyOpenGL-Users] 3D Textures

[Ian M. <geo...@gm...>]

Hi,

I've been trying to get 3D textures working in PyOpenGL.  I tried a simple
2D image (depth = 1).  The source image (which I choose randomly) is
here<http://www.savvyhousekeeping.com/wp-content/uploads/2009/01/cheese.jpg>.


texture3darray = pygame.surfarray.array3d(#pygame.Surface)
data = Numeric.array(Numeric.ravel(texture3darray),"uint8")

texture = glGenTextures(1)
glBindTexture(GL_TEXTURE_3D,texture)
glTexImage3D(GL_TEXTURE_3D,0,GL_RGB,480,342,1,0,GL_RGB,GL_UNSIGNED_BYTE,data)
glTexParameterf(paramtype,GL_TEXTURE_MIN_FILTER,GL_LINEAR)
glTexParameterf(paramtype,GL_TEXTURE_MAG_FILTER,GL_LINEAR)

I tried using this code to texture a rectangular solid, but I get an
incorrect result--see
here<http://img20.imageshack.us/img20/3905/image1dsz.png>.
 Here's the code for the solid:

#Inside a function
box = glGenLists(1)
glNewList(box,GL_COMPILE)
glDisable(GL_TEXTURE_2D)
glEnable(GL_TEXTURE_3D)
glSelectTexture(GL_TEXTURE_3D,texture)
glBegin(GL_QUADS)
# Right face
if normalflip: glNormal3f( 1.0, 0.0, 0.0)
else: glNormal3f(-1.0, 0.0, 0.0)
glTexCoord3f(1.0, 1.0, 1.0); glVertex3f( size[0],  size[1],  size[2])
glTexCoord3f(1.0, 0.0, 1.0); glVertex3f( size[0], -size[1],  size[2])
glTexCoord3f(1.0, 0.0, 0.0); glVertex3f( size[0], -size[1], -size[2])
glTexCoord3f(1.0, 1.0, 0.0); glVertex3f( size[0],  size[1], -size[2])
# Left Face
if normalflip: glNormal3f(-1.0, 0.0, 0.0)
else: glNormal3f( 1.0, 0.0, 0.0)
glTexCoord3f(0.0, 1.0, 1.0); glVertex3f(-size[0],  size[1],  size[2])
glTexCoord3f(0.0, 1.0, 0.0); glVertex3f(-size[0],  size[1], -size[2])
glTexCoord3f(0.0, 0.0, 0.0); glVertex3f(-size[0], -size[1], -size[2])
glTexCoord3f(0.0, 0.0, 1.0); glVertex3f(-size[0], -size[1],  size[2])
# Top Face
if normalflip: glNormal3f( 0.0, 1.0, 0.0)
else: glNormal3f( 0.0, -1.0, 0.0)
glTexCoord3f(0.0, 1.0, 0.0); glVertex3f(-size[0],  size[1], -size[2])
glTexCoord3f(0.0, 1.0, 1.0); glVertex3f(-size[0],  size[1],  size[2])
glTexCoord3f(1.0, 1.0, 1.0); glVertex3f( size[0],  size[1],  size[2])
glTexCoord3f(1.0, 1.0, 0.0); glVertex3f( size[0],  size[1], -size[2])
# Bottom Face
if normalflip: glNormal3f( 0.0,-1.0, 0.0)
else: glNormal3f( 0.0, 1.0, 0.0)
glTexCoord3f(1.0, 0.0, 1.0); glVertex3f( size[0], -size[1],  size[2])
glTexCoord3f(0.0, 0.0, 1.0); glVertex3f(-size[0], -size[1],  size[2])
glTexCoord3f(0.0, 0.0, 0.0); glVertex3f(-size[0], -size[1], -size[2])
glTexCoord3f(1.0, 0.0, 0.0); glVertex3f( size[0], -size[1], -size[2])
# Front Face
if normalflip: glNormal3f( 0.0, 0.0,-1.0)
else: glNormal3f( 0.0, 0.0, 1.0)
glTexCoord3f(1.0, 1.0, 0.0); glVertex3f( size[0],  size[1], -size[2])
glTexCoord3f(1.0, 0.0, 0.0); glVertex3f( size[0], -size[1], -size[2])
glTexCoord3f(0.0, 0.0, 0.0); glVertex3f(-size[0], -size[1], -size[2])
glTexCoord3f(0.0, 1.0, 0.0); glVertex3f(-size[0],  size[1], -size[2])
# Back Face
if normalflip: glNormal3f( 0.0, 0.0, 1.0)
else: glNormal3f( 0.0, 0.0,-1.0)
glTexCoord3f(0.0, 0.0, 1.0); glVertex3f(-size[0], -size[1],  size[2])
glTexCoord3f(1.0, 0.0, 1.0); glVertex3f( size[0], -size[1],  size[2])
glTexCoord3f(1.0, 1.0, 1.0); glVertex3f( size[0],  size[1],  size[2])
glTexCoord3f(0.0, 1.0, 1.0); glVertex3f(-size[0],  size[1],  size[2])
glEnd()
glDisable(GL_TEXTURE_3D)
glEnable(GL_TEXTURE_2D)
glEndList()

Why am I not seeing the rectangular solid be textured properly?  It should
look like the 2D image on the top and bottom and the edges of the image on
the sides of the box, right?

Ian

Re: [PyOpenGL-Users] access opengl thru c++

[axel m. <mi...@ho...>]

That solved my problem, and thank you so much for your quick reply :-)






> Date: Sat, 6 Jun 2009 18:31:53 -0400
> From: mcf...@vr...
> To: mi...@ho...
> CC: pyo...@li...
> Subject: Re: [PyOpenGL-Users] access opengl thru c++
> 
> axel mårtensson wrote:
> > hello,
> > i am trying to write a simple program to display a cube.
> > my problem is however that when i run the program i can only see a
> > blue background (the background being the value of glClearColor)
> > and not the red cube.
> ...
> >     glTranslatef(-1.5f,0.0f,-6.0f);
> >     glBegin(GL_QUADS);
> >     glColor3f(1.0, 0.0, 0.0);
> >     glVertex3f(100.0, 100.0, 0.0);
> >     glVertex3f(200.0, 100.0, 0.0);
> >     glVertex3f(200.0, 200.0, 0.0);
> >     glVertex3f(100.0, 200.0, 0.0);
> >     glEnd();
> You move the camera 6 back from the 0,0,0 point, then draw something at
> 100 to the right and 100 up from 0,0,0... my expectation is that the
> geometry is off-screen.  Don't have time to be compiling things this
> afternoon, but I'd suggest drawing something at 0,0,0 first.
> 
> HTH,
> Mike
> 
> -- 
> ________________________________________________
>   Mike C. Fletcher
>   Designer, VR Plumber, Coder
>   http://www.vrplumber.com
>   http://blog.vrplumber.com
> 

_________________________________________________________________
Hitta hetaste singlarna på MSN Dejting!
http://dejting.se.msn.com/channel/index.aspx?trackingid=1002952

Re: [PyOpenGL-Users] Glut close function

[Mike C. F. <mcf...@vr...>]

Gijs wrote:
> Hello List,
>
> I tried to bind an exit-function with Glut, but the function you 
> normally use to bind your exit-function with, glutCloseFunc, does not 
> exist in Mac OS X. It's called glutWMCloseFunc in Mac OS X. Now this is 
> not much of a problem, but when I try to use glutCloseFunc, it gives me 
> the following traceback:
> Traceback (most recent call last):
>    File "./runtests.py", line 107, in <module>
>      glutCloseFunc(exitProgram)
>    File 
> "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/OpenGL/GLUT/special.py", 
> line 131, in __call__
>    File 
> "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/OpenGL/GLUT/special.py", 
> line 100, in failFunction
> OpenGL.error.NullFunctionError: Undefined GLUT callback function Close, 
> check for bool(glutCloseFunc) before calling
>
> Kind of obvious of course, but I wanted to know if there is a normal way 
> to check if this function really exists. I could check for the platform 
> I'm running the program in, but to me it seems a better solution to 
> check for the existence of this function. Even neater would be that 
> PyOpenGL binds glutWMCloseFunc to glutCloseFunc when ran in Mac OS X. 
> That would at least keep the Glut/OpenGL code platform independent.
>   
We do something similar for Win32.  Unlike all other platform-specific
stuff, this is done in the GLUT package itself, where we substitute a
call that does the correct Win32-ish thing when creating windows so that
they will be properly closed down.  If you would like to provide an
equivalent for OS X, I'm willing to include it.  The GLUT/special.py
module is where it would likely go.

Have fun,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

Re: [PyOpenGL-Users] access opengl thru c++

[Mike C. F. <mcf...@vr...>]

axel mårtensson wrote:
> hello,
> i am trying to write a simple program to display a cube.
> my problem is however that when i run the program i can only see a
> blue background (the background being the value of glClearColor)
> and not the red cube.
...
>     glTranslatef(-1.5f,0.0f,-6.0f);
>     glBegin(GL_QUADS);
>     glColor3f(1.0, 0.0, 0.0);
>     glVertex3f(100.0, 100.0, 0.0);
>     glVertex3f(200.0, 100.0, 0.0);
>     glVertex3f(200.0, 200.0, 0.0);
>     glVertex3f(100.0, 200.0, 0.0);
>     glEnd();
You move the camera 6 back from the 0,0,0 point, then draw something at
100 to the right and 100 up from 0,0,0... my expectation is that the
geometry is off-screen.  Don't have time to be compiling things this
afternoon, but I'd suggest drawing something at 0,0,0 first.

HTH,
Mike

-- 
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com

[PyOpenGL-Users] access opengl thru c++

[axel m. <mi...@ho...>]

hello,
i am trying to write a simple program to display a cube.
my problem is however that when i run the program i can only see a blue background (the background being the value of glClearColor)
and not the red cube.

note: compile the C program as a shared library and set LD_LIBRARY_PATH=/path/to/lib

python code (testGL.py):
------snip----

#!/usr/bin/python
import pygame
import sys
import os
import subprocess
import ctypes
from pygame.locals import *
screen = pygame.display.set_mode((1440, 900), HWSURFACE|OPENGL|DOUBLEBUF|FULLSCREEN)
Driver = ctypes.CDLL("testGL.so")
Driver.resize(ctypes.c_int(1440), ctypes.c_int(900))
Driver.init()
kg=True
while kg:
    for event in pygame.event.get():
        if event.type == KEYDOWN or event.type == QUIT:
            kg=False
            sys.exit()
    Driver.draw_scene()
    pygame.display.flip()

-------end snip-----

C code (testGL.c):
-----snip-----

#include <GL/gl.h>
#include <GL/glu.h>
#include <GL/glext.h>
#include <math.h>

GLvoid resize(int width, int height)
{
    glViewport(0, 0, width, height);
    glMatrixMode(GL_PROJECTION);
    glLoadIdentity();
    gluPerspective(60., (float)width/height, 1., 10000.);
    glMatrixMode(GL_MODELVIEW);
    glLoadIdentity();
}

GLvoid init()
{
    glEnable(GL_DEPTH_TEST);
    glClearColor(0.0, 0.0, 1.0, 0.0);
    glShadeModel(GL_SMOOTH);
}

GLvoid draw_scene()
{
    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);           
    glLoadIdentity();
    glTranslatef(-1.5f,0.0f,-6.0f);
    glBegin(GL_QUADS);
    glColor3f(1.0, 0.0, 0.0);
    glVertex3f(100.0, 100.0, 0.0);
    glVertex3f(200.0, 100.0, 0.0);
    glVertex3f(200.0, 200.0, 0.0); 
    glVertex3f(100.0, 200.0, 0.0); 
    glEnd();
}

-----end snip-----

_________________________________________________________________
Vårkänslor och pirr i magen? Hitta din drömpartner här!
http://dejting.se.msn.com/channel/index.aspx?trackingid=1002952

[PyOpenGL-Users] Glut close function

[Gijs <in...@bs...>]

Hello List,

I tried to bind an exit-function with Glut, but the function you 
normally use to bind your exit-function with, glutCloseFunc, does not 
exist in Mac OS X. It's called glutWMCloseFunc in Mac OS X. Now this is 
not much of a problem, but when I try to use glutCloseFunc, it gives me 
the following traceback:
Traceback (most recent call last):
   File "./runtests.py", line 107, in <module>
     glutCloseFunc(exitProgram)
   File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/OpenGL/GLUT/special.py", 
line 131, in __call__
   File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/OpenGL/GLUT/special.py", 
line 100, in failFunction
OpenGL.error.NullFunctionError: Undefined GLUT callback function Close, 
check for bool(glutCloseFunc) before calling

Kind of obvious of course, but I wanted to know if there is a normal way 
to check if this function really exists. I could check for the platform 
I'm running the program in, but to me it seems a better solution to 
check for the existence of this function. Even neater would be that 
PyOpenGL binds glutWMCloseFunc to glutCloseFunc when ran in Mac OS X. 
That would at least keep the Glut/OpenGL code platform independent.

Regards, Gijs

Re: [PyOpenGL-Users] Using glDrawElements on C-allocated data

[Gordon L. K. <gl...@uc...>]

Hello,

On Jun 3, 2009, at 5:55 AM, René Dudfield wrote:

> hi again,
>
> or if you just want to whip up a c module...
>
> the buffer interface is your friend:
>     http://docs.python.org/dev/c-api/buffer.html
>
>
> Check out the docs for this functions:
> PyObject* PyBuffer_FromMemory(void *ptr, Py_ssize_t size)
> PyObject* PyBuffer_FromReadWriteMemory(void *ptr, Py_ssize_t size)

Maybe I'm missing something about the value of this "PyBuffer", but  
ctypes is already providing everything I need to access the individual  
values in the C-allocated array.  That's how I'm currently drawing  
geometry without glDrawElements in

http://people.cs.uchicago.edu/~glk/pglt/pgltDemo.py

The values in the "norm", "xyzw", and "rgba" arrays are being accessed  
just fine.  The problem is finding a way to pass the correct pointer  
to these pre-existing buffers for glDrawElements.

> sure, but can those libraries let you pass in your own allocated data?
> Or are they not extensible in that way?  Many C libraries let you
> allocate the memory yourself, is why I asked.

The nature of the computation being implemented in the C library is  
that you don't know ahead of time how much geometry is going to be  
generated, so pre-allocation is not possible.  It represents a numeric  
search that may terminate sooner or later, depending on local data  
conditions.  The C library already handles dynamic reallocation as  
needed, and returns a buffer that is sized to fit the computation  
results.

> but, if you don't want to do it that way, or can't then you can create
> a buffer from a pointer+size, and then use it.

I'm sorry, I don't know precisely what you mean by this.

> Seems to be some ctypes wrappers here:
> http://svn.python.org/projects/ctypes/trunk/ctypeslib/ctypeslib/contrib/pythonhdr.py
>
> For the PyBuffer_FromReadWriteMemory function.  If you don't want to
> use a C module for it.

Again, I may be missing the point of this PyBuffer object, but I don't  
see how it answers the issue about how to pass the right kind of  
pointer to glDrawElements.

Would it be possible for you to indicate with some pseudocode how this  
would be used?

Thanks,
Gordon


>
>
>
>
>
>
>
> On Wed, Jun 3, 2009 at 8:44 PM, René Dudfield <re...@gm...>  
> wrote:
>>
>> hi,
>>
>> usually you can create the array in python, and then give a pointer  
>> to the C/C++/F0oLang
>>
>> Generally easiest for my mind.  That leaves the memory management  
>> in python.
>>
>> Or create the python buffers from your pointer.
>>
>>
>> Then create the slices in python, rather than using pointer  
>> arithmetic.
>>
>> eg, new_array = array[vertIdx:]
>>
>>
>>
>> cu,
>>
>> On Mon, Jun 1, 2009 at 8:37 AM, Gordon L. Kindlmann  
>> <gl...@uc...> wrote:
>>>
>>> Hello,
>>>
>>> I've recently started using PyOpenGL as the framework for re- 
>>> writing C/
>>> C++ OpenGL wrappers around an large amount of research code in C.   
>>> Its
>>> been a pleasure to have something that allows such literal  
>>> translation
>>> from the successful C/C++ OpenGL code to Python code; thanks for
>>> creating this!
>>>
>>> The main hitch I've had is in using glDrawElements.  I've looked
>>> around for answers to this, and its clear that people people using
>>> PyOpenGL are using it with geometry that is created on the python
>>> side.  In my case, all the geometry information is created on the C
>>> side, and I want to control its display from Python.
>>>
>>> The line that's causing problems is:
>>>
>>>   glDrawElements(glpt[lpld.type[primIdx]], vertCnt, GL_UNSIGNED_INT,
>>> lpld.indx + vertIdx)
>>>
>>> where lpld.indx is a ctypes-created pointer to a buffer of unsigned
>>> ints allocated and filled in C, which causes this problem:
>>>
>>>   Traceback (most recent call last):
>>>     File "pgltDemo.py", line 118, in display
>>>       pgltDraw(pgltObject, uva)
>>>     File "pgltDemo.py", line 76, in pgltDraw
>>>       GL_UNSIGNED_INT, lpld.indx + vertIdx)
>>>   TypeError: unsupported operand type(s) for +: 'LP_c_ulong' and  
>>> 'int'
>>>
>>> because apparently pointer arithmetic games aren't quite so simply  
>>> in
>>> Python.  If you just replace "lpld.indx + vertIdx" with "lpld.indx",
>>> which removes the pointer arithmetic stuff, it segfaults.  I know  
>>> that
>>> others have looked at this issue from the context of having array  
>>> data
>>> that's created via numpy:
>>>
>>> http://www.mail-archive.com/pyg...@go.../msg01356/t.py
>>>
>>> I've tried many different iterations of things like this, and I get
>>> either python errors or segfaults.
>>>
>>> Getting this to work with PyOpenGL would make a huge difference in  
>>> how
>>> I can get research work done with python, so I've taken some type to
>>> put a self-contained example online:
>>>
>>> http://people.cs.uchicago.edu/~glk/pglt/
>>>
>>> This includes a C library the generates some geometry to render,  
>>> and a
>>> ctypeslib-generated wrapper around the library.  pgltDemo.c  
>>> contains a
>>> "pgltDraw()" function that shows how I'm currently doing things
>>> without (for display lists) and with vertex arrays.  pgltDemo.py
>>> contains the same function, but the vertex array code is broken.
>>>
>>> Hopefully someone on this list will be able to spend a little time
>>> working with these examples, and figure out how to get my
>>> "pgltDemo.py" to work with vertex arrays.
>>>
>>> Thanks very much,
>>> Gordon
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
>>> is a gathering of tech-side developers & brand creativity  
>>> professionals. Meet
>>> the minds behind Google Creative Lab, Visual Complexity,  
>>> Processing, &
>>> iPhoneDevCamp as they present alongside digital heavyweights like  
>>> Barbarian
>>> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
>>> _______________________________________________
>>> PyOpenGL Homepage
>>> http://pyopengl.sourceforge.net
>>> _______________________________________________
>>> PyOpenGL-Users mailing list
>>> PyO...@li...
>>> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>>
>
> ------------------------------------------------------------------------------
> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
> looking to deploy the next generation of Solaris that includes the  
> latest
> innovations from Sun and the OpenSource community. Download a copy and
> enjoy capabilities such as Networking, Storage and Virtualization.
> Go to: http://p.sf.net/sfu/opensolaris-get
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>

Re: [PyOpenGL-Users] Using glDrawElements on C-allocated data

[René D. <re...@gm...>]

Seems to be some ctypes wrappers here:
http://svn.python.org/projects/ctypes/trunk/ctypeslib/ctypeslib/contrib/pythonhdr.py

For the PyBuffer_FromReadWriteMemory function.  If you don't want to
use a C module for it.


cu,


On Wed, Jun 3, 2009 at 9:01 PM, René Dudfield <re...@gm...> wrote:
> On Wed, Jun 3, 2009 at 8:53 PM, Gordon L. Kindlmann <gl...@uc...> wrote:
>> Hello,
>>
>> I'm aware that most users of PyOpenGL are creating their arrays on the
>> python side.
>>
>> In my case, I'd like to make use of a large set of pre-existing C libraries,
>> which do what they do very well, and do it rapidly.  This includes
>> extracting features from scientific data, and representing them as polydata,
>> which I'd like to visualize from python.  Creating the buffers in python is
>> not an option for me.  Copying the data into a python array, just so I can
>> hand it back to PyOpenGL, which in turn goes back through ctypes to give it
>> OpenGL, is going to incur a memory and performance cost that should be
>> avoided.
>
> sure, but can those libraries let you pass in your own allocated data?
>  Or are they not extensible in that way?  Many C libraries let you
> allocate the memory yourself, is why I asked.
>
> but, if you don't want to do it that way, or can't then you can create
> a buffer from a pointer+size, and then use it.
>
>
> cheers,
>

Re: [PyOpenGL-Users] Using glDrawElements on C-allocated data

[René D. <re...@gm...>]

On Wed, Jun 3, 2009 at 8:53 PM, Gordon L. Kindlmann <gl...@uc...> wrote:
> Hello,
>
> I'm aware that most users of PyOpenGL are creating their arrays on the
> python side.
>
> In my case, I'd like to make use of a large set of pre-existing C libraries,
> which do what they do very well, and do it rapidly.  This includes
> extracting features from scientific data, and representing them as polydata,
> which I'd like to visualize from python.  Creating the buffers in python is
> not an option for me.  Copying the data into a python array, just so I can
> hand it back to PyOpenGL, which in turn goes back through ctypes to give it
> OpenGL, is going to incur a memory and performance cost that should be
> avoided.

sure, but can those libraries let you pass in your own allocated data?
 Or are they not extensible in that way?  Many C libraries let you
allocate the memory yourself, is why I asked.

but, if you don't want to do it that way, or can't then you can create
a buffer from a pointer+size, and then use it.


cheers,

Re: [PyOpenGL-Users] Using glDrawElements on C-allocated data

[René D. <re...@gm...>]

hi again,

or if you just want to whip up a c module...

the buffer interface is your friend:
    http://docs.python.org/dev/c-api/buffer.html


Check out the docs for this functions:
PyObject* PyBuffer_FromMemory(void *ptr, Py_ssize_t size)
PyObject* PyBuffer_FromReadWriteMemory(void *ptr, Py_ssize_t size)






On Wed, Jun 3, 2009 at 8:44 PM, René Dudfield <re...@gm...> wrote:
>
> hi,
>
> usually you can create the array in python, and then give a pointer to the C/C++/F0oLang
>
> Generally easiest for my mind.  That leaves the memory management in python.
>
> Or create the python buffers from your pointer.
>
>
> Then create the slices in python, rather than using pointer arithmetic.
>
> eg, new_array = array[vertIdx:]
>
>
>
> cu,
>
> On Mon, Jun 1, 2009 at 8:37 AM, Gordon L. Kindlmann <gl...@uc...> wrote:
>>
>> Hello,
>>
>> I've recently started using PyOpenGL as the framework for re-writing C/
>> C++ OpenGL wrappers around an large amount of research code in C.  Its
>> been a pleasure to have something that allows such literal translation
>> from the successful C/C++ OpenGL code to Python code; thanks for
>> creating this!
>>
>> The main hitch I've had is in using glDrawElements.  I've looked
>> around for answers to this, and its clear that people people using
>> PyOpenGL are using it with geometry that is created on the python
>> side.  In my case, all the geometry information is created on the C
>> side, and I want to control its display from Python.
>>
>> The line that's causing problems is:
>>
>>   glDrawElements(glpt[lpld.type[primIdx]], vertCnt, GL_UNSIGNED_INT,
>> lpld.indx + vertIdx)
>>
>> where lpld.indx is a ctypes-created pointer to a buffer of unsigned
>> ints allocated and filled in C, which causes this problem:
>>
>>   Traceback (most recent call last):
>>     File "pgltDemo.py", line 118, in display
>>       pgltDraw(pgltObject, uva)
>>     File "pgltDemo.py", line 76, in pgltDraw
>>       GL_UNSIGNED_INT, lpld.indx + vertIdx)
>>   TypeError: unsupported operand type(s) for +: 'LP_c_ulong' and 'int'
>>
>> because apparently pointer arithmetic games aren't quite so simply in
>> Python.  If you just replace "lpld.indx + vertIdx" with "lpld.indx",
>> which removes the pointer arithmetic stuff, it segfaults.  I know that
>> others have looked at this issue from the context of having array data
>> that's created via numpy:
>>
>> http://www.mail-archive.com/pyg...@go.../msg01356/t.py
>>
>> I've tried many different iterations of things like this, and I get
>> either python errors or segfaults.
>>
>> Getting this to work with PyOpenGL would make a huge difference in how
>> I can get research work done with python, so I've taken some type to
>> put a self-contained example online:
>>
>> http://people.cs.uchicago.edu/~glk/pglt/
>>
>> This includes a C library the generates some geometry to render, and a
>> ctypeslib-generated wrapper around the library.  pgltDemo.c contains a
>> "pgltDraw()" function that shows how I'm currently doing things
>> without (for display lists) and with vertex arrays.  pgltDemo.py
>> contains the same function, but the vertex array code is broken.
>>
>> Hopefully someone on this list will be able to spend a little time
>> working with these examples, and figure out how to get my
>> "pgltDemo.py" to work with vertex arrays.
>>
>> Thanks very much,
>> Gordon
>>
>>
>> ------------------------------------------------------------------------------
>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
>> is a gathering of tech-side developers & brand creativity professionals. Meet
>> the minds behind Google Creative Lab, Visual Complexity, Processing, &
>> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
>> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
>> _______________________________________________
>> PyOpenGL Homepage
>> http://pyopengl.sourceforge.net
>> _______________________________________________
>> PyOpenGL-Users mailing list
>> PyO...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>

Re: [PyOpenGL-Users] Using glDrawElements on C-allocated data

[Gordon L. K. <gl...@uc...>]

Hello,

I'm aware that most users of PyOpenGL are creating their arrays on the  
python side.

In my case, I'd like to make use of a large set of pre-existing C  
libraries, which do what they do very well, and do it rapidly.  This  
includes extracting features from scientific data, and representing  
them as polydata, which I'd like to visualize from python.  Creating  
the buffers in python is not an option for me.  Copying the data into  
a python array, just so I can hand it back to PyOpenGL, which in turn  
goes back through ctypes to give it OpenGL, is going to incur a memory  
and performance cost that should be avoided.

I know that what I'm hoping to do is possible, somehow, because the  
underlying array data is already being used perfectly well to call  
glDrawElements from C.

I remain hopeful that someone on this list has the time and expertise  
to help me make this work.

Gordon

On Jun 3, 2009, at 5:44 AM, René Dudfield wrote:

> hi,
>
> usually you can create the array in python, and then give a pointer  
> to the C/C++/F0oLang
>
> Generally easiest for my mind.  That leaves the memory management in  
> python.
>
> Or create the python buffers from your pointer.
>
>
> Then create the slices in python, rather than using pointer  
> arithmetic.
>
> eg, new_array = array[vertIdx:]
>
>
>
> cu,
>
> On Mon, Jun 1, 2009 at 8:37 AM, Gordon L. Kindlmann  
> <gl...@uc...> wrote:
> Hello,
>
> I've recently started using PyOpenGL as the framework for re-writing  
> C/
> C++ OpenGL wrappers around an large amount of research code in C.  Its
> been a pleasure to have something that allows such literal translation
> from the successful C/C++ OpenGL code to Python code; thanks for
> creating this!
>
> The main hitch I've had is in using glDrawElements.  I've looked
> around for answers to this, and its clear that people people using
> PyOpenGL are using it with geometry that is created on the python
> side.  In my case, all the geometry information is created on the C
> side, and I want to control its display from Python.
>
> The line that's causing problems is:
>
>   glDrawElements(glpt[lpld.type[primIdx]], vertCnt, GL_UNSIGNED_INT,
> lpld.indx + vertIdx)
>
> where lpld.indx is a ctypes-created pointer to a buffer of unsigned
> ints allocated and filled in C, which causes this problem:
>
>   Traceback (most recent call last):
>     File "pgltDemo.py", line 118, in display
>       pgltDraw(pgltObject, uva)
>     File "pgltDemo.py", line 76, in pgltDraw
>       GL_UNSIGNED_INT, lpld.indx + vertIdx)
>   TypeError: unsupported operand type(s) for +: 'LP_c_ulong' and 'int'
>
> because apparently pointer arithmetic games aren't quite so simply in
> Python.  If you just replace "lpld.indx + vertIdx" with "lpld.indx",
> which removes the pointer arithmetic stuff, it segfaults.  I know that
> others have looked at this issue from the context of having array data
> that's created via numpy:
>
> http://www.mail-archive.com/pyg...@go.../msg01356/ 
> t.py
>
> I've tried many different iterations of things like this, and I get
> either python errors or segfaults.
>
> Getting this to work with PyOpenGL would make a huge difference in how
> I can get research work done with python, so I've taken some type to
> put a self-contained example online:
>
> http://people.cs.uchicago.edu/~glk/pglt/
>
> This includes a C library the generates some geometry to render, and a
> ctypeslib-generated wrapper around the library.  pgltDemo.c contains a
> "pgltDraw()" function that shows how I'm currently doing things
> without (for display lists) and with vertex arrays.  pgltDemo.py
> contains the same function, but the vertex array code is broken.
>
> Hopefully someone on this list will be able to spend a little time
> working with these examples, and figure out how to get my
> "pgltDemo.py" to work with vertex arrays.
>
> Thanks very much,
> Gordon
>
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity  
> professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp as they present alongside digital heavyweights like  
> Barbarian
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
> ------------------------------------------------------------------------------
> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
> looking to deploy the next generation of Solaris that includes the  
> latest
> innovations from Sun and the OpenSource community. Download a copy and
> enjoy capabilities such as Networking, Storage and Virtualization.
> Go to: http://p.sf.net/sfu/opensolaris-get_______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users

Re: [PyOpenGL-Users] Using glDrawElements on C-allocated data

[René D. <re...@gm...>]

hi,

usually you can create the array in python, and then give a pointer to the
C/C++/F0oLang

Generally easiest for my mind.  That leaves the memory management in python.

Or create the python buffers from your pointer.


Then create the slices in python, rather than using pointer arithmetic.

eg, new_array = array[vertIdx:]



cu,

On Mon, Jun 1, 2009 at 8:37 AM, Gordon L. Kindlmann <gl...@uc...>wrote:

> Hello,
>
> I've recently started using PyOpenGL as the framework for re-writing C/
> C++ OpenGL wrappers around an large amount of research code in C.  Its
> been a pleasure to have something that allows such literal translation
> from the successful C/C++ OpenGL code to Python code; thanks for
> creating this!
>
> The main hitch I've had is in using glDrawElements.  I've looked
> around for answers to this, and its clear that people people using
> PyOpenGL are using it with geometry that is created on the python
> side.  In my case, all the geometry information is created on the C
> side, and I want to control its display from Python.
>
> The line that's causing problems is:
>
>   glDrawElements(glpt[lpld.type[primIdx]], vertCnt, GL_UNSIGNED_INT,
> lpld.indx + vertIdx)
>
> where lpld.indx is a ctypes-created pointer to a buffer of unsigned
> ints allocated and filled in C, which causes this problem:
>
>   Traceback (most recent call last):
>     File "pgltDemo.py", line 118, in display
>       pgltDraw(pgltObject, uva)
>     File "pgltDemo.py", line 76, in pgltDraw
>       GL_UNSIGNED_INT, lpld.indx + vertIdx)
>   TypeError: unsupported operand type(s) for +: 'LP_c_ulong' and 'int'
>
> because apparently pointer arithmetic games aren't quite so simply in
> Python.  If you just replace "lpld.indx + vertIdx" with "lpld.indx",
> which removes the pointer arithmetic stuff, it segfaults.  I know that
> others have looked at this issue from the context of having array data
> that's created via numpy:
>
> http://www.mail-archive.com/pyg...@go.../msg01356/t.py
>
> I've tried many different iterations of things like this, and I get
> either python errors or segfaults.
>
> Getting this to work with PyOpenGL would make a huge difference in how
> I can get research work done with python, so I've taken some type to
> put a self-contained example online:
>
> http://people.cs.uchicago.edu/~glk/pglt/<http://people.cs.uchicago.edu/%7Eglk/pglt/>
>
> This includes a C library the generates some geometry to render, and a
> ctypeslib-generated wrapper around the library.  pgltDemo.c contains a
> "pgltDraw()" function that shows how I'm currently doing things
> without (for display lists) and with vertex arrays.  pgltDemo.py
> contains the same function, but the vertex array code is broken.
>
> Hopefully someone on this list will be able to spend a little time
> working with these examples, and figure out how to get my
> "pgltDemo.py" to work with vertex arrays.
>
> Thanks very much,
> Gordon
>
>
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals.
> Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>

Re: [PyOpenGL-Users] Using glDrawElements on C-allocated data

[Gordon L. K. <gl...@uc...>]

Sorry for the excessive traffic ...

On Jun 2, 2009, at 5:35 AM, Gordon L. Kindlmann wrote:

> I agree that this is relevant, but I'm still stumped because my data
> is not coming from numpy.  Its coming from a C-allocated array that is
> being accessed via numpy.

being accessed via *ctypes*.

>  There is no .data_as for me.

This is the important point.

>  I don't quite
> understand the relationship between what .data_as returns, how
> pyopengl's use of ctypes handles that "pointer", and how to
> communicate the analogous information from array allocated in C,
> outside of numpy.
>
> If you have any spare time, I'd be interested if you can tweak the
> call to glDrawElements in
>
> http://people.cs.uchicago.edu/~glk/pglt/pgltDemo.py
>
> so that it works; I've done everything I can to make a self-contained
> but non-trivial demonstration of the problem I'm having.
>
> Thanks,
> Gordon

Gordon