pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] For the Brave: PyOpenGL 3.0.1a1 released...

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

Zack Schilling wrote:
> I tried the new alpha out on my game. The game draws a lot of quads
> and point sprite particles using VBOs. Everything drew fine, no
> crashes, flickering, stuttering, or any other errata. The only change
> I noticed was a stricter behavior with ERROR_ON_COPY enabled. I
> typically used ERROR_ON_COPY to make sure that I didn't make a dumb
> mistake with VBOs, but I never had a problem with using Python lists
> for things like texture deletion. Now the flag catches such uses. I'll
> need to make a few minor changes to my code.
Yeah, the ERROR_ON_COPY stuff now actually makes simplifying assumptions
for the wrappers (i.e. drops out wrapper code), so the various array
handlers need to be far more rigorous about checking.  It caught quite a
few of my scripts where I was passing lists/tuples for light/material
parameters and similar small arrays.
>
> Other than that, the game ran as if nothing had changed. I didn't
> notice any change in speed or GPU load capability with acceleration
> on. I don't handle a ton buffers and pointers, so I guess a lot of the
> optimizations are lost on my code.
Yeah, if your code is basically a few dozen calls into PyOpenGL passing
in huge data-arrays then the PyOpenGL overhead would be negligible.  In
OpenGLContext I see a drop from OpenGL calls being ~10% of run-time to
~2.5% of run time.  Translates to about 9fps on the shaderobjects.py
demo (from 69 to 78).
> My main dev machine runs Mac OS X. I'll need to compile and test this
> all there too. I'll let you know if anything comes up.
We had a bug report on OS-X, I'm about to look into that.

Thanks for the update,
Mike

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

[PyOpenGL-Users] For the Brave: PyOpenGL 3.0.1a1 released...

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

I've just managed to get PyOpenGL's first alpha for the 3.0.1 series out
the door.  The biggest changes of note are:

    * Shader convenience module OpenGL.GL.shaders, provides shader entry
      points named as the core entry points with alternate
      implementations using ARB when necessary.  Includes Two utility
      functions compileShader( source, type_constant ) and
      compileProgram( *shaders ) which allow for easily creating
      shader-using demos.
    * Cython OpenGL_accelerate wrapper mechanism accelerators available
      (pre-built for Python 2.5 and 2.6 on Win32)
    * Many bug-fixes.
    * SIZE_1_ARRAY_UNPACK flag to configure single-value-array-unpacking
      behaviour
    * CONTEXT_CHECKING flag to enable rigorous (slow) checking for valid
      contexts before each GL/GLU/GLE call in order to debug crashes due
      to calls before there is a valid context present.
    * STORE_POINTERS flag to enable/disable storage of (temporary) pointers
    * Optimizations to reduce or remove certain wrapper operations when
      the ERROR_ON_COPY flag is enabled.

This release is very much an alpha, do not install in production
environments, use it to test your software and send me bug reports. 
There are enough significant implementation changes in this release that
it would be extremely unlikely that no bugs have crept in.

See: https://sourceforge.net/projects/pyopengl/files for downloads.

Enjoy,
Mike

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

[PyOpenGL-Users] [ pyopengl-Feature Requests-2109993 ] ez_setup for setuptool

[SourceForge.net <no...@so...>]

Feature Requests item #2109993, was opened at 2008-09-14 03:46
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355988&aid=2109993&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: install
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: ez_setup for setuptool

Initial Comment:
Not everybody has setuptools installed already, so PEAK advise setup.py should start like this:

import ez_setup
ez_setup.use_setuptools()

and of course you need to add a the file to the package: http://peak.telecommunity.com/dist/ez_setup.py

setuptools is automatically installed and that way nobody has to manually download it. Very nice :)

If you don't believe me then check it out yourself at:
http://peak.telecommunity.com/DevCenter/setuptools



----------------------------------------------------------------------

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-07-19 00:16

Message:
Removed setuptools entirely due to end-user complaints and
incompatibilities.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355988&aid=2109993&group_id=5988

