GL O.B.S. GUI is now based on GtkBuider

Let’s read together some lines from the revision log:

• GUI migrated from libglade to GtkBuilder
  This was, with no doubt, the most time consuming task: gtk-builder-convert tool was not so reliable and I was compelled to recreate the GUI from scratch with Glade. I have also set the minimum GTK version required to 2.16
• using JSON format for storing benchmark information dictionaries
  This feature is a way to get rid of the deprecated execfile() built-in function, instead of executing a python script to read a dictionary, the Benchmark class now parses a JSON file with the new integrated json module.
  Comparing an old and a new file you can notice how simple it was the conversion, I’ve only lost the ability to comment a line.
• importing numpy instead of numerix in matplotlib
  This is another deprecation related issue, matplotlib is now based upon numpy.
• matplotlib canvas get refreshed instead of being destroyed and then recreated
  I don’t know why two years ago I was destroying and recreating the object instead of just calling the draw() method every time it had to be refreshed.
• some more attributes and objects integrated in the GtkBuilder XML file
  I’ve integrated more attributes in the XML GUI file, like default size for secondary windows or Paned positions.
  Moreover, thanks to GtkBuilder, even some objects have been integrated, like Adjustment or TextBuffer.
  Actually also TreeModel objects should be configurable inside Glade and integrated inside the XML, but I didn’t manage to make them work.

Other remarkable changes in the field of Python3 future support and deprecated features removal were:

• all the print statements converted to functions
  Well, we all know the content of PEP 3105…
• using hashlib.md5 instead of md5
  The md5 module has been deprecated in favour of the hashlib one
• using “key in dict” instead of dict.has_key()
  The has_key() method no longer exists in Python 3
• using subprocess.Popen instead of os.popen()
  os.popen() have been deprecated in favour of the subprocess module
• using urllib2.urlopen() instead of urllib.urlopen()
  Another deprecation suggested substitution, from urllib.urlopen() to urllib2.urlopen()
• removed “copyright” argument and added “classifiers” in setup.py
  The distutils.core.setup() function loses the “copyright” argument but gains “classifiers”.
• dropped support for pysqlite2 and old webbrowser module
  Now that the minimum requirement is Python 2.6, there is no need for pysqlite2 or old webbrowser module support
• I have also removed the deprecated Options class in some SCons scripts.

I’m not sure I will have some time in the future to continue developing, but this was a nice “reboot” and I also have some new ideas in my to-do list.

Some days ago a 3d artist of the team, Alessandro, asked me a script that would have helped him using Blender for one more task along the company asset creation pipeline, weight painting.
He needed a simple script to actually convert vertex weights to per-bone vertex colors layers, in order to bake them to per-bone UV maps and later import them inside 3d Studio Max.

Weight painting

Vertex painting

At first I didn’t even know where to start, how to extract and match per-vertex weight data with per-face vertex color one, but my second try with it went as smoothly as honey.
The core algorithm is, indeed, very simple:

for f in faces:
  for i,v in enumerate(f):
      infs = me.getVertexInfluences(v.index)
      for vgroup, w in infs:
        me.activeColorLayer = vgroup
        col = f.col[i]
        col.r = col.g = col.b = int(255*w)

Well, he has not yet taken advantage of it nor I know if he will ever use it, nevertheless the script is working and I have shared it on my site, as usual.

During these days I was relaxing and practicing subdivision modeling, after a long time away from Blender I was back to the dream of creating a convincing human head model, but my programming side win the day.
While I was studying in detail some face key parts topology from here, I noticed the PiP-like composed images attached to the first post…

Showing camera keyframes

Last night I was thinking of a way to automates the process and today it becomes reality in the form of a Blender Python script: it is capable of producing an image which is composed of multiple rendered frames, think of a daily comic strip and you understand the name .

The user can select which frames to render specifying a string similar to the following one: “1-3, 5, 7, 9-11“.
Moreover it is possible, of course, to choose the size of a single frame and the composed image table dimensions, i.e. how many rows and columns it should have.
Have a look to how well my topology study renders fit the script purpose.

The resulting composed image

This second script is a bit more complex than my first one, making use of the Registry module to load and save options and the Draw.PupBlock() method to display a bigger GUI.

Of course it is released under the GNU GPL License and available online, download it from here.

The second thing is closely related to this post instead, a couple of months ago I began to convert, following M3xican’s advice, my OpenGL demos to object oriented C++.
What I have now is really not much, nevertheless my class library can load a Stanford PLY model, it is ES 2.0 compliant (this means it will be easily converted to “Pure” OpenGL 3.x), and it can already display both parallax mapping and depth of field!

I’m not going to publish any screenshot by now because I think it’s not the time yet, what I’m showing you is a easy script, my first one, which I wrote yesterday night using the Blender Python API.
What it does is really simple yet time-saving, you select a high-poly and a low-poly model, run the script from the Object->Scripts menu and watch Blender baking your normal and height map and then saving them.

I have also set up an easy compositing nodes configuration to mix the two images in a single parallax map with height data encoded in the alpha channel.

