Using ARRAY_BUFFER’s in PyOpenGL

Posted in How To, Programming, PyGLy with tags , , , , on 2013/02/16 by Adam Griffiths

I’m in the process of converting my code from Pyglet GL to PyOpenGL.
In doing so, my VBO objects stopped rendering.

It turns out the problem is glVertexAttribPointer.
The Pyglet GL version takes the last parameter (offset) as a number. I set this to 0 for arrays with no offset.

glVertexAttribPointer( in_position, 3, GL_FLOAT, GL_FALSE, 0, 0)

It seems that PyOpenGL expects the pointer value by absolute instead of relative.
The solution is to pass None instead of 0.

glVertexAttribPointer( in_position, 3, GL_FLOAT, GL_FALSE, 0, None)

If you have an actual offset to pass, you need to convert to a ctypes c_void_p (void*).

http://stackoverflow.com/questions/11132716/how-to-specify-buffer-offset-with-pyopengl

glVertexAttribPointer( in_position, 3, GL_FLOAT, GL_FALSE, 0, ctypes.c_void_p(offset))

Rotating a vector by a quaternion in GLSL

Posted in How To, Programming with tags , , , , on 2013/02/11 by Adam Griffiths

I’ve found numerous code samples which produce erroneous results in my shaders.

The functions I’ve found to work are the following:


vec4 multQuat(vec4 q1, vec4 q2)
{
return vec4(
q1.w * q2.x + q1.x * q2.w + q1.z * q2.y - q1.y * q2.z,
q1.w * q2.y + q1.y * q2.w + q1.x * q2.z - q1.z * q2.x,
q1.w * q2.z + q1.z * q2.w + q1.y * q2.x - q1.x * q2.y,
q1.w * q2.w - q1.x * q2.x - q1.y * q2.y - q1.z * q2.z
);
}

vec3 rotate_vector( vec4 quat, vec3 vec )
{
vec4 qv = multQuat( quat, vec4(vec, 0.0) );
return multQuat( qv, vec4(-quat.x, -quat.y, -quat.z, quat.w) ).xyz;
}

Source from here: http://www.opengl.org/discussion_boards/showthread.php/166386-Quaternions-and-hardware-skinning

And this version which is optimised:


vec3 rotate_vector( vec4 quat, vec3 vec )
{
return vec + 2.0 * cross( cross( vec, quat.xyz ) + quat.w * vec, quat.xyz );
}

Using gl_VertexID without any VBOs.

Posted in How To, Programming with tags , , , on 2013/02/03 by Adam Griffiths

Normally, gl_VertexID is the index of the currently rendered vertex element.

When you provide indices (GL_ELEMENT_ARRAY_BUFFER), gl_VertexID should match the value provided. Ie, the gl_VertexID value can repeat if you render the same element multiple times.

 

I say “should”, because this is NOT correct when you haven’t provided any VBO data.

This means, that if you are rendering using nothing but a shader and a GL_ELEMENT_ARRAY_BUFFER, the gl_VertexID will NOT match the indices you provide, and will instead be a sequence from 0 -> N.

The solution is to use a single VBO and use glDrawArrays.

 

Personally, I consider this a bug.

Adobe Air hanging when using SDK but not when packaged

Posted in How To with tags , , , , , on 2013/01/30 by Adam Griffiths

I just had an issue during the development of an Adobe AIR Application.
When using Flash Pro CS 6, the application hang in certain situations for 5 odd seconds.

I found a few peculiar quirks:

  • Packaged builds didn’t have the problem.
  • Moving the project to a different directory fixed the problem.
  • Clean checkouts of the source didn’t have the problem
  • Re-creating the project in Flash Pro CS 6 didn’t fix the problem.

The console was printing the following messages

Breakpoint not set; No executable code at line ###

It turns out the problem was old breakpoints that don’t exist anymore.
There’s not trivial way to remove all the breakpoints (the button was greyed out!).
The easiest way I found (on OS-X) was to do the following:

vi ~/Library/Application\ Support/Adobe/Flash\ CS6/en_US/Configuration/Debugger/AsBreakpoints.xml

Remove all the breakpoint entries in the XML.
The file should look similar to this:

<?xml version="1.0"?>
<flash_breakpoints version="1.0">
</flash_breakpoints>

This resolved the issue.

Compiling Python on Ubuntu / Linux

Posted in Twisted Pair with tags , , , , on 2012/09/25 by Adam Griffiths

I’ve been having problems installing Python on my Ubuntu machine because of errors with setup tools.

During installation you get the following error:

Installing distribute into /home/ting/.pythonbrew/pythons/Python-2.7.3
ERROR: Failed to install setuptools. See /home/ting/.pythonbrew/build.log to see why.
Skip installation of setuptools.

And if you try and use pip / easy_install, you get this:

ImportError: No module named setuptools

It turns out the answer is simple, we’re missing some libraries required to compile it.

sudo apt-get build-dep python2.7

BAM! Pythonbrew works!

PyGLy steps into the future

Posted in Development, PyGLy, Twisted Pair with tags , , , , , on 2012/09/21 by Adam Griffiths

I’ve been working quite heavily on PyGLy for the last few weeks and I’m incredibly pleased to announce that PyGLy is now OpenGL 3 clean!

It took more work than I hoped. Not because of PyGLy (it was already pretty good), but Pyglet’s OpenGL Core (3+) support on OS-X, is well… broken.
I had to integrate a patch written by someone else and patch out 2 of the window event handlers.
The main reason for this is that OpenGL Core on OS-X is limited to 3.2, and is Core only (no legacy compatibility).
These changes can be found in my Github repository.

Pyglet isn’t without it’s problems. It is quite heavy weight in places. There is no support for float or 1D textures.
Other problems are it’s usage of legacy calls. These are scattered throughout the code base and prevent me from using even the Label or VertexList classes.
I would LOVE to help with the development of Pyglet… but I find the code… very confusing.
It’s got a fair amount of abstraction. Tracing even a vertex buffer blows my mind.

Regardless, I hope these issues will be fixed soon.

OpenGL and GLSL support in OS-X

Posted in Twisted Pair with tags , , , , on 2012/08/13 by Adam Griffiths

I had difficulty finding the supported OpenGL and GLSL versions in OS-X.
Using Pyglet, I get errors trying to use versions GLSL 1.30 and above. Printing out the version returns 1.20.

from ctypes import *
from pyglet.gl import *

print "OpenGL version", gl_info.get_version()

plain = string_at(glGetString(GL_SHADING_LANGUAGE_VERSION)).split(' ')[0]
major, minor = map(int, plain.split('.'))
version = major*100 + minor
print "GLSL Version",version

Looking around I found this information.
Mac OS-X OpenGL Support

Legacy would infer the “Fixed Function Pipeline” and Core would be modern OpenGL.
So it seems that legacy OpenGL (normal Pyglet) is stuck with GLSL 1.20 and Core has 1.50.

This code can be found on the Pyglet source repository that enables OpenGL 3 (Core).
Enable OpenGL 3 in Pyglet

But the ouput I get is not correct.

OpenGL version 2.1 ATI-1.0.25
GLSL Version 120

According to this conversation, it appears that Pyglet ignores the OpenGL version on OS-X currently.

Follow

Get every new post delivered to your Inbox.

Join 119 other followers

%d bloggers like this: