pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] Getting Started With PyOpenGL and OpenGL 3.2

[Przemysław L. <an....@gm...>]

Hi!

OpenGL 3 needs separate context. This means that you will get OpenGL 2
as default.
Use:

glutInit(&argc, argv);
glutInitContextVersion(3, 2);
glutInitContextFlags(GLUT_FORWARD_COMPATIBLE);
glutInitContextProfile(GLUT_CORE_PROFILE);

That's C code that will get you OpenGL 3.2 core profile context (if
your hwd/drivers support it).
Do not know PyOpenGL equivalents but should be similar.

[PyOpenGL-Users] How to get OpenGL4 using PyOpenGL

[Przemysław L. <an....@gm...>]

Can I get OpenGL 4 (core profile) with PyOpenGL? (can live with
manually loading needed extensions one by one, but need to know if
they all are in PyOpenGL)

What is state of PyOpenGL development? Main site claim compatibility
only with OGL 3.2.

Re: [PyOpenGL-Users] PyOpenGL/PySide QML interaction bug

[Henry G. <he...@ca...>]

On Wed, 2011-05-11 at 00:25 -0400, Mike C. Fletcher wrote:
> but good luck,

Just to tidy up and conclude this thread, upgrading to git Mesa (well,
actually to xedgers ppa, so it could be anything in there) has made the
problem go away, so I conclude that it was a regression between 10.10
and 11.04.

Although I'd love to have the time and motivation to track down the
specific bug, I don't, so here's to hoping it stays fixed!

All in all a bit of an anticlimax.

Cheers,
Henry

Re: [PyOpenGL-Users] PyOpenGL/PySide QML interaction bug

[Henry G. <he...@ca...>]

On Wed, 2011-05-11 at 00:25 -0400, Mike C. Fletcher wrote:
> I can't test the code on my machine without the firegl driver (older
> radeon only has OpenGL 1.4 support with the free driver), so can't
> confirm behaviour on the OS driver.
> 

That's funny, my OpenGL version is 2.1 using the r600 driver which
should be the same as you.

In case you feeling super keen, I can trigger the bug using the software
mesa driver (enabled with the environment variable
LIBGL_ALWAYS_SOFTWARE=1).

Anyway, I understand this is probably getting beyond the PyOpenGL list.
I'll go and pester the PySide list (which it probably isn't either,
PyQt4 bindings show the same bug).

Thanks,

Henry

Re: [PyOpenGL-Users] PyOpenGL/PySide QML interaction bug

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

On 11-05-10 08:17 AM, Henry Gomersall wrote:
...
> Right, so I've had more of a play. Using the proprietary fglrx driver, I
> have no problems (using the ATI HD4350 card), as expected from Mike's
> tests (btw, all tests are using Ubuntu 11.04).
>
> I've added another example test case to my github repository:
> https://github.com/hgomersall/Blog-Code/tree/master/qml_with_simplegl_bugtest
>
> This adds another two files called broken_wrapper.py and
> hd4350_working_wrapper.py. The external calls that are made in each case
> are identical and everything I know tells me the two wrappers should do
> exactly the same thing. The only difference is an extra function layer
> in hd4350_working_wrapper.py. The code that is run when either wrapper
> file is executed is superficially identical to the code that is run when
> gl_simple.py is executed. The outcomes however are quite different:
>
> 1) gl_simple.py executed: Everything works as expected on both the
> desktop ATI HD4350 (running r600 driver) and the laptop Intel GMA X3100
> (a red triangle and some sliders).
> 2) broken_wrapper.py executed: Hangs with both the desktop and the
> laptop.
> 3) hd4350_working_wrapper.py executed: Runs as expected on the desktop
> ATI HD4350 machine, but hangs on the laptop.
>
> This is the first time if teased apart a difference between the laptop
> and the desktop.
>
> Does this suggest some kind of timing issue? The bug is starting to be
> pretty unpredictable and really needs to be sorted, so assistance is
> *much* appreciated.
Yeah, its definitely beginning to look like some sort of timing or
similar issue where the longer tear-down time of a few modules or
something of that nature is causing some race condition in a thread or
the like.  I gather Qt is creating threads for e.g. your URL-based
loading of the resource file?  IIRC you did not see the same failure
when using direct rendering of the widgets, so we might be seeing some
tear-down problem in that thread?  I see from google that there have
been errors in PySide where image loading threads could cause the
application to hang, it might be possible this is a similar issue, but
likely more subtle in the trigger/race condition causing it.

I can't test the code on my machine without the firegl driver (older
radeon only has OpenGL 1.4 support with the free driver), so can't
confirm behaviour on the OS driver.

Afraid that's not likely much help, but good luck,
Mike

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

Re: [PyOpenGL-Users] PyOpenGL/PySide QML interaction bug

[Henry G. <he...@ca...>]

On Mon, 2011-05-09 at 19:37 +0100, Henry Gomersall wrote:
> I'll try the code with the proprietary driver and report back.
> 

Right, so I've had more of a play. Using the proprietary fglrx driver, I
have no problems (using the ATI HD4350 card), as expected from Mike's
tests (btw, all tests are using Ubuntu 11.04).

I've added another example test case to my github repository:
https://github.com/hgomersall/Blog-Code/tree/master/qml_with_simplegl_bugtest