[PyOpenGL-Users] [ pyopengl-Feature Requests-1311265 ] glReadPixels enhancement request

[SourceForge.net <no...@so...>]

Feature Requests item #1311265, was opened at 2005-10-02 19:00
Message generated for change (Comment added) made by mcfletch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355988&aid=1311265&group_id=5988

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Stuart Woolford (swoolford)
Assigned to: Nobody/Anonymous (nobody)
Summary: glReadPixels enhancement request

Initial Comment:
When using glReadPixels in combinations with pixel buffer 
objects 
(PBOs) the last (C) argument is no longer the address of 
memory to 
move the data to, but an offset from the currently defined buffer 
object base. 
 
As a trivial example it is connon to use: 
glReadPixels(0,0,640,480,GL_BGRA,GL_UNSIGNED_BYTE,0) 
Which causes the data to be copied to the base (0 offset) of the 
currently defined PBO. 
Of course, in pyOpengl this does not seem doable, as the 
buffers are 
handled internally, and the last argument is not exposed. 
Is it possible that we could have new versions of the affected 
calls 
exposed that do take the last argument? 
Perhaps a glReadPixelsB (for buffer) or something like that? 
(glWritePixels has the same limitation). 
 
PBOs are a very important feature for using openGL in image 
processing, so this would be a very useful addition. 
It would also allow glReadPixels to be used from python in 
situations 
where the overhead of the double data copy currently required for 
the 
(much easier to use) current implementation is too much when 
moving 
through bounce buffers. 

----------------------------------------------------------------------

>Comment By: Mike C. Fletcher (mcfletch)
Date: 2009-07-19 00:15

Message:
I've just added code to bzr head to support passing in the array argument
to glReadPixels, but haven't found glWritePixels to alter that.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355988&aid=1311265&group_id=5988

Re: [PyOpenGL-Users] VBOs and gl*Pointer offset parameter

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

renaud blanch wrote:
> On Thu, Jul 16, 2009 at 8:32 PM, Mike C. Fletcher<mcf...@vr...> wrote:
>   
...
>>    ctypes.c_void_p( 12 )
>>
>> should work as an array offset of 12 bytes,
...
> no, it does not work (at least for me).
> that's what i was also doing.
>   
Argh.  ctypes c_void_p is a parameter type, not a pointer type (I knew
this, but I mis-coded for it).  I've checked a 2-line patch into the
OpenGL.arrays.ctypesparameters file, it should show up in the next
release (which should happen reasonably soon, if I ever get enough time
to test).  In the meantime, the following patch should work, or you
could use bzr head of PyOpenGL.

HTH,
Mike

=== modified file 'OpenGL/arrays/ctypesparameters.py'
--- OpenGL/arrays/ctypesparameters.py   2009-04-09 19:06:55 +0000
+++ OpenGL/arrays/ctypesparameters.py   2009-07-17 18:21:38 +0000
@@ -30,7 +30,7 @@
                        return ctypes.byref( value )
        from_param = voidDataPointer = classmethod( from_param )
        def dataPointer( cls, value ):
-               if isinstance( value, ParamaterType ):
+               if isinstance( value, DIRECT_RETURN_TYPES ):
                        return value
                else:
                        return ctypes.addressof( value )
@@ -95,6 +95,8 @@
                                yield length
        def asArray( self, value, typeCode=None ):
                """Convert given value to an array value of given
typeCode"""
+               if isinstance( value, DIRECT_RETURN_TYPES ):
+                       return value
                if isinstance( value, ParamaterType ):
                        value = value._obj
                return ctypes.byref( value )

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

Re: [PyOpenGL-Users] VBOs and gl*Pointer offset parameter

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