You can download the script from here.
Everything is very simple (and funny!) with the astonishing power of Blender!

What came after was just that I decided to hack it a bit and make it behave more like a standard build tool, that is to control the modification time of a source file in order to choose whether it is updated or need a fresh compilation.

The new policy for the script is very simple, but useful enough to save plenty of time.
It is aware of the following cases (thank you Arc for tips on how to deal with the last one):

• a .c file is missing, pyrex should compile the .pyx file
• a .pyx file is newer than the corresponding .c file, an update is needed
• a .pxd file is newer than any .pyx file, a global recompile is needed

The last point is not optimal, of course, but it’s a lot simpler than specifying all the .pxd dependecies for any .pyx file, and, anyway, quite close to being optimal, because of the thick web of cross dependencies which actually exists in PySoy.

Here is the piece of code which performs the magic:

# Convert Pyrex sources to C if using Trunk
if version == 'Trunk' :
  import os
  from stat import *
  from Pyrex.Compiler import Main

  options = Main.CompilationOptions(defaults=Main.default_options, include_path=include_path)

  newestpxd = 0
  for dir in include_path:
    for pxdsource in os.listdir(dir):
      pxdsource_path = (os.path.join(dir, pxdsource))

      if os.path.isfile(pxdsource_path) and pxdsource.rsplit('.', 1)[1] == 'pxd':
        if os.stat(pxdsource_path)[ST_MTIME] > newestpxd:
          newestpxd = os.stat(pxdsource_path)[ST_MTIME]

  for pyxsource in pyrex_sources:
    compilation_needed = False

    if os.path.isfile(pyxsource.rsplit('.', 1)[0] + '.c'):
      ctime = os.stat(pyxsource.rsplit('.', 1)[0] + '.c')[ST_MTIME]
    else:
      ctime = 0

    if newestpxd > ctime:
      compilation_needed = True
    elif os.stat(pyxsource)[ST_MTIME] > ctime:
      compilation_needed = True

    if compilation_needed:
      Main.compile(pyxsource, options)

Well, actually Arc commited r65 too, simplifying the conditionals of the script even more, but this is another story.
Anyway, I hope to have made another little step into making the life of our team a bit simpler.

But let’s start from the beginning…
After having shown to Arc an early draft of an UML class diagram for the current code I decided to come back to work on some test code I had written in the afternoon.
It was just a classical spinning cube demo to actually compare PyOpenGL versus Pyrex speed, I don’t report the results here because they are quite identical, if I haven’t done any mistake it should be the absolute minimum complexity of the code which actually determined this result.
Anyway, even without this proof I firmly believe in the power and speed of Pyrex.

Going back to my commit, my changes affected a small yet important area of the code, I think we will remember it in the future.

BEFORE
In src/windows-glx/soy.windows.pyx:

gl.glClear(0x4100)

AFTER
In include/gl.pxd:

[...]
# Constants
  ctypedef enum:
    [...]
    # glPush/PopAttrib bits
    GL_DEPTH_BUFFER_BIT
    GL_COLOR_BUFFER_BIT
[...]

In src/windows-glx/soy.windows.pyx:

gl.glClear(gl.GL_COLOR_BUFFER_BIT | gl.GL_DEPTH_BUFFER_BIT)

Was it better before or now?

I don’t know if it can be called “support”, but at least GL O.B.S. is now aware of it.
The changes are very simple yet of some importance.
First of all, pysqlite is not needed anymore if you have the integrated sqlite3 module:

if sys.version_info[:2] >= (2, 5):
  from sqlite3 import dbapi2 as sqlite
else:
  from pysqlite2 import dbapi2 as sqlite

Moreover I make use of the updated API of the webbrowser module:

if sys.version_info[:2] >= (2, 5):
  webbrowser.open_new_tab(Globs.BROWSE_URL)
else:
  webbrowser.Netscape('firefox').open(Globs.BROWSE_URL)

Another addition, not related with the support of Python 2.5, is the check_ver function, which checks if a particular version of OpenGL is available on the machine running GL O.B.S., this have opened the possibility to add an OpenGL 2 only test like GLSL_Parallax into benchmarks r47.

Python and GL O.B.S. are getting better and better.

My first proposal was about working on GL O.B.S. under the Python Software Foundation, unfortunately it was very likely going to be discarded.
I learned this from a mentor who contacted me, he wrote that my application was based on a personal program and that it would have been hard to find someone to mentor me, moreover I wouldn’t have contributed to the Python community. He also added that I could have been a good candidate for his project, he is, indeed, Arc Riley, Project Manager of PySoy.
And so I did, I wrote another application and, this time, it has been accepted.

My work will be to integrate multi-texturing in the PySoy rendering loop and API, document API additions, test the whole under many different free software drivers and then implement some related techniques, like bump or normal mapping.

I’m really glad of this opportunity, I will learn many interesting OpenGL and Python topics and I will improve my design, teamwork and communication skills.
Thank you Google!