This adds another two files called broken_wrapper.py and
hd4350_working_wrapper.py. The external calls that are made in each case
are identical and everything I know tells me the two wrappers should do
exactly the same thing. The only difference is an extra function layer
in hd4350_working_wrapper.py. The code that is run when either wrapper
file is executed is superficially identical to the code that is run when
gl_simple.py is executed. The outcomes however are quite different:

1) gl_simple.py executed: Everything works as expected on both the
desktop ATI HD4350 (running r600 driver) and the laptop Intel GMA X3100
(a red triangle and some sliders).
2) broken_wrapper.py executed: Hangs with both the desktop and the
laptop.
3) hd4350_working_wrapper.py executed: Runs as expected on the desktop
ATI HD4350 machine, but hangs on the laptop.

This is the first time if teased apart a difference between the laptop
and the desktop.

Does this suggest some kind of timing issue? The bug is starting to be
pretty unpredictable and really needs to be sorted, so assistance is
*much* appreciated.

Thanks,

Henry

Re: [PyOpenGL-Users] PyOpenGL/PySide QML interaction bug

[Henry G. <he...@ca...>]

On Mon, 2011-05-09 at 14:11 -0400, Mike C. Fletcher wrote:
> We're likely looking at something low-level, as differences in
> hardware/drivers are causing the error to appear/disappear, but I
> don't
> see anything obviously wrong with what you're doing.  I don't have any
> machines updated to 11.11 yet, so we might possibly be looking at an
> 11.11 regression, or a bug in the r600 driver?  If it's easy for you,
> can you test with the FireGL (proprietary) driver or an 11.04 machine?
> 

Whoops, I meant 11.04 :)

I'll try the code with the proprietary driver and report back.

I tried to replicate the bug using the more usual method of directly
controlling an instance of QQLWidget, but couldn't.

Cheers,

Henry

Re: [PyOpenGL-Users] PyOpenGL/PySide QML interaction bug

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

On 11-05-09 11:35 AM, Henry Gomersall wrote:
...
> Is this a bug with primarily PyOpenGL or should I be getting on to
> PySide? Clearly PyOpenGL should handle imports and dependencies without
> breakages.
I don't see the bug(s) with an Kubuntu Natty (11.04), Radeon HD 3650
(with the FireGL bindings).  PyOpenGL doesn't have any internal
threading operations, so the most likely culprit would be something in
PySide keeping the rendering loop running.  Other possible culprits
might be code which is attempting to do cleanup that crashes when the
references to GL or numpy go to None during interpreter shutdown; a
raised exception may be preventing the finalization/destruction of the
context.  That might be in PyOpenGL or elsewhere, but I can't readily
track it down without some traceback or the like.  I suppose it would be
possible that something is doing reference counting for the windows and
winding up with a loop due to something being held by PyOpenGL, but that
seems unlikely given the symptoms.

We're likely looking at something low-level, as differences in
hardware/drivers are causing the error to appear/disappear, but I don't
see anything obviously wrong with what you're doing.  I don't have any
machines updated to 11.11 yet, so we might possibly be looking at an
11.11 regression, or a bug in the r600 driver?  If it's easy for you,
can you test with the FireGL (proprietary) driver or an 11.04 machine?

Good luck,
Mike

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

[PyOpenGL-Users] PyOpenGL/PySide QML interaction bug

[Henry G. <he...@ca...>]