renaud blanch wrote:
> hello,
>
> i start to experiment with VBOs to prepare some code to the future of opengl :)
> i try to use a single array buffer to store a bunch of vertices and
> then the associated colors.
> as far as i understand, i should then use the last parameter of the
> usual gl[Vertex|Color]Pointer to pass the offset of the first element
> inside the array.
> for the vertices, it's 0, so i can pass None (the c functions expect a
> void* parameter).
> the problem is for non-zero offsets, e.g. for the colors in this case.
> it seems that the python wrapper interprets the last parameter as an
> array, and i have not found a way to pass an offset without
> "dewrapping" the function, i.e.
>
> offset = 12
> glColorPointer.wrappedOperation(3, GL_FLOAT, 0, offset) # works
> glColorPointer(3, GL_FLOAT, 0, any_thing_i_could_think_of(offset)) #
> doesn't work
>
> i've tried several any_thing_i_could_think_of functions (casting to
> c_void_p, etc.) with no luck.
> any advice ?
>   
I'm afraid I'm so accustomed to using the OpenGL.arrays.vbo.VBO wrapper
that I haven't documented the base operation:

    ctypes.c_void_p( 12 )

should work as an array offset of 12 bytes, if it isn't, let me know and
I'll dig into why it's not working for you (failing code would be
helpful).  The wrapper includes a VBOOffset type which basically is
interpreted as an offset when using the wrapper (they're created with
myVBO + byteOffset).

HTH,
Mike

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

[PyOpenGL-Users] VBOs and gl*Pointer offset parameter

[renaud b. <rnd...@gm...>]

hello,

i start to experiment with VBOs to prepare some code to the future of opengl :)
i try to use a single array buffer to store a bunch of vertices and
then the associated colors.
as far as i understand, i should then use the last parameter of the
usual gl[Vertex|Color]Pointer to pass the offset of the first element
inside the array.
for the vertices, it's 0, so i can pass None (the c functions expect a
void* parameter).
the problem is for non-zero offsets, e.g. for the colors in this case.
it seems that the python wrapper interprets the last parameter as an
array, and i have not found a way to pass an offset without
"dewrapping" the function, i.e.

offset = 12
glColorPointer.wrappedOperation(3, GL_FLOAT, 0, offset) # works
glColorPointer(3, GL_FLOAT, 0, any_thing_i_could_think_of(offset)) #
doesn't work

i've tried several any_thing_i_could_think_of functions (casting to
c_void_p, etc.) with no luck.
any advice ?

i've started looking into pyopengl code to see if the  wrapper could
be made more "clever" by distinguishing array-like and offset-like use
of the last parameter but i need some time to fully understand the
wrapping of the pointer functions.

thanks for any advice,

renaud

Re: [PyOpenGL-Users] glGetUniformLocation causes segmentation faults

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

I don't know, but I've had this problem on two systems.

My newer (current) is a NVidia GeForce 8400M GS
According to here<http://en.kioskea.net/guide/692632-nvidia-geforce-6800-gs-256-mo-gddr3>,
it has "Graphics Support: DirectX 9.0, OpenGL 2.0"

Re: [PyOpenGL-Users] glGetUniformLocation causes segmentation faults

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

Ian Mallett wrote:
> On Sun, Jul 5, 2009 at 1:57 PM, Mike C. Fletcher
> <mcf...@vr... <mailto:mcf...@vr...>> wrote:
>
>     You don't have a valid OpenGL context at this point, without that many
>     of the newer GL implementations will return NULL pointers when you try
>     to get the pointer.  Some will even silently return NULL values
>     (without
>     raising errors!) when there's no active context.  That's all
>     reasonably
>     spec-compliant, but a bit of a PITA IMO.
>
> Thought it might be the context.  Attached is a simple example that
> crashes.
> Ian
Hmm, no problem over here (AMD64 Linux with fglrx ATI drivers (OpenGL
2.1)).  You're sure your card supports an actual OpenGL 2.x driver, and
doesn't just have extensions on top of a 1.x driver?

Clueless is me,
Mike

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

Re: [PyOpenGL-Users] glGetUniformLocation causes segmentation faults

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

On Sun, Jul 5, 2009 at 1:57 PM, Mike C. Fletcher <mcf...@vr...>wrote:

