pyopengl-users — Discussion of all PyOpenGL matters.

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

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

On Jun 2, 2009, at 3:24 AM, Mads Ipsen wrote:

> Gordon L. Kindlmann 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!

...
>> http://people.cs.uchicago.edu/~glk/pglt/
>>
...
>> 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
>>
>>
>>
> Using ctypes, I wrote the following interface to glMultiDrawElements:
>
> # Interface to glMultiDrawElements
> def multiDrawElements(mode, count, gl_type, index):
>   """
>   """
>   # Set up interface for the call
>   n_count = count.shape[0]
>   libGL.glMultiDrawElements.restype  = ctypes.c_void_p
>   libGL.glMultiDrawElements.argtypes = [ctypes.c_int32,
>                                          
> ctypes.POINTER(ctypes.c_int32),
>                                         ctypes.c_int32,
>                                          
> ctypes.POINTER(ctypes.c_int32)*n_count,
>                                         ctypes.c_int32,
>                                         ]
>
>   # Set pointer to data in the count array
>   count_ptr = count.ctypes.data_as(ctypes.POINTER(ctypes.c_int32))
>
>   # Set array of pointers to the index array
>   iptr = ctypes.POINTER(ctypes.c_int32)
>   index_ptr = (iptr*len(index))(*[row.ctypes.data_as(iptr) for row  
> in index])
>
>   # Do the actual call to glMultiDrawElements
>   libGL.glMultiDrawElements(int(mode), count_ptr, int(gl_type),  
> index_ptr, n_count)
>
> Then, using vertex arrays, I call glMultiDrawElements as follows:
>
> multiDrawElements(GL_QUAD_STRIP, count, GL_UNSIGNED_INT, index)

Okay, this is interesting.  However, I'm confused about the types of  
the arguments that you're passing to multiDrawElements().  "count"  
looks like it must be a numpy array, since you're using .shape  
and .ctypes.data_as, right?  "index" is a 2-D numpy array, given your  
use of row.ctypes.data_as for row in index, right?

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.  There is no .data_as for me.  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

>
>
> You should be able to boil this down to a working example for  
> glDrawElements(), whose arguments are a subset of the arguments to  
> glMultiDrawElements.
>
> Best regards,
>
> Mads
>
>
>

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

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

Gordon L. Kindlmann 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
>
>   
Using ctypes, I wrote the following interface to glMultiDrawElements:

# Interface to glMultiDrawElements
def multiDrawElements(mode, count, gl_type, index):
    """
    """
    # Set up interface for the call
    n_count = count.shape[0]
    libGL.glMultiDrawElements.restype  = ctypes.c_void_p
    libGL.glMultiDrawElements.argtypes = [ctypes.c_int32,
                                          ctypes.POINTER(ctypes.c_int32),
                                          ctypes.c_int32,
                                          
ctypes.POINTER(ctypes.c_int32)*n_count,
                                          ctypes.c_int32,
                                          ]

    # Set pointer to data in the count array
    count_ptr = count.ctypes.data_as(ctypes.POINTER(ctypes.c_int32))

    # Set array of pointers to the index array
    iptr = ctypes.POINTER(ctypes.c_int32)
    index_ptr = (iptr*len(index))(*[row.ctypes.data_as(iptr) for row in 
index])

    # Do the actual call to glMultiDrawElements
    libGL.glMultiDrawElements(int(mode), count_ptr, int(gl_type), 
index_ptr, n_count)

Then, using vertex arrays, I call glMultiDrawElements as follows:

multiDrawElements(GL_QUAD_STRIP, count, GL_UNSIGNED_INT, index)

You should be able to boil this down to a working example for 
glDrawElements(), whose arguments are a subset of the arguments to 
glMultiDrawElements.

Best regards,

Mads

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

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

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

[PyOpenGL-Users] installation questions

[chris b. <chr...@gm...>]

Hi,

I'm brand new to PyOpenGL and to this list.