I've been using PyOpenGL in conjunction with PySide (the python Qt
bindings) and QML (Qt's new declarative language). The idea is to have
an OpenGL scene, with a declarative view on top presenting interface
widgets. I describe it a little more here (with a picture):
http://hgomersall.wordpress.com/2011/03/31/qml_with_opengl_using_python/

I had everything working well with my old laptop (Radeon x1400 graphics
card with r300 driver, running Ubuntu 10.10). However, in moving to a
new machine (necessitated by the death of the laptop), I've been
experience an interesting bug, the source of which I am not sure about.

The code that triggers the bug can be found here:
https://github.com/hgomersall/Blog-Code/tree/master/qml_with_simplegl_bugtest

I've attempted to pare the code down to be as simple as possible. The
code is run by calling gl_simple.py. In its checked in state, the code
will function using the workaround described below, but it is simple to
trigger the bug. The program paints a red triangle on a black background
with a few transparent QML widgets on top.

Here is the problem:
The GL commands are split between two classes in two different files:
gl_simple.py and renderer_simple.py, containing the Renderer class
(which is called from gl_simple.py). If "from OpenGL import GL" is
included in any file in addition to gl_simple.py, then the program will
hang and needs to be killed. The workaround used is to pass GL
explicitly to Renderer and to store that within the class instance. This
is how the code is made to work.

In addition, there is a call to import numpy within gl_simple.py. Numpy
is *not* used within my code in gl_simple.py, but if this import is
removed then the program hangs. Numpy has to be imported *before* GL is
imported - doing so after causes the hang.

As mentioned, the bug was triggered by moving to a new machine. This is
running Ubuntu 11.11 with a Radeon 4000 series card and the r600 driver.
The same problem occurred on a laptop running 11.11 and using an Intel
GMA X3100 graphics card.

Is this a bug with primarily PyOpenGL or should I be getting on to
PySide? Clearly PyOpenGL should handle imports and dependencies without
breakages.

Thanks,

Henry Gomersall

[PyOpenGL-Users] PyOpenGL/PySide QML interaction bug

[Henry G. <he...@ca...>]

I've been using PyOpenGL in conjunction with PySide (the python Qt
bindings) and QML (Qt's new declarative language). The idea is to have
an OpenGL scene, with a declarative view on top presenting interface
widgets. I describe it a little more here (with a picture):
http://hgomersall.wordpress.com/2011/03/31/qml_with_opengl_using_python/

I had everything working well with my old laptop (Radeon x1400 graphics
card with r300 driver, running Ubuntu 10.10). However, in moving to a
new machine (necessitated by the death of the laptop), I've been
experience an interesting bug, the source of which I am not sure about.

The code that triggers the bug can be found here:
https://github.com/hgomersall/Blog-Code/tree/master/qml_with_simplegl_bugtest

I've attempted to pare the code down to be as simple as possible. The
code is run by calling gl_simple.py. In its checked in state, the code
will function using the workaround described below, but it is simple to
trigger the bug. The program paints a red triangle on a black background
with a few transparent QML widgets on top.

Here is the problem:
The GL commands are split between two classes in two different files:
gl_simple.py and renderer_simple.py, containing the Renderer class
(which is called from gl_simple.py). If "from OpenGL import GL" is
included in any file in addition to gl_simple.py, then the program will
hang and needs to be killed. The workaround used is to pass GL
explicitly to Renderer and to store that within the class instance. This
is how the code is made to work.

In addition, there is a call to import numpy within gl_simple.py. Numpy
is *not* used within my code in gl_simple.py, but if this import is
removed then the program hangs. Numpy has to be imported *before* GL is
imported - doing so after causes the hang.

As mentioned, the bug was triggered by moving to a new machine. This is
running Ubuntu 11.11 with a Radeon 4000 series card and the r600 driver.
The same problem occurred on a laptop running 11.11 and using an Intel
GMA X3100 graphics card.

Is this a bug with primarily PyOpenGL or should I be getting on to
PySide? Clearly PyOpenGL should handle imports and dependencies without
breakages.

Thanks,

Henry Gomersall

Re: [PyOpenGL-Users] Drawing a bitmap at "native" resolution

[Christopher B. <Chr...@no...>]

On 5/3/11 12:18 AM, Nicolas Rougier wrote:
>
>
> Here is a quick example:

Very nice, thanks!

It's going to take me a bit to digest that, but it looks like all the 
key pieces are there that I need.

And it worked out of the box for me.

again, thanks!

-Chris

>
>
> import sys
> import OpenGL.GL as gl
> import OpenGL.GLU as glu
> import OpenGL.GLUT as glut
>
>
> def on_display():
> global theta, phi
>
> gl.glClear(gl.GL_COLOR_BUFFER_BIT | gl.GL_DEPTH_BUFFER_BIT)
> gl.glColor(0,0,0,1)
>
> # Push rotation matrix onto stack
> gl.glPushMatrix()
> gl.glRotatef(theta, 0,0,1)
> gl.glRotatef(phi, 0,1,0)
>
> # Transform coordinates from 3d space to window 2d
> modelview = gl.glGetDoublev(gl.GL_MODELVIEW_MATRIX)
> projection= gl.glGetDoublev(gl.GL_PROJECTION_MATRIX)
> viewport = gl.glGetIntegerv(gl.GL_VIEWPORT)
> coords = [ ( 1, 1, 1), ( 1, 1, -1),
> ( 1, -1, 1), (-1, 1, 1),
> ( 1, -1, -1), (-1, -1, 1),
> (-1, 1, -1), (-1, -1, -1) ]
> pcoords = []
> for x,y,z in coords:
> pcoords.append(glu.gluProject(x,y,z, modelview, projection, viewport))
>
> # Draw cube
> glut.glutWireCube(2)
>
> # Pop out rotation matrix
> gl.glPopMatrix()
>
> # Setup an orthogonal projection
> gl.glMatrixMode(gl.GL_PROJECTION)
> gl.glPushMatrix()
> gl.glLoadIdentity()
> gl.glOrtho(0, viewport[2], 0, viewport[3], -1, 1)
> gl.glMatrixMode(gl.GL_MODELVIEW)
> gl.glPushMatrix()
> gl.glLoadIdentity()
> for x,y,z in pcoords:
> gl.glBegin(gl.GL_LINE_LOOP)
> gl.glVertex(x-20,y-5,0), gl.glVertex(x-20,y+5,0)
> gl.glVertex(x+20,y+5,0), gl.glVertex(x+20,y-5,0)
> gl.glEnd()
> gl.glMatrixMode(gl.GL_PROJECTION)
> gl.glPopMatrix()
> gl.glMatrixMode(gl.GL_MODELVIEW)
> gl.glPopMatrix()
> glut.glutSwapBuffers()
>
>
> def on_reshape(width, height):
> gl.glViewport(0, 0, width, height)
> gl.glMatrixMode( gl.GL_PROJECTION )
> gl.glLoadIdentity( )
> glu.gluPerspective( 45.0, float(width)/float(height), 2.0, 10.0 )
> gl.glMatrixMode( gl.GL_MODELVIEW )
> gl.glLoadIdentity( )
> gl.glTranslatef( 0.0, 0.0, -5.0 )
>
>
> def on_keyboard(key, x, y):
> if key == '\033':
> sys.exit()
>
> def on_timer(value):
> global theta, phi
> theta += 0.25
> phi += 0.25
> glut.glutPostRedisplay()
> glut.glutTimerFunc(10, on_timer, 0)
>
>
> if __name__ == '__main__':
> glut.glutInit(sys.argv)
> glut.glutInitDisplayMode(glut.GLUT_DOUBLE | glut.GLUT_RGB | glut.GLUT_DEPTH)
> glut.glutCreateWindow("Python billboard")
> glut.glutReshapeWindow(400, 400)
> glut.glutDisplayFunc(on_display)
> glut.glutReshapeFunc(on_reshape)
> glut.glutKeyboardFunc(on_keyboard)
> glut.glutTimerFunc(10, on_timer, 0)
> gl.glClearColor(1,1,1,1);
> theta, phi = 0, 0
> glut.glutMainLoop()
>
>
> Nicolas
>
>
>
>
> On May 3, 2011, at 7:31 AM, Ian Mallett wrote:
>
>> On Mon, May 2, 2011 at 3:18 PM, Christopher Barker
>> <Chr...@no... <mailto:Chr...@no...>> wrote:
>>
>>     Hi folks,
>>
>>     Anyone know of a performant way to draw a bitmap at its "native"
>>     resolution -- i.e. one pixel in the bitmap is one pixel on screen,
>>     regardless of zoom level, etc. I think I've heard this referred to as
>>     "billboard" view, but that may be a term specific to one visualization
>>     lib (VTK, maybe)?
>>
>>     Anyway, the task at hand is using bitmaps fonts as textures to do
>>     simple
>>     text labels, lot of them, in a scientific visualization app.
>>
>>     For each data point ( up to 100s of thousands ) we need a little text
>>     label. But we want the text to not change size as the user zooms
>>     in or out.
>>
>> There's not a way to get around projecting the labels' locations on
>> screen. You'd have to use gluProject(...). If you want to be fancy,
>> you can use a vertex shader to project to get each coordinate.
>>
>> From there, set up a 2D view. Then, draw each label at the screen
>> coordinate of its projected location, using textured quads the same
>> size as your textures.
>>
>> Ian
>> ------------------------------------------------------------------------------
>> WhatsUp Gold - Download Free Network Management Software
>> The most intuitive, comprehensive, and cost-effective network
>> management toolset available today. Delivers lowest initial
>> acquisition cost and overall TCO of any competing solution.
>> http://p.sf.net/sfu/whatsupgold-sd_______________________________________________
>> PyOpenGL Homepage
>> http://pyopengl.sourceforge.net
>> _______________________________________________
>> PyOpenGL-Users mailing list
>> PyO...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>

-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [PyOpenGL-Users] Drawing a bitmap at "native" resolution

[Christopher B. <Chr...@no...>]

On 5/2/11 10:31 PM, Ian Mallett wrote:
> There's not a way to get around projecting the labels' locations on
> screen.

right -- I knew that the trick was how to project the location, but not 
the label itself.

>  You'd have to use gluProject(...).  If you want to be fancy,
> you can use a vertex shader to project to get each coordinate.

but how? Anyway, it looks like that may not be neccessary, so I can put 
off learning that.

>  From there, set up a 2D view.  Then, draw each label at the screen
> coordinate of its projected location, using textured quads the same size
> as your textures.

this is the part I don't get -- but i see that Nicolas has given me a 
demo of that!

thanks,

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [PyOpenGL-Users] Drawing a bitmap at "native" resolution

[Nicolas R. <Nic...@in...>]

Here is a quick example:



import sys
import OpenGL.GL as gl
import OpenGL.GLU as glu
import OpenGL.GLUT as glut


def on_display():
    global theta, phi

    gl.glClear(gl.GL_COLOR_BUFFER_BIT | gl.GL_DEPTH_BUFFER_BIT)
    gl.glColor(0,0,0,1)

    # Push rotation matrix onto stack
    gl.glPushMatrix()
    gl.glRotatef(theta, 0,0,1)
    gl.glRotatef(phi, 0,1,0)

    # Transform coordinates from 3d space to window 2d
    modelview = gl.glGetDoublev(gl.GL_MODELVIEW_MATRIX)
    projection= gl.glGetDoublev(gl.GL_PROJECTION_MATRIX)
    viewport  = gl.glGetIntegerv(gl.GL_VIEWPORT)
    coords  = [ ( 1,  1,  1), ( 1,  1, -1),
                ( 1, -1,  1), (-1,  1,  1),
                ( 1, -1, -1), (-1, -1,  1),
                (-1,  1, -1), (-1, -1, -1) ]
    pcoords = []
    for x,y,z in coords:
        pcoords.append(glu.gluProject(x,y,z, modelview, projection, viewport))

    # Draw cube
    glut.glutWireCube(2)

    # Pop out rotation matrix
    gl.glPopMatrix()

    # Setup an orthogonal projection
    gl.glMatrixMode(gl.GL_PROJECTION)
    gl.glPushMatrix()
    gl.glLoadIdentity()
    gl.glOrtho(0, viewport[2], 0, viewport[3], -1, 1)
    gl.glMatrixMode(gl.GL_MODELVIEW)
    gl.glPushMatrix()
    gl.glLoadIdentity()
    for x,y,z in pcoords:
        gl.glBegin(gl.GL_LINE_LOOP)
        gl.glVertex(x-20,y-5,0), gl.glVertex(x-20,y+5,0)
        gl.glVertex(x+20,y+5,0), gl.glVertex(x+20,y-5,0)
        gl.glEnd()
    gl.glMatrixMode(gl.GL_PROJECTION)
    gl.glPopMatrix()
    gl.glMatrixMode(gl.GL_MODELVIEW)
    gl.glPopMatrix()
    glut.glutSwapBuffers()


def on_reshape(width, height):
    gl.glViewport(0, 0, width, height)
    gl.glMatrixMode( gl.GL_PROJECTION )
    gl.glLoadIdentity( )
    glu.gluPerspective( 45.0, float(width)/float(height), 2.0, 10.0 )
    gl.glMatrixMode( gl.GL_MODELVIEW )
    gl.glLoadIdentity( )
    gl.glTranslatef( 0.0, 0.0, -5.0 )


def on_keyboard(key, x, y):
    if key == '\033':
        sys.exit()

def on_timer(value):
    global theta, phi
    theta += 0.25
    phi += 0.25
    glut.glutPostRedisplay()
    glut.glutTimerFunc(10, on_timer, 0)


if __name__ == '__main__':
    glut.glutInit(sys.argv)
    glut.glutInitDisplayMode(glut.GLUT_DOUBLE | glut.GLUT_RGB | glut.GLUT_DEPTH)
    glut.glutCreateWindow("Python billboard")
    glut.glutReshapeWindow(400, 400)
    glut.glutDisplayFunc(on_display)
    glut.glutReshapeFunc(on_reshape)
    glut.glutKeyboardFunc(on_keyboard)
    glut.glutTimerFunc(10, on_timer, 0)
    gl.glClearColor(1,1,1,1);
    theta, phi = 0, 0
    glut.glutMainLoop()


Nicolas




On May 3, 2011, at 7:31 AM, Ian Mallett wrote:

> On Mon, May 2, 2011 at 3:18 PM, Christopher Barker <Chr...@no...> wrote:
> Hi folks,
> 
> Anyone know of a performant way to draw a bitmap at its "native"
> resolution -- i.e. one pixel in the bitmap is one pixel on screen,
> regardless of zoom level, etc. I think I've heard this referred to as
> "billboard" view, but that may be a term specific to one visualization
> lib (VTK, maybe)?
> 
> Anyway, the task at hand is using bitmaps fonts as textures to do simple
> text labels, lot of them, in a scientific visualization app.
> 
> For each data point ( up to 100s of thousands ) we need a little text
> label. But we want the text to not change size as the user zooms in or out.
> There's not a way to get around projecting the labels' locations on screen.  You'd have to use gluProject(...).  If you want to be fancy, you can use a vertex shader to project to get each coordinate.
> 
> From there, set up a 2D view.  Then, draw each label at the screen coordinate of its projected location, using textured quads the same size as your textures.
> 
> Ian
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network 
> management toolset available today.  Delivers lowest initial 
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd_______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users

Re: [PyOpenGL-Users] Drawing a bitmap at "native" resolution

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

On Mon, May 2, 2011 at 3:18 PM, Christopher Barker <Chr...@no...>wrote:

> Hi folks,
>
> Anyone know of a performant way to draw a bitmap at its "native"
> resolution -- i.e. one pixel in the bitmap is one pixel on screen,
> regardless of zoom level, etc. I think I've heard this referred to as
> "billboard" view, but that may be a term specific to one visualization
> lib (VTK, maybe)?
>
> Anyway, the task at hand is using bitmaps fonts as textures to do simple
> text labels, lot of them, in a scientific visualization app.
>
> For each data point ( up to 100s of thousands ) we need a little text
> label. But we want the text to not change size as the user zooms in or out.
>
There's not a way to get around projecting the labels' locations on screen.
You'd have to use gluProject(...).  If you want to be fancy, you can use a
vertex shader to project to get each coordinate.

>From there, set up a 2D view.  Then, draw each label at the screen
coordinate of its projected location, using textured quads the same size as
your textures.

Ian

[PyOpenGL-Users] Drawing a bitmap at "native" resolution

[Christopher B. <Chr...@no...>]

Hi folks,

Anyone know of a performant way to draw a bitmap at its "native" 
resolution -- i.e. one pixel in the bitmap is one pixel on screen, 
regardless of zoom level, etc. I think I've heard this referred to as 
"billboard" view, but that may be a term specific to one visualization 
lib (VTK, maybe)?

Anyway, the task at hand is using bitmaps fonts as textures to do simple 
text labels, lot of them, in a scientific visualization app.

For each data point ( up to 100s of thousands ) we need a little text 
label. But we want the text to not change size as the user zooms in or out.

Our current solution is something like this:

Each label is a texture (actually, I think a piece of a big texture).

When rendering, we calculate where the corners of the label should be in 
world coordinates, so that it scales to one pixel per pixel. This does 
produce the desired result.

The problem with this is that with each draw call, those coordinates 
need to be re-calculated. This can be pretty slow, particularly in 
python. We've got numpy doing it now, but that requires some pretty big 
arrays of coordinates to be kept around, which take up memory, and is 
still a bit pokey.

Is there any way to do this directly in OpenGL?

Or, if not, it seems that we may be able to use a shader to do that 
coordinate calculation -- should that be doable? I have no idea where to 
even start with that.

(this a 2D app, but I think the principle is the same either way)

Any suggestions would be appreciated.

-Chris







-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [PyOpenGL-Users] VBO memory not cleaned up ?

[Michka P. <mic...@gm...>]

Oups sorry, the bug came from me not updating the good variable for my index
array. So "everything" works now.

It works on Mac OS X with python from macports, but not on Ubuntu (I get
only a black screen). I'll have to find out why ...
I'ill open a new thread if I don't find it out.

Sorry for the disturbance

Michka

2011/4/24 Michka Popoff <mic...@gm...>

> Hello
>
> I am trying to use VBO's to display a big colored meshgrid. I have a
> problem, as I think the buffer is not cleared correctly when I delete it.
> What I am doing :
>
> - Calculate the indexes, vertexes and colors of the meshgrid (on init)
> - Buffer
> - Display
> - On user input (by keyboard), change a parameter (call it "z"), and
> recalculate a new meshgrid
>
> But there seem to be some display bugs, some triangles are not on the right
> place, and as I go on with new calculations (new "z"), the grid is more and
> more messed up.
> I tested with going directly to a new meshgrid (with a fixed parameter "z"
> on init) , and the meshgrid is displayed without graphical bug. So the bug
> is not coming from my vertexes array or index array.
>
> So :
> - If I init directly the meshgrid with a specific "z" parameter (for
> example z=6), no problem
> - If I go from z=0 to z=6 (by steps of 1), the grid at z=6 is messed up
>
> I use the VertexBuffer class from Nathan Ostgard (
> http://www.siafoo.net/snippet/185), but a little bit modified :
>
> For the creation of the buffer :
> self.buffer = glGenBuffers(1)
>
> To delete the buffer : (needed to add int() here, without it there is a
> TypeError ...)
> glDeleteBuffers(1, int(self.buffer))
> self.buffer = None
>
> I checked the deletion of the buffer with glIsBuffer, it says that it is
> well deleted (Vertexes, color and indexes buffer).
>
> So what could be the problem ? Should I post some code to show what I am
> doing in detail ?
>
>
> Using python 2.7 and opengl 3.0.1 through macports.
>
> Thank you in advance !
>
> Michka Popoff
>
>
>
> ------------------------------------------------------------------------------
> Fulfilling the Lean Software Promise
> Lean software platforms are now widely adopted and the benefits have been
> demonstrated beyond question. Learn why your peers are replacing JEE
> containers with lightweight application servers - and what you can gain
> from the move. http://p.sf.net/sfu/vmware-sfemails
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>

[PyOpenGL-Users] VBO memory not cleaned up ?

[Michka P. <mic...@gm...>]

Hello

I am trying to use VBO's to display a big colored meshgrid. I have a problem, as I think the buffer is not cleared correctly when I delete it.
What I am doing :

- Calculate the indexes, vertexes and colors of the meshgrid (on init)
- Buffer
- Display
- On user input (by keyboard), change a parameter (call it "z"), and recalculate a new meshgrid

But there seem to be some display bugs, some triangles are not on the right place, and as I go on with new calculations (new "z"), the grid is more and more messed up.
I tested with going directly to a new meshgrid (with a fixed parameter "z" on init) , and the meshgrid is displayed without graphical bug. So the bug is not coming from my vertexes array or index array.

So :
- If I init directly the meshgrid with a specific "z" parameter (for example z=6), no problem
- If I go from z=0 to z=6 (by steps of 1), the grid at z=6 is messed up

I use the VertexBuffer class from Nathan Ostgard (http://www.siafoo.net/snippet/185), but a little bit modified :

For the creation of the buffer :
self.buffer = glGenBuffers(1)

To delete the buffer : (needed to add int() here, without it there is a TypeError ...)
glDeleteBuffers(1, int(self.buffer))
self.buffer = None

I checked the deletion of the buffer with glIsBuffer, it says that it is well deleted (Vertexes, color and indexes buffer).

So what could be the problem ? Should I post some code to show what I am doing in detail ?


Using python 2.7 and opengl 3.0.1 through macports.

Thank you in advance !

Michka Popoff

Re: [PyOpenGL-Users] Basic query regarding glSelectBuffer

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

On 11-04-18 08:39 AM, Abhijeet Rastogi wrote:
> Thanks Davis for your reply.
> But, then in C++ code, I have used it too... ( like in choiche =
> selectBuff[(hits*4)-1];)... So, what will I do in python code?

See the PyOpenGL documentation for glSelectBuffer, in the section Sample
Code References you'll find a few links to sample code, including from
OpenGLContext.  Basically you get back a list from the glRenderMode()
call and you can iterate over the (near,far,names) records in that list:

   
http://pyopengl.sourceforge.net/documentation/manual-3.0/glSelectBuffer.xhtml

HTH,
Mike

>
> On Mon, Apr 18, 2011 at 5:46 PM, Joshua R. Davis <joshuardavis@q.com
> <mailto:joshuardavis@q.com>> wrote:
>
>     You just pass in the buffer size. This is in the code I pointed
>     you to.
>
>     selectionBufferCapacity = 64
>     glSelectBuffer(selectionBufferCapacity)
>
>     Josh
>
>     On 2011 Apr 18, at 7:06 AM, Abhijeet Rastogi wrote:
>
>     > Also, I have noticed that in python, glSelectBuffer (size) →
>     None is the specification. So, how am I supposed to use
>     selectBuff. Because in C++, we also pass selectBuff's reference to
>     the function.
>     >
>     > On Mon, Apr 18, 2011 at 5:33 PM, Abhijeet Rastogi
>     <abh...@gm... <mailto:abh...@gm...>> wrote:
>     > Hi,
>     >
>     > I am not clear as to how do we use glSelectBuffer in pyopengl.
>     >
>     > So far, I have tried to convert it to python and my attempt is
>     as follows:
>     > Python code:- http://sprunge.us/JPUj?python
>     > C++ code:- http://sprunge.us/YPhU?c++
>     >
>     >
>     >
>     >
>     > --
>     > Regards,
>     > Abhijeet Rastogi (shadyabhi)
>     > http://www.google.com/profiles/abhijeet.1989
>     >
>     ------------------------------------------------------------------------------
>     > Benefiting from Server Virtualization: Beyond Initial Workload
>     > Consolidation -- Increasing the use of server virtualization is
>     a top
>     > priority.Virtualization can reduce costs, simplify management,
>     and improve
>     > application availability and disaster protection. Learn more
>     about boosting
>     > the value of server virtualization.
>     http://p.sf.net/sfu/vmware-sfdev2dev_______________________________________________
>     > PyOpenGL Homepage
>     > http://pyopengl.sourceforge.net
>     > _______________________________________________
>     > PyOpenGL-Users mailing list
>     > PyO...@li...
>     <mailto:PyO...@li...>
>     > https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
>     Joshua R. Davis    joshuardavis@q.com <mailto:joshuardavis@q.com>
>
>
>
>
>
>
> -- 
> Regards,
> Abhijeet Rastogi (shadyabhi)
> http://www.google.com/profiles/abhijeet.1989
>
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload 
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve 
> application availability and disaster protection. Learn more about boosting 
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
>
>
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users


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

Re: [PyOpenGL-Users] Basic query regarding glSelectBuffer

[Abhijeet R. <abh...@gm...>]

Thanks Davis for your reply.
But, then in C++ code, I have used it too... ( like in choiche =
selectBuff[(hits*4)-1];)... So, what will I do in python code?

On Mon, Apr 18, 2011 at 5:46 PM, Joshua R. Davis <joshuardavis@q.com> wrote:

> You just pass in the buffer size. This is in the code I pointed you to.
>
> selectionBufferCapacity = 64
> glSelectBuffer(selectionBufferCapacity)
>
> Josh
>
> On 2011 Apr 18, at 7:06 AM, Abhijeet Rastogi wrote:
>
> > Also, I have noticed that in python, glSelectBuffer (size) → None is the
> specification. So, how am I supposed to use selectBuff. Because in C++, we
> also pass selectBuff's reference to the function.
> >
> > On Mon, Apr 18, 2011 at 5:33 PM, Abhijeet Rastogi <
> abh...@gm...> wrote:
> > Hi,
> >
> > I am not clear as to how do we use glSelectBuffer in pyopengl.
> >
> > So far, I have tried to convert it to python and my attempt is as
> follows:
> > Python code:- http://sprunge.us/JPUj?python
> > C++ code:- http://sprunge.us/YPhU?c++
> >
> >
> >
> >
> > --
> > Regards,
> > Abhijeet Rastogi (shadyabhi)
> > http://www.google.com/profiles/abhijeet.1989
> >
> ------------------------------------------------------------------------------
> > Benefiting from Server Virtualization: Beyond Initial Workload
> > Consolidation -- Increasing the use of server virtualization is a top
> > priority.Virtualization can reduce costs, simplify management, and
> improve
> > application availability and disaster protection. Learn more about
> boosting
> > the value of server virtualization.
> http://p.sf.net/sfu/vmware-sfdev2dev_______________________________________________
> > PyOpenGL Homepage
> > http://pyopengl.sourceforge.net
> > _______________________________________________
> > PyOpenGL-Users mailing list
> > PyO...@li...
> > https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>
> Joshua R. Davis    joshuardavis@q.com
>
>
>
>


-- 
Regards,
Abhijeet Rastogi (shadyabhi)
http://www.google.com/profiles/abhijeet.1989

Re: [PyOpenGL-Users] Basic query regarding glSelectBuffer

[Joshua R. D. <joshuardavis@q.com>]

You just pass in the buffer size. This is in the code I pointed you to.

selectionBufferCapacity = 64
glSelectBuffer(selectionBufferCapacity)

Josh

On 2011 Apr 18, at 7:06 AM, Abhijeet Rastogi wrote:

> Also, I have noticed that in python, glSelectBuffer (size) → None is the specification. So, how am I supposed to use selectBuff. Because in C++, we also pass selectBuff's reference to the function.
> 
> On Mon, Apr 18, 2011 at 5:33 PM, Abhijeet Rastogi <abh...@gm...> wrote:
> Hi,
> 
> I am not clear as to how do we use glSelectBuffer in pyopengl.
> 
> So far, I have tried to convert it to python and my attempt is as follows:
> Python code:- http://sprunge.us/JPUj?python
> C++ code:- http://sprunge.us/YPhU?c++
>  
> 
> 
> 
> -- 
> Regards,
> Abhijeet Rastogi (shadyabhi)
> http://www.google.com/profiles/abhijeet.1989
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload 
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve 
> application availability and disaster protection. Learn more about boosting 
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev_______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users

Joshua R. Davis    joshuardavis@q.com

Re: [PyOpenGL-Users] Basic query regarding glSelectBuffer

[Abhijeet R. <abh...@gm...>]

Also, I have noticed that in python, *glSelectBuffer (size) → None *is the
specification. So, how am I supposed to use selectBuff. Because in C++, we
also pass selectBuff's reference to the function.

On Mon, Apr 18, 2011 at 5:33 PM, Abhijeet Rastogi
<abh...@gm...>wrote:

> Hi,
>
> I am not clear as to how do we use glSelectBuffer in pyopengl.
>
> So far, I have tried to convert it to python and my attempt is as follows:
> *Python code:- http://sprunge.us/JPUj?python
> C++ code:- http://sprunge.us/YPhU?c++*
>  **
>



-- 
Regards,
Abhijeet Rastogi (shadyabhi)
http://www.google.com/profiles/abhijeet.1989

[PyOpenGL-Users] Basic query regarding glSelectBuffer

[Abhijeet R. <abh...@gm...>]

Hi,

I am not clear as to how do we use glSelectBuffer in pyopengl.

So far, I have tried to convert it to python and my attempt is as follows:
*Python code:- http://sprunge.us/JPUj?python
C++ code:- http://sprunge.us/YPhU?c++*

*Corresponding C++ code is (If you want just the part required):-*
// Space for selection buffer
static GLuint selectBuff[BUFFER_LENGTH];
//Something else
//Setup selection buffer
glSelectBuffer(BUFFER_LENGTH, selectBuff);

//Some more stuff, and its now used in the code like
hits = glRenderMode(GL_RENDER);
//Other stuff..
if(hits > 0){ //something's been selected
        unsigned int choiche;

        // fi there's more than one figure (or control point) selected, take
the top one
        if (hits > 1)
          choiche = selectBuff[(hits*4)-1];
        else
          choiche = selectBuff[3];

        cpsel = false;
        if (win == 1) {
          selWin1(selectBuff);
        }
        else if (win == 2){
             sel = true;
             if (choiche < figureSet.size()) // figure selected
                selected = choiche;
             else{ // it's a control point
                cpsel = true;
                cp = choiche;
             }
        }
     }
___________________________________________________________




A quick reply will be highly appreciated as I have a deadline to submit a
project.
-- 
Regards,
Abhijeet Rastogi (shadyabhi)
http://www.google.com/profiles/abhijeet.1989

Re: [PyOpenGL-Users] Converted C++ project to python project (some issues)

[Abhijeet R. <abh...@gm...>]

On Mon, Apr 18, 2011 at 4:41 AM, Mike C. Fletcher <mcf...@vr...>wrote:

>
> You are calling glGenTextures before you have a valid OpenGL context,
> this results in getting 4 values of 0 for the textures.  Instead, only
>

Instead of doing

textures = glGenTextures(TEX_COUNT)

in main, I did it in drawRAWs function

global textures
textures = glGenTextures(TEX_COUNT)

Now, the textures are loaded perfectly but they are not selected and give
some error. Googling (
http://pyopengl.sourceforge.net/documentation/opengl_diffs.html) told me
that there are some differences the way selection buffers are handled. By
the way, the error which I get is

Traceback (most recent call last):
  File "_ctypes/callbacks.c", line 313, in 'calling callback function'
  File "main.py", line 651, in mouseWin2
    selection(x, y, 2)
  File "main.py", line 299, in selection
    choiche = selectBuff[(hits*4)-1]
TypeError: unsupported operand type(s) for -: 'list' and 'int'


I know, I have used python datatype wrongly. I am figuring out how to do it.
If I am not successful, I will ask the question on mailling list again.
Thanks for your helo so far.

-- 
Regards,
Abhijeet Rastogi (shadyabhi)
http://www.google.com/profiles/abhijeet.1989

Re: [PyOpenGL-Users] Converted C++ project to python project (some issues)

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

On 11-04-17 06:50 PM, Derakon wrote:
> On Sun, Apr 17, 2011 at 3:36 PM, Abhijeet Rastogi
> <abh...@gm...> wrote:
>> I have tried my best to explain the issue. Its probably a very small issue
>> with textures variable acquiring None value but I am not able to solve the
>> bug.
> Have you tried printing the value of the textures variable after each
> time it's changed? That should quickly tell you where it's going
> wrong.
>
> -Chris

Abhijeet, here's the changes I needed to make to get what I *think* is a working version of your code...


mcfletch@sturm:~/OpenGL-dev/imagesnone$ diff -w main-orig.py main.py
177c177
< textures = glGenTextures(TEX_COUNT)
---
> textures = None
318a319,321
>         global textures
>         if not textures:
>             textures = glGenTextures(TEX_COUNT)
325d327
<               global textures

You are calling glGenTextures before you have a valid OpenGL context,
this results in getting 4 values of 0 for the textures.  Instead, only
generate the texture ids the first time you need them.  BTW, watch your
indentation in Python, try to use either 4-space indents or if you feel
very strongly about it, literal tab characters, mixing tabs and spaces
is considered very bad form.

The modified form does not produce any tracebacks on my machine (a Linux
Ubuntu machine) until I hit one of the "buttons" in the palette.  Don't
have time to track down what that is, but it's likely a problem where
the return type for select buffer is a custom object type in PyOpenGL.

Good luck,
Mike
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload 
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve 
> application availability and disaster protection. Learn more about boosting 
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users


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

Re: [PyOpenGL-Users] Converted C++ project to python project (some issues)

[Derakon <de...@gm...>]

On Sun, Apr 17, 2011 at 3:36 PM, Abhijeet Rastogi
<abh...@gm...> wrote:
> I have tried my best to explain the issue. Its probably a very small issue
> with textures variable acquiring None value but I am not able to solve the
> bug.

Have you tried printing the value of the textures variable after each
time it's changed? That should quickly tell you where it's going
wrong.

-Chris