> You don't have a valid OpenGL context at this point, without that many
> of the newer GL implementations will return NULL pointers when you try
> to get the pointer.  Some will even silently return NULL values (without
> raising errors!) when there's no active context.  That's all reasonably
> spec-compliant, but a bit of a PITA IMO.

Thought it might be the context.  Attached is a simple example that crashes.
Ian

Re: [PyOpenGL-Users] glGetUniformLocation causes segmentation faults

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

Ian Mallett wrote:
> On Sun, Jul 5, 2009 at 12:39 PM, Mike C. Fletcher
> <mcf...@vr... <mailto:mcf...@vr...>> wrote:
>
>     Ian Mallett wrote:
>
>     > 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.
>     Missed this.
>
>     Can you give more details and/or a test-case?
>
> Well, this <http://www.pygame.org/wiki/GLSLExample?parent=CookBook>
> didn't work...
>
> I might have been referring to simple tests like:
>
> >>> from OpenGL.GL import *
> >>> glCreateShader
> <OpenGL.platform.baseplatform.glCreateShader object at 0x02C03090>
> >>> glCreateShader()
> Traceback (most recent call last):
>   File "<pyshell#2>", line 1, in <module>
>     glCreateShader()
>   File
> "C:\dev\Python25\Lib\site-packages\OpenGL\platform\baseplatform.py",
> line 299, in __call__
>     self.__name__, self.__name__,
> NullFunctionError: Attempt to call an undefined function
> glCreateShader, check for bool(glCreateShader) before calling
>
> Simply missing something?
You don't have a valid OpenGL context at this point, without that many
of the newer GL implementations will return NULL pointers when you try
to get the pointer.  Some will even silently return NULL values (without
raising errors!) when there's no active context.  That's all reasonably
spec-compliant, but a bit of a PITA IMO.

Maybe I'm missing something, though.  You do *way* more work with
PyOpenGL than me, so I could quite easily have missed a common failure-case.
Mike

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

Re: [PyOpenGL-Users] glGetUniformLocation causes segmentation faults

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

On Sun, Jul 5, 2009 at 12:39 PM, Mike C. Fletcher <mcf...@vr...>wrote:

> Ian Mallett wrote:
>
> > 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.
> Missed this.
>
> Can you give more details and/or a test-case?

Well, this <http://www.pygame.org/wiki/GLSLExample?parent=CookBook> didn't
work...

I might have been referring to simple tests like:

>>> from OpenGL.GL import *
>>> glCreateShader
<OpenGL.platform.baseplatform.glCreateShader object at 0x02C03090>
>>> glCreateShader()
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    glCreateShader()
  File "C:\dev\Python25\Lib\site-packages\OpenGL\platform\baseplatform.py",
line 299, in __call__
    self.__name__, self.__name__,
NullFunctionError: Attempt to call an undefined function glCreateShader,
check for bool(glCreateShader) before calling

Simply missing something?

Ian

Re: [PyOpenGL-Users] glGetUniformLocation causes segmentation faults

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

Ian Mallett wrote:

> 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. 
Missed this.

Can you give more details and/or a test-case?  When I run against
PyOpenGL trunk and enable INFO level logging in the extensions module I
get this:

INFO:OpenGL.extensions:OpenGL Version: 2.1.8575 FireGL
INFO:OpenGL.extensions:Chose alternate: glCreateProgram from
glCreateProgram, glCreateProgramObjectARB
INFO:OpenGL.extensions:Chose alternate: glCreateShader from
glCreateShader, glCreateShaderObjectARB
INFO:OpenGL.extensions:Chose alternate: glShaderSource from
glShaderSource, glShaderSourceARB
INFO:OpenGL.extensions:Chose alternate: glCompileShader from
glCompileShader, glCompileShaderARB
INFO:OpenGL.extensions:Chose alternate: glAttachShader from
glAttachShader, glAttachObjectARB
INFO:OpenGL.extensions:Chose alternate: glValidateProgram from
glValidateProgram, glValidateProgramARB
INFO:OpenGL.extensions:Chose alternate: glLinkProgram from
glLinkProgram, glLinkProgramARB
INFO:OpenGL.extensions:Chose alternate: glDeleteShader from
glDeleteShader, glDeleteObjectARB
INFO:OpenGL.extensions:Chose alternate: glGetAttribLocation from
glGetAttribLocation, glGetAttribLocationARB
INFO:OpenGL.extensions:GL Extension GL_ARB_occlusion_query available
INFO:OpenGL.extensions:GL Extension GL_ARB_point_parameters available
INFO:OpenGL.extensions:Chose alternate: glUseProgram from glUseProgram,
glUseProgramObjectARB
INFO:OpenGL.extensions:GL Extension GL_ARB_vertex_buffer_object available
INFO:OpenGL.extensions:Chose alternate: glVertexAttribPointer from
glVertexAttribPointer, glVertexAttribPointerARB

when running a shader-using sample.  That is, it appears to properly
choose the core rather than ARB extension versions (and the core
functions are non-null).

Good luck,
Mike

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

Re: [PyOpenGL-Users] glTranslatef between two glVertex3f

[Astan C. <ast...@al...>]

Thanks.
I guess my question would then be how do I convert from x,y,z to a,b,c 
using maths instead of glTranslatef/glRotatef?
Cheers
Astan

Zack Schilling wrote:
> You cannot modify the matrix between glBegin and glEnd calls, so no  
> translation or rotation between plotting of vertices is allowed.
>
> If I understand what you want, you're trying to draw a line from the  
> "camera" to an object. Depending on how your frustum is set up, this  
> may be a bad idea. In any case, it'll look strange and glitchy at  
> best. But if you insist, here's what you need to do.
>
> Maintain the position of the camera with (x,y,z) and between loading  
> the identity and doing any drawing, perform a glTranslatef(-x,-y,-z)  
> as well as any other "camera" rotations you want. Once that's done,  
> plot a line from (x,y,z) to (x1,y1,z1), where (x1,y1,z1) are the  
> coordinates to the object you're drawing the line to.
>
>             glBegin(GL_LINES)
>             glVertex3f(x,y,z)
>             glVertex3f(x1,y1,z1)
>             glEnd()
>
> You cannot and should not try to adjust the matrix while plotting  
> points.
>
> -Zack
>
> On Jul 2, 2009, at 10:51 PM, Astan Chee wrote:
>
>   
>> Hi,
>> I'm trying to draw a line between two points (x0,y0,z0 and x1,y1,z1)
>> like this:
>>
>>            glPushMatrix()
>>
>>            glEnable(GL_BLEND)
>>
>>            glTranslatef(x,y,z)
>>
>>            glRotatef(-angle[0],0,1,0)
>>            glRotatef(angle[1],1,0,0)
>>
>>            glColor4f( 1, 0.0, 0.0, .8 )
>>
>>            glBegin(GL_LINES)
>>            glVertex3f(x0,y0,z0)
>>
>>            glTranslatef(-x,-y,-z)
>>
>>            glRotatef(angle[0],0,1,0)
>>            glRotatef(-angle[1],1,0,0)
>>
>>            glVertex3f(x1,y1,z1)
>>            glEnd()
>>
>>            glDisable(GL_BLEND)
>>            glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)
>>            glPopMatrix()
>>
>> Where x0,y0,z0 is the point near or in front of the "camera" and the
>> point x1,y1,z1 is the point in "real world coordinates".
>> This doesn't seem to work. How should I be doing this assuming I don't
>> know how to calculate either point in terms of the other?
>> Thanks
>> Astan
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> PyOpenGL Homepage
>> http://pyopengl.sourceforge.net
>> _______________________________________________
>> PyOpenGL-Users mailing list
>> PyO...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>>     
>
>
>   

Re: [PyOpenGL-Users] glTranslatef between two glVertex3f

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

glTranslatef(...) cannot be executed between glBegin(...) and glEnd().
Ian

[PyOpenGL-Users] glTranslatef between two glVertex3f

