Re: Cleanups and deprecations going forward...

"Mike C. Fletcher" <[email protected]>
Newsgroups gmane.comp.python.opengl.user
Message-ID <[email protected]>
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
> <[email protected]> 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


------------------------------------------------------------------------------
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.