Re: Pyglet example that uses GLSL and programmable pipeline

505 views
Skip to first unread message

Adam Griffiths

unread,
Sep 25, 2012, 11:33:39 PM9/25/12
to pyglet...@googlegroups.com

I've been working on getting the Core profile working under Pyglet.

My framework, PyGLy (very simple, flexible, stays out of your way) includes a number of examples.


The simplest one is here:

https://github.com/adamlwgriffiths/PyGLy/blob/master/examples/core/simple/main.py


Uses the scene graph to render a series of cubes.


This uses the core profile.

I also _had_ some example code that was using shaders in the legacy profile (fixed function pipeline + shaders), but have not committed this.


Using shaders in legacy is essentially the same as normal rendering.

The only thing I had to look out for was assigning attributes to vertices.

You need to link the shader, then query for the attribute index, then use that as the "XgX" format specifier for the vertex_list (assuming you're using piglet's vertex list object).

I talked about this here:

https://groups.google.com/forum/?fromgroups=#!topic/pyglet-users/Eonyq0tKR6s


Hope that helps =)


Cheers,

Adam


On Tuesday, September 25, 2012 9:19:39 PM UTC+10, mv wrote:
Hello,

I am looking for a Pyglet example that uses GLSL and the programmable pipeline.

I looked at the Pyglet documentation, but am unable to figure out how to define my own vertex list, and then link that with say, a "attribute vec4 pos" variable in the vertex shader.

The examples I have seen use vertex lists, but still use the now deprecated fixed function pipeline.

I'd appreciate any help with this.

Regards


Adam Griffiths

unread,
Sep 25, 2012, 11:40:02 PM9/25/12
to pyglet...@googlegroups.com
I just read your post a bit more thoroughly, sorry, in a rush today.

Pyglet's code uses legacy calls. If you're using Core profile only with no compatibility, you'll need to do your own vertex arrays.
I'm running on OS-X and I'm unable to mix legacy and core.

I've got an example that uses Core VBO and VAO calls.
It includes everything needed to render the cube, apart from the matrices themselves which are in simple.py I posted earlier.

This file also uses vertex attributes to specify colour:

I'm currently looking into either writing my own classes to use in PyGLy, or updating pyglet to enable core profile usage in these key classes (texture, label, vertex_list).

Take a gander around my PyGLy repository.

I've also got a GLSL shader I'm working on atm (it works, just want to clean up the API) that does hardware animation / interpolation of MD2 mesh formats (yes, old, but simple).

This should give you enough info.

The code is long, but its clear and I don't remove any boiler plate.
So the code you want to look at is:
pygly/shader.py
examples/application.py
examples/core/application.py
examples/core/simple/main.py
examples/core/cube.py
examples/core/colour_cube.py


Cheers,
Adam

Adam Griffiths

unread,
Sep 25, 2012, 11:42:45 PM9/25/12
to pyglet...@googlegroups.com
To sum up (sorry, 3 emails).

If you want core profile, the only thing you can use pyglet for is events and the window itself.
You need to provide the rest.

However, like I said before. I'm either going to provide my own classes in pygly, or work on pyglet to add this functionality.

Adam

mv

unread,
Sep 29, 2012, 11:21:32 PM9/29/12
to pyglet...@googlegroups.com
Thanks, Adam.

I'll check out the links your provided.

Prior to seeing this post, I was able to make my code (that uses my own vertex/fragment shaders and vertex attributes) work with something like this:


        # position
        self.posLoc = glGetAttribLocation(self.shader.handle, "pos")
        pos_attrib_type = "%ig3f" % (self.posLoc)
        # texcoord
        self.texLoc = glGetAttribLocation(self.shader.handle, "tex")
        tex_attrib_type = "%ig2f" % (self.texLoc)
        # create vertex list
        self.vertex_list = pyglet.graphics.vertex_list(
            4,
            (pos_attrib_type, (-0.5, -0.5, -1,
                                -0.5, 0.5, -1,
                                0.5, -0.5, -1,
                                0.5, 0.5, -1)),
            (tex_attrib_type, (0, 0,
                               0, 1,
                               1, 0,
                               1, 1))
            )

Adam Griffiths

unread,
Sep 30, 2012, 11:46:37 AM9/30/12
to pyglet...@googlegroups.com
Ah thanks for that information.
I hadn't tried the vertex_list class without the 'v' type and just assumed it would always call some legacy code.

Cheers,
Adam

mv

unread,
Sep 30, 2012, 10:42:56 PM9/30/12
to pyglet...@googlegroups.com


On Sunday, September 30, 2012 9:16:37 PM UTC+5:30, Adam Griffiths wrote:
Ah thanks for that information.
I hadn't tried the vertex_list class without the 'v' type and just assumed it would always call some legacy code.

Cheers,
Adam

Hi Adam,

Unfortunately, you can't update the generic attributes in Pyglet vertex lists :