[Astan C. <ast...@al...>]

Hi,
I'm trying to draw a line between two points (x0,y0,z0 and x1,y1,z1) 
like this:

            glPushMatrix()

            glEnable(GL_BLEND)

            glTranslatef(x,y,z)

            glRotatef(-angle[0],0,1,0)
            glRotatef(angle[1],1,0,0)

            glColor4f( 1, 0.0, 0.0, .8 )

            glBegin(GL_LINES)
            glVertex3f(x0,y0,z0)

            glTranslatef(-x,-y,-z)

            glRotatef(angle[0],0,1,0)
            glRotatef(-angle[1],1,0,0)

            glVertex3f(x1,y1,z1)
            glEnd()

            glDisable(GL_BLEND)
            glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)           
            glPopMatrix()

Where x0,y0,z0 is the point near or in front of the "camera" and the 
point x1,y1,z1 is the point in "real world coordinates".
This doesn't seem to work. How should I be doing this assuming I don't 
know how to calculate either point in terms of the other?
Thanks
Astan

Re: [PyOpenGL-Users] converting "object position" to "view position" in (py)opengl

[Astan C. <ast...@al...>]

Hi,
I'm drawing characters using pygame and pyopengl like this:
def __init__(self):
        pygame.font.init()
        self.font = pygame.font.Font(FONT,18)
        self.char = []
        for c in range(256):
            self.char.append(self.CreateCharacter(chr(c)))
        self.char = tuple(self.char)
    def CreateCharacter(self,s):
        try:
            letter_render = self.font.render(s,1,(255,255,255), (0,0,0))
            letter = pygame.image.tostring(letter_render,'RGBA',1)
            letter_w,letter_h = letter_render.get_size()
        except:
            letter = None
            letter_w = letter_h= 0
        return (letter,letter_w,letter_h)
   
    def textView(self):
        w = self.Screen[0]
        h = self.Screen[1]
        glViewport(0,0,w,h)
        glMatrixMode(GL_PROJECTION)
        glLoadIdentity()
        glOrtho(0.0, w - 1.0, 0.0, h - 1.0, -1.0, 1.0)
        glMatrixMode(GL_MODELVIEW)
        glLoadIdentity()

    def Print(self,s,x,y):
        s = str(s)
        i = 0
        lx = 0
        length = len(s)
        self.textView()
        glPushMatrix()
        while i < length:
            glRasterPos2i(x + lx, y)
            ch = self.char[ ord( s[i] ) ]
            glDrawPixels(ch[1], ch[2], GL_RGBA, GL_UNSIGNED_BYTE, ch[0])
            lx += ch[1]
            i += 1
        glPopMatrix() 
and then when I need to print in a certain part of the screen, I do a 
self.Print("text",0,0) which will do a print on the bottom left corner.
I don't think i'm using glBitmap
Cheers
Astan

Dirk Reiners wrote:
> 	Hi Astan,
>
> Astan Chee wrote:
>   
>> Hi,
>> Im relatively new to opengl and I'm not familiat with its jargon but 
>> what I have is objects in a 3D world in various positions and a camera 
>> that can "move" around. What I'm trying to do is if the distance between 
>> object and camera is close enough, display some information on the 
>> screen on the object.
>> I know how to calculate distance and I know how to print/display text in 
>> opengl (I'm using glOrtho and glRasterPos2i to map out the characters 
>> one at a time).
>> Anyway, what I'm having problems with is how do I calculate where to 
>> display these information on the screen so that it overlaps the object 
>> (assuming I know the distance and the angle of the camera and the object 
>> relative to the camera). Does this make sense? I've attached an image 
>> that I photoshopped to look like what I'm trying to do.
>>     
>
> What are you using to draw the characters? glBitmap? Your use of glRasterPos2i 
> hints at that.
>
> In that case you can just ignore the glOrtho and use glRasterPos3f to position 
> your text in the 3D scene (e.g. in the center of the object). The main 
> difficulty is putting the chacaters next to each other, and glBitmap takes care 
> of that nicely.
>
> If you're using a different method things get a little more complicated (but not 
> too much, really).
>
> 	Dirk
>
>   