I have a Solaris 10 x86 application that uses wxPython.  I'm upgrading
wxPython to the latest version that specifies PyOpenGL and OpenGL or
Mesa3D as prerequisites.  Not knowing anything about OpenGL except
what I've been reading the last 2 days, I have a fair number of
questions.  I'll try to pare them down to the basics to start, though.

1.PyOpenGL specifies OpenGL 1.1 and GLU as prerequisites.  How do I
determine if OpenGL is already installed, and if so what version it
is? The initial system is an Ultra 20 with Solaris 10 6/06, though we
will be using and shipping newer releases on different boxes.  Python
is 2.5.

Note: I saw a reference to trying "xdpyinfo | grep GLX" which gave me
"GLX" and "SGI-GLX", but I'm not yet sure what this tells me.

2. If OpenGL is not on the system, I've noted that Sun only has SPARC
versions for download.  Does this mean my only option is Mesa3D?

3. Do I need to install GLUT (for which I see there are Solaris x86
precompiled binaries) and GLX?  Anything else?

I appreciate any help anyone might provide in helping me sort this out
to get on the right track.

Regards,
Chris Botos

Re: [PyOpenGL-Users] deprecations

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

René Dudfield wrote:
>
> On Wed, May 20, 2009 at 3:25 AM, Mike C. Fletcher
> <mcf...@vr... <mailto:mcf...@vr...>> wrote:
>
>
>     note that nVidia has committed to providing support for deprecated
>     functionality on their cards, so you *may* be able to get away without
>     rewrites if your vendor supports you.
>
>
> All major vendors have committed to providing support.  I haven't
> heard of one that has said they aren't going to support current OpenGL.
I can't find a direct source for ATI, but people do seem to be saying
that they have committed to it.
> Marking existing functionality as depreciated is kind of silly at this
> point... considering how little opengl 3.x hardware is out there.
Hmm, and yet the ARB hasn't retracted the deprecations.  I gather we're
supposed to imply that no legacy code rewrites are necessary but that
all new code should use the new APIs.  Sheesh this is a PITA of a
release process :) .

Have fun,
Mike

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

Re: [PyOpenGL-Users] deprecations

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

On Wed, May 20, 2009 at 3:25 AM, Mike C. Fletcher <mcf...@vr...>wrote:

>
> note that nVidia has committed to providing support for deprecated
> functionality on their cards, so you *may* be able to get away without
> rewrites if your vendor supports you.
>

All major vendors have committed to providing support.  I haven't heard of
one that has said they aren't going to support current OpenGL.

Marking existing functionality as depreciated is kind of silly at this
point... considering how little opengl 3.x hardware is out there.

Re: [PyOpenGL-Users] deprecations

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

Andrew Wilson wrote:
> Hello,
>   I may be a little dense, it appears that quit a few functions in
> pyOpenGL3.0 have become deprecated (for example, glMatrixMode).  I
> don't see pointers to the appropriate function that I should upgrade
> to, is there a list somewhere?
The changes in OpenGL 3.x, and particularly the deprecations, are more
involved than a 1:1 change of replacing a given function with another
function.  OpenGL 3.x is attempting to eliminate the old-style
direct-mode APIs (and even many of the OpenGL 1.1 entry points) in favor
of an entirely shader-based/attribute-and-uniform-based
streaming-geometry rendering model.  There are some general instructions
here (in the comments):

   
http://blog.vrplumber.com/index.php?/archives/2267-PyOpenGL-3.0.0c1-Available-for-Testing.html

and presentation with background here:

    http://us.pycon.org/2009/conference/schedule/event/94/

note that nVidia has committed to providing support for deprecated
functionality on their cards, so you *may* be able to get away without
rewrites if your vendor supports you.

HTH,
Mike

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

[PyOpenGL-Users] deprecations

[Andrew W. <and...@al...>]

Hello,
  I may be a little dense, it appears that quit a few functions in
pyOpenGL3.0 have become deprecated (for example, glMatrixMode).  I don't see
pointers to the appropriate function that I should upgrade to, is there a
list somewhere?
  thanks
  Andrew

Re: [PyOpenGL-Users] Flipped FBO

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

This method uses a framebuffer object for the render to texture:
-Enable the framebuffer object
-glCopyTexImage2D(...)
-Disable the framebuffer object

I'm aware that framebuffer objects can render to textures using render
targets (glFramebufferTexture2DEXT...()), but I didn't want to deal with
making it a depth texture.  In my implementation, the framebuffer object is
just used to increase the size of the viewport meaningfully.  Could this
setup be the problem?

Incidentally, when is used glCopyTexImage2D(...) alone, everywhere appears
to be in shadow.

In my shader, I hardcoded the shadow functions to avoid card to card
problems, such as what to do with the edges outside the shadowmap (we
already saw that's a problem earlier, René).

I will check to see if the matrices are somehow different between cards.

Thanks,
Ian

Re: [PyOpenGL-Users] Flipped FBO

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

hi,

I've noticed some ATI cards flip textures some times too... not sure why.

It could be that some matrix is getting a negative sign somehow... or some
other random reason.  Perhaps something to do with the perspective matrix.

Are you using glReadPixels?  I've heard that sometimes flips things on
different cards...


cu,



On Sat, May 9, 2009 at 11:56 AM, Ian Mallett <geo...@gm...> wrote:

> Any idea what could possibly be causing these problems?  Is there some
> function that flips the framebuffer's texture?  What am I missing and what's
> going on?
>
[snip crappy sf mailing list spam]

Re: [PyOpenGL-Users] Flipped FBO

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

Any idea what could possibly be causing these problems?  Is there some
function that flips the framebuffer's texture?  What am I missing and what's
going on?

Re: [PyOpenGL-Users] font rendering problem

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

vwf wrote:
...
> Does someone know how to fix it? If there is an entirely new approach, I
> would like to know.
>   
Looks like a 90 degree rotation problem, that will cause the image to
get those diagonal lines (when width != height).  PyOpenGL automatically
sets tight packing (non-aligned) so the problem Dirk described shouldn't
happen.  Try doing a simple rotate on the image before you pass it to
PyOpenGL.

There are dozens of approaches to rendering text, you are using a
version ripped out of OpenGLContext by the look of it.  IIRC the
Pygame-generated font there needs to do a rotate in order to get to
OpenGL-compatible rendering format.

HTH,
Mike

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

Re: [PyOpenGL-Users] font rendering problem

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

	Hi Frits,

vwf wrote:
> Hello PyOpenGL experts,
> 
> 
> I have an ongoing saga of opengl problems. This time I try to tacle a
> font rendering problem. It might be that there are new rendering
> techniques available, but I still use a rather old technique.
> 
> The attached image shows the problem, the attached code produces it (on
> my system, running Debian Linux, Lenny/stable). For it to run you need
> Vera.ttf. The code is a small as I could get it without seriously
> changing the functionality.
> 
> Does someone know how to fix it? If there is an entirely new approach, I
> would like to know.

In 99% of the cases an image like that is caused by images that have odd width. 
By default OpenGL assumes image lines to start on a 4 byte boundary. if you have 
RGBA byte-sized pixels that's automatic, but for other sizes it may or may not 
work. You can try to add a glPixelStore(GL_UNPACK_ALIGNMENT, 1), that would 
avoid this problem.

Hope it helps

	Dirk

[PyOpenGL-Users] font rendering problem

[vwf <vw...@vu...>]

Hello PyOpenGL experts,


I have an ongoing saga of opengl problems. This time I try to tacle a
font rendering problem. It might be that there are new rendering
techniques available, but I still use a rather old technique.

The attached image shows the problem, the attached code produces it (on
my system, running Debian Linux, Lenny/stable). For it to run you need
Vera.ttf. The code is a small as I could get it without seriously
changing the functionality.

Does someone know how to fix it? If there is an entirely new approach, I
would like to know.

Thank you all,

Frits

Re: [PyOpenGL-Users] some problem with conversion

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

glCallLists() draws an array or list of display lists, so you can go:
glCallLists([list1,list2,list3,...]) Note the brackets.  Use glCallList() to
draw only one.

Re: [PyOpenGL-Users] some problem with conversion

[vwf <vw...@vu...>]

On Wed, Apr 29, 2009 at 07:44:11AM -0700, Ian Mallett wrote:
> Try glCallList() instead of glCallLists()

I don't know why yet, but this seems to work.

Thank you

Re: [PyOpenGL-Users] some problem with conversion

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

Try glCallList() instead of glCallLists()

[PyOpenGL-Users] some problem with conversion

[vwf <vw...@vu...>]

Hello PyOpenGL experts,

The latest PyOpenGL (2 april 2009) fixed almost all my problems.
Unfortunately, yesterday another one showed up. I do not see a problem
in my code. Can it be a bug in PyOpenGL?

  File "[...]/main_manav.py", line 146, in simulate
    ogldraw_timeplan(timeplan)
  File "[...]/ogldraw_new.py", line 378, in
ogldraw_timeplan
    draw_bignumb()
  File "[...]/drawmap.py", line 2472, in
draw_bignumb
    draw_ticker(1,b,a,pos,'%03d.')
  File "[...]/drawmap.py", line 2373, in draw_ticker
    atextLeft(text_Large,pos)
  File "[...]/pyfont.py", line 255, in atextLeft
    glCallLists( line )
  File "/var/lib/python-support/python2.5/OpenGL/lazywrapper.py", line
9, in __call__
    return wrapper( baseFunction, *args, **named )
  File "/var/lib/python-support/python2.5/OpenGL/GL/exceptional.py",
line 155, in glCallLists
    ctypes.c_void_p( arrays.GLuintArray.dataPointer(ptr))
TypeError: cannot be converted to pointer

The offending code:
def atextLeft( l, pos):
    (x,y)=pos
    glRasterPos2f( x,y )
    for line,metrics in l.lines:
        glCallLists( line )


Thanks,
Frits

[PyOpenGL-Users] Fwd: display openGl framebuffer in a python window

[rajendra k. d. <ra...@gm...>]

---------- Forwarded message ----------
From: rajendra kumar dale <ra...@gm...>
Date: Tue, Apr 28, 2009 at 9:13 PM
Subject: Re: [PyOpenGL-Users] display openGl framebuffer in a python window
To: Hoang Anh Nguyen <mai...@gm...>
Cc: pyo...@li...


i am also a newbie struggling on this FBO ... i just wrote a sample program
on using this fbos ...
but im using glutwindow ...hope this helps you (use any image "LITE.bmp")

raj

On Tue, Apr 28, 2009 at 8:55 PM, Hoang Anh Nguyen <
mai...@gm...> wrote:

> Hi guys,
>
>
>  I am a pyOpenGL newbie and I need some instructions to solve my problem.
>
> Current I have a openGL program written in C, and I want to stream the
> frame buffer from
>
> that program to a python window. Acquiring the frame buffer is done, my
> problem is that
>
> I am not sure how to pass the framebuffer and update the python window.
>
> Any suggestion is appreciated.
>
>  Cheers,
>
> Thanks.
>
>
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
>

Re: [PyOpenGL-Users] display openGl framebuffer in a python window

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

What "python window"?  The problem is pretty easy, but what windowing system
are you using?  wx?  pygame?  OpenGL.GLUT?
Ian

[PyOpenGL-Users] display openGl framebuffer in a python window

[Hoang A. N. <mai...@gm...>]

Hi guys,


 I am a pyOpenGL newbie and I need some instructions to solve my problem.

Current I have a openGL program written in C, and I want to stream the frame
buffer from

that program to a python window. Acquiring the frame buffer is done, my
problem is that

I am not sure how to pass the framebuffer and update the python window.

Any suggestion is appreciated.

 Cheers,

Thanks.

Re: [PyOpenGL-Users] Attempt to retrieve context when no valid context - repost

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

Mads Ipsen wrote:
...
> I am running an app in a PyQt based QGLWidget. If the window is minimized,
> and the method for rendering the object that should be displayed is
> called, I get the error 'OpenGL.error.Error: Attempt to retrieve context
> when no
> valid context' (included below), when glColorPointerd() is called.
>   
This is actually *not* really a necessary operation for any situation 
where you have retained a pointer to your data and avoided any data-copy 
operations, but if GetCurrentContext() is returning null you're likely 
going to blow up at some point anyway.
> Is there:
>
> * a way to check whether a valid context is set?
>   
OpenGL.platform.CurrentContextIsValid() -> bool
> * force the context to be set?
>   
This is windowing-system dependent, you will likely find something like 
self.setCurrent() in your QGLWidget, it may not work when the window is 
minimized, however.  I'm a bit surprised that the widget is calling the 
draw callback without doing a setCurrent(), would be more likely that it 
just can't get the context to be current when it's not on-screen.

HTH,
Mike

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

Re: [PyOpenGL-Users] PyOpenGL Release 3.0.0 (final)

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

Lorenzo Mancini wrote:
> Mike C. Fletcher wrote:
>
>> If you have a PyOpenGL code-base you should be looking at reworking 
>> the code in order to eliminate the use of "legacy" APIs before OpenGL 
>> 3.1 drivers become mainstream.
>
> This seems to be OpenGL's direction indeed:
>
> Appendix F "Version 3.0 and Before", page 301
> Appendix G "Version 3.1", page 308
> http://www.opengl.org/registry/doc/glspec31.20090324.pdf
>
>
> But it was my understanding that even when OpenGL 3.1 drivers become 
> mainstream, to obtain a "forward-compatible" 3.x context you will have 
> to explicitly request it, otherwise you will get a 2.x legacy context.
That assumes that your driver has the ability to create a legacy 
context.  While nVidia might be committing to always have a legacy 
context available, the OpenGL 3.1 spec doesn't require having a legacy 
context available.
> Also, when you are using a 3.x context and your vendor chose to 
> implement the GL_ARB_compatibility extension, you can find there all 
> the constants and functions deprecated in 3.0 and removed in 3.1.
Yes, again, with the assumption that your vendor is supporting that 
extension.  With nVidia supporting it we can assume ATI/AMD will likely 
support it as well... which just eliminated any significant benefits 
from the OpenGL 3.1 rewrite :) .

