pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] Fastest way to draw lots of points

[Chris B. <chr...@no...>]

On Fri, Oct 19, 2012 at 10:02 AM, Ryan Hope <rm...@gm...> wrote:
> I think miss the point that this is a moving star field, the points
> are in new locations every frame. I dont see how display lists can
> help with dynamic data.

You're right, that when the data are changing (not jsut the view on
the data) you lose much of the benefit of OpenGL. NOne the less, you
still can get benefit, particularly in Python, from using VBOs -- that
way there is no looping in Python -- you can build a VBO from a numpy
array at the speed of C.

Display lists probably wont' help as you would still need to build up
the list -- it's also old-style and practically deprecated approach.

-Chris

> On Fri, Oct 19, 2012 at 1:00 PM, Ian Mallett <geo...@gm...> wrote:
>> The most efficient ways to draw points are none of what you have here. You
>> should look into display lists (or better, VBOs).


-- 

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] Fastest way to draw lots of points

[Rajan <nag...@gm...>]

The usual idea is that the star field is in one place and the camera moves
through it, so the star field can stay static.

If you want to move your star field and keep the camera in one place (like
a hail storm), you can still get away with a static star field and a shader
which adds the dynamic nature to the star field. The shader can take as
input the time as parameter and add offset to each starfield coordinate
depending on the time.

This will be much much faster than sending new starfield coordinates each
frame.
A major rule of thumb for fast graphics... transfer minimum data between
CPU / GPU - whatever you want to send, do it in the beginning and
manipulate stuff on the GPU.

On Fri, Oct 19, 2012 at 10:02 AM, Ryan Hope <rm...@gm...> wrote:

> I think miss the point that this is a moving star field, the points
> are in new locations every frame. I dont see how display lists can
> help with dynamic data.
>
> On Fri, Oct 19, 2012 at 1:00 PM, Ian Mallett <geo...@gm...> wrote:
> > The most efficient ways to draw points are none of what you have here.
> You
> > should look into display lists (or better, VBOs).
> >
> > Most of your overhead is caused by having to transfer all the data across
> > the graphics bus to the GPU each frame. Display lists and VBOs both
> transfer
> > the data once and then invoke the GPU to draw the cached data.
> >
> > Ian
>
>
>
> --
> Ryan Hope, M.S.
> CogWorks Lab
> Cognitive Science Department
> Rensselaer Polytechnic Institute
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>

Re: [PyOpenGL-Users] Fastest way to draw lots of points

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

On Fri, Oct 19, 2012 at 10:02 AM, Ryan Hope <rm...@gm...> wrote:
> I think miss the point that this is a moving star field, the points
> are in new locations every frame. I dont see how display lists can
> help with dynamic data.

If the points aren't changing with respect to each other (e.g. they
just scroll as the view changes) then you should still be able to use
a display list, yes? Just set up your view transform before using the
display list.

Of course, if you're manually scrolling the stars then this wouldn't
work. So don't manually scroll the stars. :)

>
> On Fri, Oct 19, 2012 at 1:00 PM, Ian Mallett <geo...@gm...> wrote:
>> The most efficient ways to draw points are none of what you have here. You
>> should look into display lists (or better, VBOs).
>>
>> Most of your overhead is caused by having to transfer all the data across
>> the graphics bus to the GPU each frame. Display lists and VBOs both transfer
>> the data once and then invoke the GPU to draw the cached data.
>>
>> Ian
>
>
>
> --
> Ryan Hope, M.S.

-Chris

[PyOpenGL-Users] 3d globe?

[Tony P. <emp...@gm...>]

how can i get example of 3d glboe earth projection with simple texture
image of the blue marble or openstreetmap or like satellite . with a simple
point into 0,0 and of course could be rotate ?
is for try including into pyqt qtabwidget ...
any idea?

-- 
Antonio Peña
Secure email with PGP 0x8B021001 available at http://pgp.mit.edu
 Fingerprint: 74E6 2974 B090 366D CE71  7BB2 6476 FA09 8B02 1001

Re: [PyOpenGL-Users] Fastest way to draw lots of points

[Ryan H. <rm...@gm...>]

I think miss the point that this is a moving star field, the points
are in new locations every frame. I dont see how display lists can
help with dynamic data.

On Fri, Oct 19, 2012 at 1:00 PM, Ian Mallett <geo...@gm...> wrote:
> The most efficient ways to draw points are none of what you have here. You
> should look into display lists (or better, VBOs).
>
> Most of your overhead is caused by having to transfer all the data across
> the graphics bus to the GPU each frame. Display lists and VBOs both transfer
> the data once and then invoke the GPU to draw the cached data.
>
> Ian



-- 
Ryan Hope, M.S.
CogWorks Lab
Cognitive Science Department
Rensselaer Polytechnic Institute

Re: [PyOpenGL-Users] Fastest way to draw lots of points

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

The most efficient ways to draw points are none of what you have here. You
should look into display lists (or better, VBOs).

Most of your overhead is caused by having to transfer all the data across
the graphics bus to the GPU *each frame*. Display lists and VBOs both
transfer the data once and then invoke the GPU to draw the cached data.

Ian

[PyOpenGL-Users] Fastest way to draw lots of points

[Ryan H. <rm...@gm...>]

I am working on a pygame app that I recently converted to using opegl
for the backend. The game has a parallax star field in the background
so I have been looking for the most efficient way of drawing multiple
points. My game updates the display every 33ms. Bellow are the draw
points methods I have tried.

def point(point, color, size=1.0, alpha=255.0):
    glPointSize(size)
    glDisable(GL_TEXTURE_2D)
    glBegin(GL_POINTS)
    glColor4f(color[0] / 255.0, color[1] / 255.0, color[2] / 255.0,
alpha / 255.0)
    glVertex3f(point[0], point[1], 0)
    glEnd()
    glEnable(GL_TEXTURE_2D)

def points(points, indices, color, size=1.0, alpha=255.0):
    glPointSize(size)
    glDisable(GL_TEXTURE_2D)
    glColor4f(color[0] / 255.0, color[1] / 255.0, color[2] / 255.0,
alpha / 255.0)
    glEnableClientState(GL_VERTEX_ARRAY)
    glVertexPointer(2, GL_FLOAT, 0, points)
    glDrawElementsui(GL_POINTS, indices)
    glDisableClientState(GL_VERTEX_ARRAY)
    glEnable(GL_TEXTURE_2D)

def points2(points, color, size=1.0, alpha=255.0):
    glPointSize(size)
    glDisable(GL_TEXTURE_2D)
    glBegin(GL_POINTS)
    glColor4f(color[0] / 255.0, color[1] / 255.0, color[2] / 255.0,
alpha / 255.0)
    for p in points:
        glVertex2f(p[0], p[1])
    glEnd()
    glEnable(GL_TEXTURE_2D)

I've tested these with different size arrays of points, a small array
of 250 and a large array of 2000.

The first of the 3 methods I would obviously call N times in a loop.
For the small array this is not an issue but for the larger array the
overhead of glBegin starts to take over.
The second method is better than the first but there are some weird
numpy array operations that occur and add overhead with some weird
interactions. If points is a regular python list there seems to be a
linear increase in time with more points. If I points is a numpy array
of dtype="f" it starts faster but seems to increase non-linearly. The
fastest solution is the third function regardless of the size of the
array. Does anyone have any thoughts on this or ideas of how I can
improve any of these methods?



-- 
Ryan Hope, M.S.
CogWorks Lab
Cognitive Science Department
Rensselaer Polytechnic Institute

Re: [PyOpenGL-Users] Documentation about configuring OpenGLContext

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

On 12-10-15 10:40 AM, Tómas Þór Jónsson wrote:
> Hi,
>
> Is there any documentation about how to set, for example the window 
> size that TestContext creates? Or where on the screen it's positioned? 
> Basically stuff that in "old" OpenGL GLUT handles.
The documentation is pretty fragmentary, basically you need to create a 
ContextDefinition object:

http://pyopengl.sourceforge.net/pydoc/OpenGLContext.contextdefinition.html 
<http://pyopengl.sourceforge.net/pydoc/OpenGLContext.context.html>

if __name__ == "__main__":
     from OpenGLContext import contextdefinition
     TestContext.ContextMainLoop(
         definition = contextdefinition.ContextDefinition(
             size = (800,500 ),
         )
     )

which then is passed into the mainloop, which passes it into the 
context.Context() __init__ call.  The various GL features (bit depths 
and the like) are controlled the same way.  Each concrete Context 
sub-class (GLUTContext, PyGameContext, wxContext) then examines the 
ContextDefinition to set up the various features.  The 
ContextDefinitions can be populated from a ConfigParser, should you want 
to do that.

I'll try to add a bit of documentation about this stuff (and maybe make 
the API a little easier too) for the next OpenGLContext release.

Thanks,
Mike

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

[PyOpenGL-Users] Documentation about configuring OpenGLContext

[Tómas Þ. J. <be...@gm...>]

Hi,

Is there any documentation about how to set, for example the window size
that TestContext creates? Or where on the screen it's positioned? Basically
stuff that in "old" OpenGL GLUT handles.

Regards,
Tomas

[PyOpenGL-Users] PyOpenGL 3.0.2 Released

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

PyOpenGL 3.0.2 (final, finally) has been released.  The major changes since 3.0.1 (released in 2010!) are:

   * OpenGL core support up to 4.3 level [1]
   * OpenGL extension support from the current registry [1]
   * Some missing FreeGLUT extensions added
   * OpenGL.GL.framebufferobjects providing ARB/EXT alternates for framebuffer operations
   * Experimental OSMesa (Offscreen Mesa) context (use the environment variable PYOPENGL_PLATFORM=osmesa)

Codebase changes:

   * Experimental Python 3.2 and PyPy support
   * Win64 Support (including OpenGL_accelerate)
   * Numarray (the ancient transitional module between Numeric and numpy) is no longer supported as an array type
   * More compact auto-generated wrappers
   * Large numbers of bug fixes

Downloads are at:

     http://pypi.python.org/pypi/PyOpenGL/3.0.2
     http://pypi.python.org/pypi/PyOpenGL-accelerate/3.0.2

Future Compatibility Notes:

  * This will be the last release of PyOpenGL to support Python 2.5 (and
    it supports Python 2.5 in source-release only mode).
      o PyOpenGL will be moving to a "shared code" approach for Python
        2/3 support, which makes supporting the older Python releases
        problematic
  * This will be the last release to support the use of bare numbers as
    number-array data-types
      o i.e. passing 1.00 to a function expecting an array/address of an
        float
      o Use Glfloat( 1.00 ) to pass in an array-compatible value
      o Passing in an int/long will generate a GLvoidp( I ) to allow for
        easy offset-address-style API usage
  * The ancient Numeric package (as distinct from Numpy) will be dropped
    as a supported array format
      o Numeric itself has long since been deprecated, use Numpy

Enjoy all,
Mike

[1] Note: OpenGL extension and higher-level core feature support is auto-generated. As always, we are limited by the number of test programs that exercise more advanced features and the availability of hardware that can support the features on which to test
  
-- ________________________________________________ Mike C. Fletcher 
Designer, VR Plumber, Coder http://www.vrplumber.com 
http://blog.vrplumber.com

[PyOpenGL-Users] VBO Attribute Error with pyinstaller

[家. <pa...@fo...>]

Dear pyopengl-users,
      I've write a script using pyopengl.arrays.vbo, it works fine. When I use pyinstaller to make exe, it got AttributeError. 
      And a same error report was found on stackoverflow:
      pyOpenGL exe made with PyInstaller gives attributeerror
      http://stackoverflow.com/questions/11011373/pyopengl-exe-made-with-pyinstaller-gives-attributeerror
      Is there any solution for this problem?
      Thanks!
                                                Teddy Qian

Re: [PyOpenGL-Users] glGenFramebuffers undefined

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

On 12-09-12 02:13 PM, Chris Weisiger wrote:
> (Sorry for the spam to the moderators -- I hadn't finished processing
> my membership before sending the first copy of this message)
>
> I have a program I wrote that works fine on OSX*, but is failing on
> Windows when I call gnGenFramebuffers. The exact error message is:
>
> Attempt to call an undefined alternate function (glGenFramebuffers,
> glGenFramebuffersEXT), check for bool(glGenFramebuffers) before
> calling
>
> I can't figure out why this isn't working. If I do try
> glGetBoolean(glGenFramebuffers) then I get this error:
Um, that should be:

      bool( glGenFramebuffers )

or you can just use it in a boolean context, like:

         if not self.haveInited:
             if not glGenFramebuffers:
                 print 'No glGenFramebuffers implementation found'
                 raise SystemExit( 1 )

so the problem becomes, why doesn't your context have glGenFrameBuffers 
or glGenFrameBuffersEXT.  You can see the extensions available to the 
current context like so:

         if not self.haveInited:
             for ext in glGetString( GL_EXTENSIONS ).split():
                 print ext
             print glGetString( GL_VERSION )
             if not glGenFramebuffers:
                 print 'No glGenFramebuffers implementation found'
                 raise SystemExit( 1 )

which will print out the name of each extension on the system, and then 
the core version.  GL_EXT_framebuffer_object, GL_ARB_framebuffer_object 
or a core version of 3.0 or above *should* provide the entry point.

HTH,
Mike

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

[PyOpenGL-Users] glGenFramebuffers undefined

[Chris W. <cwe...@ms...>]

(Sorry for the spam to the moderators -- I hadn't finished processing
my membership before sending the first copy of this message)

I have a program I wrote that works fine on OSX*, but is failing on
Windows when I call gnGenFramebuffers. The exact error message is:

Attempt to call an undefined alternate function (glGenFramebuffers,
glGenFramebuffersEXT), check for bool(glGenFramebuffers) before
calling

I can't figure out why this isn't working. If I do try
glGetBoolean(glGenFramebuffers) then I get this error:

('Unknown specifier <OpenGL.extensions.glGenFramebuffers object at
0x00000000048CBD68>', 'Failure in cConverter
<OpenGL.converters.SizedOutput object at 0x00000000043EC248>',
(<OpenGL.extensions.glGenFramebuffers object at 0x00000000048CBD68>,),
1, <OpenGL.wrapper.glGetIntegerv object at 0x00000000045BCC48>)

I made a simple test application which demonstrates the error:
http://pastebin.com/YnA4hn0y
On OSX it works fine (no errors are printed); on WIndows it will spew
the above-mentioned error. Any ideas what I'm doing wrong here? I've
had no luck with Google.

-Chris

* Well, my graphics card driver causes a kernel panic whenever I step
slightly out of line, but aside from that it works fine...bleah!
That's why I'm trying the Windows machine in the first place.

[PyOpenGL-Users] PyOpenGL 3.0.2b2 is now released

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

This will likely be the final beta before the 3.0.2 final release unless 
a show-stopping bug appears.  The major changes since 3.0.1 (released on 
2010!) to be available in 3.0.2 are:

  * OpenGL extension support up to 4.3 level (note, much of that is
    untested)
  * OpenGL core support up to 4.3 level (same caveat)
  * Some missing FreeGLUT extensions added
  * OpenGL.GL.framebufferobjects providing ARB/EXT alternates for
    framebuffer operations
  * Experimental OSMesa (Offscreen Mesa) context (use the environment
    variable PYOPENGL_PLATFORM=osmesa)

Codebase changes:

  * Experimental Python 3.2 and PyPy support
  * Win64 Support (include OpenGL_accelerate)
  * Numarray (the ancient transitional module between Numeric and numpy)
    is no longer supported as an array type
  * More compact auto-generated wrappers
  * Large numbers of bug fixes

Downloads are at:

http://pypi.python.org/pypi/PyOpenGL/3.0.2b2
http://pypi.python.org/pypi/PyOpenGL-accelerate/3.0.2b2

If you have code that relies on PyOpenGL, please consider testing it 
with the 3.0.2b2 release so that any regressions can be handled before 
the final release.

Enjoy all,
Mike

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

[PyOpenGL-Users] OpenGL 4.3 wrappers are in bzr trunk, next release soon-ish

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

I don't have 4.3 hardware/drivers for my Linux box, so I can't actually 
say if any of it works, but the 4.3 wrappers are (auto-generated) in bzr 
trunk, and should come out with the next release.  The next (beta) 
release should be out fairly soon[1], as we seem to have a working 
Python 3.x story (at least, I don't know of any further bugs/issues 
outstanding there).

As mentioned in another thread, this release (i.e. 3.0.2 final) will be 
the last version of PyOpenGL supporting Python 2.5.  We'll likely start 
moving the code to using e.g. except X as err and similar cross-version 
compatible features.  I expect that 2.x will remain my primary 
development environment, with 3.x supported by 2to3.

Enjoy,
Mike

[1] basically when I get a chance to track down a seeming regression in 
GLU tessellation with callbacks

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

Re: [PyOpenGL-Users] Cleanups and deprecations going forward...

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

On 12-07-02 03:05 PM, Chris Barker wrote:
> (this seems to have gone off-list -- putting it back on)
>
> On Mon, Jul 2, 2012 at 11:37 AM, Gordon Wrigley
> <gor...@gm...> wrote:
>> A bunch of these functions have a pointer argument and an old and new style
>> of use, old style you pass a pointer to the data, new style you pass an
>> integer index into preloaded data. The current API turns an integer argument
>> into a one element list, which is rather awkward for new style use.
> OK -- so is the proposal that the "pass an integer index into
> preloaded data" be translated into python as passing an python integer
> as an index into preloaded data, then yes, this sure seems the obvious
> thing to so. I thought the integer would be interpreted as the value
> of a reference, not as an index. My mis-understanding, I guess.
The current behaviour looks like this (using an OpenGL.arrays.vbo.VBO):

                 glVertexAttribPointer(
                     self.Vertex_normal_loc,
                     3, GL_FLOAT,False, stride, self.coords+(5*4)
                 )

where coords is a VBO.  the VBO +(5*4) creates a thing that produces a 
GLvoidp( 0 + 5*4).  You easily *can* create the GLvoidp( 0 + 5*4 ) 
yourself, of course, but nothing in any C opengl doc will tell you do 
so, as in C you don't need to do the cast yourself.  If you happen to be 
following a C document, you likely *also* won't be using the VBO class 
(which hides these details).

The issue comes with some (generally pretty old) APIs where e.g. you 
want to be able to pass in one or many items (I'm actually struggling to 
think of one off the top of my head, though I do recall that *something* 
broke with PyOpenGL-ctypes when I didn't have it).  They were odd bits 
of code here and there that used the C-level idea that a reference to an 
array of 1 item is just a reference to that item.  Again, really only 
seen when you're following along with a C tutorial, but that's a *lot* 
of what people do with PyOpenGL.  The old behaviour has been around a 
*long* time (I believe from back when PyOpenGL was hand-coded C IIRC), 
likely from before there were any APIs that did the offset-as-pointer 
trick, and I'm really feeling like we could drop the behaviour.
> I guess I need an example or two to understand.
>
> Perhpas I'm also confused by the term "array" in python, there is:
>
> a list
> a tuple
> an array.array
> a numpy ndarray
>
> ... and who knows what else.
In PyOpenGL, the OpenGL.arrays package is what defines it (or any plugin 
you load into that package).  Basically:

  * None
  * bytes (str)
  * ctypes
      o arrays
      o parameters
      o pointers
  * lists/tuples
  * numbers
      o int
      o float
      o long
  * Numeric Python (deprecated)
  * Numpy
      o arrays
      o scalars (with the appropriate flag set)
  * vbo
      o VBO
      o VBOOffset

each of those things has a plug-in that allows that type to be used as 
an array data-type within PyOpenGL.  Some of the types have extra 
features that allow them to be used as output data-types as well.  
(Note: we don't currently have a built-in-array-module plugin).

The numbers plugin is what would be altered, so that instead of doing a 
ctypes byref( int ) it would create a GLvoidp( int ), and would likely 
drop the float types.

Hope that helps,
Mike


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

Re: [PyOpenGL-Users] Cleanups and deprecations going forward...

[Chris B. <chr...@no...>]

(this seems to have gone off-list -- putting it back on)

On Mon, Jul 2, 2012 at 11:37 AM, Gordon Wrigley
<gor...@gm...> wrote:
> A bunch of these functions have a pointer argument and an old and new style
> of use, old style you pass a pointer to the data, new style you pass an
> integer index into preloaded data. The current API turns an integer argument
> into a one element list, which is rather awkward for new style use.

OK -- so is the proposal that the "pass an integer index into
preloaded data" be translated into python as passing an python integer
as an index into preloaded data, then yes, this sure seems the obvious
thing to so. I thought the integer would be interpreted as the value
of a reference, not as an index. My mis-understanding, I guess.

I guess I need an example or two to understand.

Perhpas I'm also confused by the term "array" in python, there is:

a list
a tuple
an array.array
a numpy ndarray

... and who knows what else.

They are all different things. Which were we talking about with:

"""
eliminate the interpretation of numbers as arrays
"""

-CHB

> On Jul 2, 2012 6:41 PM, "Chris Barker" <chr...@no...> wrote:
>>
>> On Sat, Jun 30, 2012 at 7:34 PM, Mike C. Fletcher
>> <mcf...@vr...> wrote:
>> >   * eliminate the interpretation of numbers as arrays, that is, if you
>> >     pass 3 to a function expecting an array of integers you will get a
>> >     pointer to address 3, rather than a pointer to an array with a
>> >     single value of 3
>>
>> So a Python integer gets interpreted as a pointer? That feels prone to
>> error to me, though probably an error that would show itself pretty
>> quickly.
>>
>> Maybe it's to wordy, but what about a "pointer" of "address" object,
>> so ratehr than passing in an integer, you'd pass in:
>>
>> pointer(an_integer)
>>
>> (or you could use a numpy scalar:
>>
>> Then passing in a string integer could either wrap an array around it,
>> or raise an error.
>>
>> And what about passing a float?
>>
>> >       o this will make the Python and C APIs look a lot closer
>>
>> sure, but Python doesn't have pointers -- so being explicit about that
>> would make more sense to me.
>>
>> >         eliminate a common class of issues where someone can't see how
>> >         to pass offsets to modern array functions
>>
>> with this method -- where would the address value come from anyway? I
>> guess in my case, I'd tend to want to use a numpy array, and an offset
>> could be expressed as a slice.
>>
>> By the way, Cython does this pretty naturally, you can do:
>>
>> cdef np.ndarray[double, ndim=1, mode="c"] an_array
>>
>> call_a_function_that_takes_a_pointer( &input[i] )
>>
>> which makes it very easy to do an offset.
>>
>> Thanks for moving PyOpenGL forward.
>>
>> -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...
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> 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] Cleanups and deprecations going forward...

[Chris B. <chr...@no...>]

On Sat, Jun 30, 2012 at 7:34 PM, Mike C. Fletcher
<mcf...@vr...> wrote:
>   * eliminate the interpretation of numbers as arrays, that is, if you
>     pass 3 to a function expecting an array of integers you will get a
>     pointer to address 3, rather than a pointer to an array with a
>     single value of 3

So a Python integer gets interpreted as a pointer? That feels prone to
error to me, though probably an error that would show itself pretty
quickly.

Maybe it's to wordy, but what about a "pointer" of "address" object,
so ratehr than passing in an integer, you'd pass in:

pointer(an_integer)

(or you could use a numpy scalar:

Then passing in a string integer could either wrap an array around it,
or raise an error.

And what about passing a float?

>       o this will make the Python and C APIs look a lot closer

sure, but Python doesn't have pointers -- so being explicit about that
would make more sense to me.

>         eliminate a common class of issues where someone can't see how
>         to pass offsets to modern array functions

with this method -- where would the address value come from anyway? I
guess in my case, I'd tend to want to use a numpy array, and an offset
could be expressed as a slice.

By the way, Cython does this pretty naturally, you can do:

cdef np.ndarray[double, ndim=1, mode="c"] an_array

call_a_function_that_takes_a_pointer( &input[i] )

which makes it very easy to do an offset.

Thanks for moving PyOpenGL forward.

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

[PyOpenGL-Users] Cleanups and deprecations going forward...

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

A few backwards-incompatible things I'm thinking of for PyOpenGL 3.0.3+:

  * eliminate the interpretation of numbers as arrays, that is, if you
    pass 3 to a function expecting an array of integers you will get a
    pointer to address 3, rather than a pointer to an array with a
    single value of 3
      o this will make the Python and C APIs look a lot closer, and
        eliminate a common class of issues where someone can't see how
        to pass offsets to modern array functions
  * drop support for Python 2.5 and below
      o to make it easier to do Python 3.x support, e.g. by using except
        Exception as var: syntax throughout

I don't expect either of those is *too* controversial, but I wanted to 
let people know and have a chance to raise issues before I go about 
implementing them (again, post 3.0.2 release).

Have fun,
Mike

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

[PyOpenGL-Users] Test your unicode-using code (Py3K Peeps)

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

I've just landed a minimal patch in bzr head to support Unicode as an 
(incoming) array data-type on PyOpenGL.  The data-type converts to 
8-bit, then treats the result as a regular string.  Note that this means 
that the unicode string is *always* copied, and will raise errors with 
ERROR_ON_COPY set.

Note that this will not *produce* Unicode, it produces the 8-bit strings 
that are the api definitions for OpenGL, but it *should* allow you to 
pass in unicode strings for e.g. shader text, uniform names, etc.  I've 
only done the most minimal testing imaginable, as I don't have any 
unicode-using code, but if you're using Py3K you likely have lots of it 
and can tell me how magnificently it blows up :) .

Enjoy,
Mike

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

Re: [PyOpenGL-Users] Mouse Wheel

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

On Tue, Jun 19, 2012 at 1:50 PM, Dick Holmes <en...@co...> wrote:

>  Ian,
>
> I renamed the glut32.dll as suggested in your referenced web page and
> copied freeglut.dll to the dlls directory. My program runs without any
> error messages, but the mouse wheel function isn't invoked. The relevant
> code is:
>
> def wheel(button, direction, x, y):
>     print button, direction, x, y
> ...
> glutMouseWheelFunc(wheel)
>
I don't know then.  As an aside, perhaps try using PyGame (Python port of
SDL) instead?  GLUT is not as flexible, and in my experience, it is buggy.

Re: [PyOpenGL-Users] Mouse Wheel

[Dick H. <en...@co...>]

Ian,

I renamed the glut32.dll as suggested in your referenced web page and 
copied freeglut.dll to the dlls directory. My program runs without any 
error messages, but the mouse wheel function isn't invoked. The relevant 
code is:

def wheel(button, direction, x, y):
     print button, direction, x, y
...
glutMouseWheelFunc(wheel)


On 6/19/2012 1:03 PM, Ian Mallett wrote:
> On Mon, Jun 18, 2012 at 11:34 AM, Dick Holmes <en...@co... 
> <mailto:en...@co...>> wrote:
>
>     I am interested in using the mouse wheel in a GLUT environment. A
>     search of the .py files turned up a reference to
>     glutMouseWheelFunc, but when I tried to use it I received and
>     error message indicating that the function did not exist. Is this
>     feature supported? If so, can you tell me how to activate it?
>
>     Thanks for you help!
>
>     Dick Holmes
>
> Without more information, a quick Google search suggests this 
> <http://stackoverflow.com/questions/10359407/how-to-use-freeglut-glutmousewheelfunc-in-pyopengl-program> 
> might be helpful.

Re: [PyOpenGL-Users] Mouse Wheel

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

On Mon, Jun 18, 2012 at 11:34 AM, Dick Holmes <en...@co...> wrote:

>  I am interested in using the mouse wheel in a GLUT environment. A search
> of the .py files turned up a reference to glutMouseWheelFunc, but when I
> tried to use it I received and error message indicating that the function
> did not exist. Is this feature supported? If so, can you tell me how to
> activate it?
>
> Thanks for you help!
>
> Dick Holmes
>
Without more information, a quick Google search suggests
this<http://stackoverflow.com/questions/10359407/how-to-use-freeglut-glutmousewheelfunc-in-pyopengl-program>might
be helpful.

[PyOpenGL-Users] Mouse Wheel

[Dick H. <en...@co...>]

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <font size="+1"><font face="Verdana">I am interested in using the
        mouse wheel in a GLUT environment. A search of the .py files
        turned up a reference to glutMouseWheelFunc, but when I tried to
        use it I received and error message indicating that the function
        did not exist. Is this feature supported? If so, can you tell me
        how to activate it?<br>
        <br>
        Thanks for you help!<br>
        <br>
        Dick Holmes<br>
        <br>
      </font></font>
  </body>
</html>

[PyOpenGL-Users] [ pyopengl-Feature Requests-3532558 ] Use FreeGLUT on Windows

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

Feature Requests item #3532558, was opened at 2012-06-06 13:24
Message generated for change (Tracker Item Submitted) made by glynnc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355988&aid=3532558&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: GLUT
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Glynn Clements (glynnc)
Assigned to: Nobody/Anonymous (nobody)
Summary: Use FreeGLUT on Windows

Initial Comment:
Currently (as of 3.0.1), platform/win32.py looks for glut32.dll, freeglut32.dll and freeglut.dll in that order, thus preferring GLUT over FreeGLUT. Also, the Windows binary package includes an "original" GLUT DLL.
As FreeGLUT offers more features, and pre-compiled FreeGLUT DLLs are available for Windows (32-bit and 64-bit), I'd like to suggest that freeglut come before the original in the search order, and that the binary package should include the FreeGLUT DLL.


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

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