Re: [PyOpenGL-Users] glGetUniformLocation causes segmentation faults

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

As a wild guess that may not work, it looks like you're using ARB
extensions.  You could try creating the shader like so:

program = glCreateProgramObjectARB()

vert = glCreateShaderObjectARB(GL_VERTEX_SHADER_ARB)
frag = glCreateShaderObjectARB(GL_FRAGMENT_SHADER_ARB)

glShaderSourceARB(vert,[self.vert_src])
glShaderSourceARB(frag,[self.frag_src])

glCompileShaderARB(vert)
glCompileShaderARB(frag)

glAttachObjectARB(program,vert)
glAttachObjectARB(program,frag)

glDeleteObjectARB(vert)
glDeleteObjectARB(frag)

glValidateProgramARB(program)
glLinkProgramARB(program)

glUseShader(program)

Ian

Re: [PyOpenGL-Users] converting "object position" to "view position" in (py)opengl

[Dirk R. <dir...@gm...>]

	Hi Astan,

Astan Chee wrote:
> Hi,
> Im relatively new to opengl and I'm not familiat with its jargon but 
> what I have is objects in a 3D world in various positions and a camera 
> that can "move" around. What I'm trying to do is if the distance between 
> object and camera is close enough, display some information on the 
> screen on the object.
> I know how to calculate distance and I know how to print/display text in 
> opengl (I'm using glOrtho and glRasterPos2i to map out the characters 
> one at a time).
> Anyway, what I'm having problems with is how do I calculate where to 
> display these information on the screen so that it overlaps the object 
> (assuming I know the distance and the angle of the camera and the object 
> relative to the camera). Does this make sense? I've attached an image 
> that I photoshopped to look like what I'm trying to do.

What are you using to draw the characters? glBitmap? Your use of glRasterPos2i 
hints at that.

In that case you can just ignore the glOrtho and use glRasterPos3f to position 
your text in the 3D scene (e.g. in the center of the object). The main 
difficulty is putting the chacaters next to each other, and glBitmap takes care 
of that nicely.

If you're using a different method things get a little more complicated (but not 
too much, really).

	Dirk

[PyOpenGL-Users] Possible 64 bit bug

[Zack S. <zac...@gm...>]

I'm developing a game with Pygame, Numpy, and PyOpenGL and I've come  
across a bug in what I think is PyOpenGL (though it may not be). I've  
only seen the bug present under Windows Vista 64. The machine in  
question was equipped with a Radeon 4870 and the most up-to-date  
drivers. Unfortunately, the machine is not mine, so I can't give more  
details.

Anyway, my game runs fine, including Numpy generated VBOs and other  
fancy stuff, but it crashes when I initialize a simple object called  
the LinkLine. The LinkLine object uses immediate mode to draw GL_LINES  
between two in-game objects. It works fine on every system I've ever  
tried (Mac OS, Linux, Windows, nVidia/ATI/Intel/Software) except for  
machines running Vista 64. When I try to draw the link line, the game  
crashes with an access violation. Here's a breakdown of the crash:

Execution traces back to LinkLine.py, line 55, in the draw method.

WindowsError: Exception: access violation writing 0x00000008

Here's what's written on line 55:
glColor4f(self.color[0],self.color[1],self.color[2],self.color[3])

Basically, I'm setting the current RGBA color using 4 floats stored in  
a tuple.

The color tuple is set by this line:
self.color = color

Referencing a calling argument in the constructor:
  def  
__init__ 
(self 
,spawnpoint,obj1,obj2,color=(0,0,0,1),thickness=2.0,additive=False):

Which in the specific case of the crash is constructed here:
gameinfo.spawnobj(create("LinkLine", 
(0,0 
),self 
.deadplayer 
,self.tempwall,color=(0,0,0.4,0.6),additive=True,thickness=12))