http://www.pyglet.org/doc/programming_guide/vertex_lists.html

I am relatively new to Python, but not to OpenGL. I wish there was an OpenGL Python binding where I didn't have to deal with all these layers of code. I just need OpenGL access - don't need anything else. Do you know if PyOpenGL is still being maintained? I was unable to make it work on my Macbook.

Thanks

Mahesh


 

Richard Jones

unread,
Sep 30, 2012, 11:11:10 PM9/30/12
to pyglet...@googlegroups.com
On 1 October 2012 12:42, mv <mkve...@gmail.com> wrote:
> I am relatively new to Python, but not to OpenGL. I wish there was an OpenGL
> Python binding where I didn't have to deal with all these layers of code.

PyOpenGL has a much nicer interface. pyglet's never had a goal of
duplicating that.


> I just need OpenGL access - don't need anything else. Do you know if PyOpenGL
> is still being maintained? I was unable to make it work on my Macbook.

The last beta for PyOpenGL was uploaded to PyPI just over a month ago.


Richard

mv

unread,
Sep 30, 2012, 11:55:35 PM9/30/12
to pyglet...@googlegroups.com

> I just need OpenGL access - don't need anything else. Do you know if PyOpenGL
> is still being maintained? I was unable to make it work on my Macbook.

The last beta for PyOpenGL was uploaded to PyPI just over a month ago.



Thanks - I'll check it out.

Mahesh
 

Adam Griffiths

unread,
Oct 18, 2012, 12:01:23 PM10/18/12
to pyglet...@googlegroups.com
You still have full access to all the normal OpenGL calls.
I'm not using pyglet for anything but events and windowing at the moment.

Just do an:
from pyglet.gl import *

and BAM, all the normal gl* funcs are available.

Check this file for an example of rendering a cube.

Only requires 2x 4x4 matrices (numpy arrays) to render.

This is used by this example:


That being said, I've been reading that PyOpenGL has a number of optimisations, such as Cython support built in.
Migration is trivial though because you can just import pyopengl's gl commands and it should work from within Pyglet.
I haven't tried this myself, but it's what I've read.

Cheers,
Adam

Richard Jones

unread,
Oct 18, 2012, 7:08:12 PM10/18/12
to pyglet...@googlegroups.com
On 19 October 2012 03:01, Adam Griffiths <adam.lw....@gmail.com> wrote:
> That being said, I've been reading that PyOpenGL has a number of
> optimisations, such as Cython support built in.

PyOpenGL does have an optional accelerator, but the main reason for
using it is the significantly nicer API. There's no need to sully your
application code with ctypes incantations! :-)

Having said that; if you're sticking to relatively simple OpenGL calls
then the small ctypes overhead is probably a reasonable tradeoff to
not needing the additional dependency.


Richard

Tristam MacDonald

unread,
Oct 18, 2012, 7:22:14 PM10/18/12
to pyglet...@googlegroups.com
On Thu, Oct 18, 2012 at 7:08 PM, Richard Jones <r1char...@gmail.com> wrote:
On 19 October 2012 03:01, Adam Griffiths <adam.lw....@gmail.com> wrote:
> That being said, I've been reading that PyOpenGL has a number of
> optimisations, such as Cython support built in.

PyOpenGL does have an optional accelerator, but the main reason for
using it is the significantly nicer API. There's no need to sully your
application code with ctypes incantations! :-)
 
Unless you are using PyPy (like me!), in which case PyOpenGL also uses ctypes exclusively...

--
Tristam MacDonald
Software Development Engineer, Amazon.com

Richard Jones

unread,
Oct 18, 2012, 7:25:32 PM10/18/12
to pyglet...@googlegroups.com
On 19 October 2012 10:22, Tristam MacDonald <swift...@gmail.com> wrote:
> On Thu, Oct 18, 2012 at 7:08 PM, Richard Jones <r1char...@gmail.com>
> wrote:
>> PyOpenGL does have an optional accelerator, but the main reason for
>> using it is the significantly nicer API. There's no need to sully your
>> application code with ctypes incantations! :-)
>
> Unless you are using PyPy (like me!), in which case PyOpenGL also uses
> ctypes exclusively...

But my point is that you as an application coder don't need to use
ctypes in *your* code.


Richard

Tristam MacDonald

unread,
Oct 18, 2012, 7:28:41 PM10/18/12
to pyglet...@googlegroups.com
On Thu, Oct 18, 2012 at 7:25 PM, Richard Jones <r1char...@gmail.com> wrote:

> Unless you are using PyPy (like me!), in which case PyOpenGL also uses
> ctypes exclusively...

But my point is that you as an application coder don't need to use
ctypes in *your* code.

As far as I can tell, you do, because PyPy doesn't seem to support any of the other methods to provide PyOpenGL with array data (i.e. NumPy).
Reply all
Reply to author
Forward
0 new messages