CG in the Multi-core Style

I've just read an two interesting articles re: real time ray tracing.

This is exciting stuff.

In the mid 90's, Ken Silverman wrote a bleeding edge 2.5D ray casting engine which was used to create Duke Nukem 3D. This was however, quickly eclipsed by Carmack's Quake engine, which was based on triangle rasterization. Ten years on, not a whole lot has changed. Things just got faster, and hotter, and bigger. Loking forward however, there is some exciting new graphics tech coming our way. With a quad core multi GHz CPU, real time ray tracing might soon become a reality.

This raises everyone's favorite Python whipping boy, the GIL, in another context.

The GIL prevents Python from scaling (using threads) across multiple processors. Hopefully someone will solve this problem soon. I want to use multiple threads on my multi-core chip in Python, but, at the moment, I cannot. Sure, I can fork a process and do something clever with that, but on Win32, this is rarely worth the effort, and generally not very useful for game programming. As more users get multi-core chips, Python won't scale as naturally as other threaded languages.

Will anyone step up and take on this challenge? I hope so.

QGL / EC Fly-by Demo

I've spent the afternoon building a spacecraft fly-by demo for Entity Crisis. I've found that it is actually very hard to create a nice visual. Just because something is 3D doesn't magically make it a great looking scene. A lot of work has to go into getting the lighting right, and the material properties. The majority of effort goes into texturing. A boring model comes alive with the right texture. Fortunately I know a few good texture artists. :-)

I've also realized that a scenegraph needs nodes which can do things like enable and disable depth testing, blending etc. Not everything can be abstracted away into high level classes, the programmer often needs access to lower level functions.

The code and data is available in svn/qgl/trunk/demos/ec_intro.

QGL 7B

I've just uploaded QGL 7B to the cheeseshop. This version fixes some critical issues with texturing Mesh leaf objects. Attached are two screenies of a textured space station with and without lighting.

The new shader functionality won't be available until after pyweek.

That sweet smell of Py

After promising myself for years not to get inloved with various web community fads, i.e. Blogging, MySpace etc. I've resided myself to fact that it is indeed the future of online social commentary and exploration.

What better way to start than introducing the third return of our small band of game developers in the latest PyWeek competition. It's back! For those who aren't familiar with it we urge to check out the competition, view some previous years entries, and perhaps if you're feeling ballsy - enter yourself!

This will be our third effort after some pretty decent success in previous attempts. More news on the competition soon.

Game onward sir!

QGL has shaders

Thanks to some enlightenment from Alex Holkner (GLSLExample on the pygame cookbook), QGL now has shader support that actually works. The attached screen shot shows a Toon Shader in action.

A QGL shader has an update method, which passes named arguments to the shader program. Currently, the only supported data type for update operations is the humble float. Vector and matrix data types are coming soon.

ATI Lighting is Bugged

I develop on a notebook which has an ATI X600 mobility video card. I'm using the latest ATI Linux drivers.

Every now and then, my lighting tests only show the ambient light value (usually (0.2,0.2,0.2,1.0) and ignore the diffuse and specular light parameters. The effect of this is that the entire scene is very dark, with no light effects at all. So, how do I fix this?

By tapping something on the keyboard.

Or clicking in the window.

This usually fixes the problem, until I click or tap again. I can do this a few times before the scene stays lit, or stays dark. I'm blaming the Linux video drivers, as this problem does not happen in windows.

Sigh.

My next notebook will use Nvidia.

Shaders aren't that hard

I've been playing with glewpy, and have been able to create, compile and use some simple OpenGL vertex and fragment shaders.

I'm thinking of adding shader type leaves to QGL. Not everyone has shader capable hardware, so the leaves need to be optional, which means they can't exist in the qgl.scene namespace, they will need to be explicitly imported by the programmer.

If shaders are optional, then the render visitor shouldn't need to know about the OpenGL shader implementation. This presents a problem. How do I enable custom leaf execution in the Render and other visitor classes? In it's current state, it is not obvious, as the Render visitor uses a big if/elif block to dispatch leaf drawing operations.

Hmmm.