> So it seems to me that allowing any existing PyOpenGL legacy app to 
> continue running on OpenGL 3.1 is unlikely to require changes to the 
> code-base, because:
>
>  * if your driver still supports creating a 2.x context, nothing changes;
>  * if your driver only supports creating a 3.x context, but implements 
> the GL_ARB_compatibility, PyOpenGL extension mechanisms will 
> automatically detect it and expose all constants and functions which 
> it declares.
>
>
> To sum it up, it looks like legacy PyOpenGL apps will be out of luck 
> only if a vendor releases a driver which doesn't allow 2.x contexts 
> creation *and* doesn't implement GL_ARB_compatibility extension.  Does 
> any of this make sense?
No, that's the scope of it, but the question arises: why define 
deprecations at all if no-one is intending to drop the deprecated 
features?  That is, the whole point of the deprecations was to create a 
smaller, lighter, more flexible API that could be more readily 
maintained and extended; something that could compete with DirectX 
head-to-head in games (where there's some really big money).  In the 
OpenGL 3.0 era, we were basically told, "it's changing suck it up", but 
there was a heck of a lot of blow-back from CAD and similar users, while 
the Game users considered it too little too late.

So now we have an extension which re-enables all of the legacy paths, so 
requires all of the complexity 3.1 was supposed to eliminate to be 
present... great for people with legacy code, but unlikely to let OpenGL 
"win" in the games sphere.  Then again, there's not a lot of OpenGL 
games left, so maybe that's not really a concern and the ARB is 
effectively just acknowledging that their remaining community values 
compatibility far more than gaming competitiveness.  Hopefully nVidia 
will implement with the switch with something like a separate legacy 
driver that will let them  do a Longs-Peak-style driver for game 
competitiveness while swapping in a (separate) legacy driver only when 
requested.

Anyway, yes, PyOpenGL will be supporting GL_ARB_compatibility, so if 
your driver supports it, you should be able to use the legacy APIs.  So 
the advice that you will need to recode is probably invalid for most 
users.  (And I apologize, while the 3.1 spec came out a few days before 
PyOpenGL 3.0.0 I hadn't had a chance to read it at the time I wrote the 
release notes).

Have fun,
Mike

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

Re: [PyOpenGL-Users] PyOpenGL Release 3.0.0 (final)

[Lorenzo M. <lma...@de...>]

Mike C. Fletcher wrote:

> If you have a PyOpenGL code-base you should be 
> looking at reworking the code in order to eliminate the use of "legacy" 
> APIs before OpenGL 3.1 drivers become mainstream.

This seems to be OpenGL's direction indeed:

Appendix F "Version 3.0 and Before", page 301
Appendix G "Version 3.1", page 308
http://www.opengl.org/registry/doc/glspec31.20090324.pdf


But it was my understanding that even when OpenGL 3.1 drivers become 
mainstream, to obtain a "forward-compatible" 3.x context you will have 
to explicitly request it, otherwise you will get a 2.x legacy context.

See for example this patch to allow an application to choose between 2.x 
and 3.x context creation, recently committed in SDL trunk:

http://www.nabble.com/OpenGL-3.0-Context-Creation-td22645797.html


Also, when you are using a 3.x context and your vendor chose to 
implement the GL_ARB_compatibility extension, you can find there all the 
constants and functions deprecated in 3.0 and removed in 3.1.


So it seems to me that allowing any existing PyOpenGL legacy app to 
continue running on OpenGL 3.1 is unlikely to require changes to the 
code-base, because:

  * if your driver still supports creating a 2.x context, nothing changes;
  * if your driver only supports creating a 3.x context, but implements 
the GL_ARB_compatibility, PyOpenGL extension mechanisms will 
automatically detect it and expose all constants and functions which it 
declares.


To sum it up, it looks like legacy PyOpenGL apps will be out of luck 
only if a vendor releases a driver which doesn't allow 2.x contexts 
creation *and* doesn't implement GL_ARB_compatibility extension.  Does 
any of this make sense?


Also see this document from nVidia about how they chose to implement 
OpenGL 3.x: http://developer.nvidia.com/object/opengl_3_driver.html

-- 
Lorenzo Mancini

[PyOpenGL-Users] Attempt to retrieve context when no valid context - repost

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

For some reason, this post ended up as a response to a previous post. This
was unintended - sorry.

Hi,

I am running an app in a PyQt based QGLWidget. If the window is minimized,
and the method for rendering the object that should be displayed is
called, I get the error 'OpenGL.error.Error: Attempt to retrieve context
when no
valid context' (included below), when glColorPointerd() is called.

Is there:

* a way to check whether a valid context is set?
* force the context to be set?

Best regards,

Mads

glColorPointerd(colors)
  File
"/home/mpi/svn/quantumconnect/external-libs/build/lib/python2.6/site-packages/OpenGL/wrapper.py",
line 410, in wrapperCall
    cArgs,
  File
"/home/mpi/svn/quantumconnect/external-libs/build/lib/python2.6/site-packages/OpenGL/arrays/arrayhelpers.py",
line 66, in __call__
    contextdata.setValue( self.constant, pyArgs[self.pointerIndex] )
  File
"/home/mpi/svn/quantumconnect/external-libs/build/lib/python2.6/site-packages/OpenGL/contextdata.py",
line 49, in setValue
    context = getContext( context )
  File
"/home/mpi/svn/quantumconnect/external-libs/build/lib/python2.6/site-packages/OpenGL/contextdata.py",
line 32, in getContext
    """Attempt to retrieve context when no valid context"""
OpenGL.error.Error: Attempt to retrieve context when no valid context