In short, I create the tuple "color=(0,0,0.4,0.6)" and pass it on down  
the chain until it gets pulled apart and set with glColor4f. I perform  
this same operation on tons of objects in my game. The same exact code  
works in other places. Why not here?

  How would I go about debugging this further? Any tips on what could  
be wrong? This is a real mystery to me.

Thanks,

-Zack

For reference, here's the whole draw function of LinkLine. It's very  
straightforward.

     def draw(self):
         glDisable(GL_TEXTURE_2D)
         glLineWidth(self.thickness)

         if self.additive:
             glColor4f(0,0,0,0.02)

             glBegin(GL_LINES)
             glVertex3f(self.obj1.positionx, self.obj1.positiony,  
self.obj1.positionz)
             glVertex3f(self.obj2.positionx, self.obj2.positiony,  
self.obj2.positionz)
             glEnd()

             glBlendFunc(GL_SRC_ALPHA, GL_ONE)

          
glColor4f(self.color[0],self.color[1],self.color[2],self.color[3])

         glBegin(GL_LINES)
         glVertex3f(self.obj1.positionx, self.obj1.positiony,  
self.obj1.positionz)
         glVertex3f(self.obj2.positionx, self.obj2.positiony,  
self.obj2.positionz)
         glEnd()

         # Set the drawing state back up the way it should be.
         glColor4f(1,1,1,1)
         if self.additive:
             glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)

         glEnable(GL_TEXTURE_2D)

[PyOpenGL-Users] converting "object position" to "view position" in (py)opengl

[Astan C. <ast...@al...>]

Hi,
Im relatively new to opengl and I'm not familiat with its jargon but 
what I have is objects in a 3D world in various positions and a camera 
that can "move" around. What I'm trying to do is if the distance between 
object and camera is close enough, display some information on the 
screen on the object.
I know how to calculate distance and I know how to print/display text in 
opengl (I'm using glOrtho and glRasterPos2i to map out the characters 
one at a time).
Anyway, what I'm having problems with is how do I calculate where to 
display these information on the screen so that it overlaps the object 
(assuming I know the distance and the angle of the camera and the object 
relative to the camera). Does this make sense? I've attached an image 
that I photoshopped to look like what I'm trying to do.
Thanks for any help
Astan

Re: [PyOpenGL-Users] ATI Card Flipping FBO Texture

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

I can just see adding this option:
"Shadows look funky?: Yes/No"

Re: [PyOpenGL-Users] ATI Card Flipping FBO Texture

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

Ian Mallett wrote:
> 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 <http://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?
To complicate your hack/workaround, I'm on a Mobility Radeon HD 3650
(Ubuntu Jaunty 9.04 AMD64 w/fglrx drivers) and the code renders
perfectly.  That is, just checking for vendor string doesn't sound like
a solution.

Afraid I don't know of any reason the flip would occur, so I don't have
any real suggestions for how to fix it properly.  You might be able to
hack it by rendering a black/white texture and reading off a pixel
result, but that seems... sub-optimal.

Good luck,
Mike

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

Re: [PyOpenGL-Users] ATI Card Flipping FBO Texture

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

That is what I'd call a hack, although that's what I'll end up doing if I
can't find a better solution.  Thanks,
Ian

Re: [PyOpenGL-Users] ATI Card Flipping FBO Texture

[Mads I. <mp...@co...>]

Ian Mallett wrote:
> 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 <http://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
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>   
vendor = GL.glGetString(GL.GL_VENDOR)
if vendor == 'NVIDIA Corporation':
    ...
elif vendor == 'ATI Technologies Inc.':
    ...

But that's probably what you call a hack.

Mads

-- 
+------------------------------------------------------------+
| Mads Ipsen, Ph.D, Scientific software developer            |
+------------------------------+-----------------------------+
| QuantumWise A/S              | phone:         +45-29716388 |
| Nørresøgade 27A              | www:    www.quantumwise.com |
| DK-1370 Copenhagen, Denmark  | email:  mp...@qu... |
+------------------------------+-----------------------------+