Chances are, you’ve never heard of Gamekit.

Despite a simple website, and a whole bunch of confused users who want to try gamekit but don’t know how, gamekit is pretty darn functional already. Within half an hour, you can make a simple 3D game that compiles and runs on an iPhone. It also supports shaders, physics, animation and lua scripting. If you a looking to replace the Blender game engine with something lighter, faster and more modern, take a look at this game engine.

Sure the documentation is a little sparse, but as more artists start using this engine, hopefully we’ll see more literature on the topic.

Above is a rendering of my ubiquitous BMW.  The total rendering time to get to this quality is less than 40 seconds. (Compare to over 3 minutes using the old Blender renderer) Even more impressive, is that the rendering takes place in the 3d viewport directly, in a progressive fashion.  So one can edit the scene while the rendering refines itself.

No more F12, rendering just went realtime Yo.

Paul Debevec published his seminal work on image based modelling in 1997, just over 14 years ago. By taking multiple images of an object from different angles, he was able to reconstruct the 3D geometry of the bell tower at  UC Berkeley.  Programmatically generating 3D models from 2D images!  It was so revolutionary at the time that the sfx team behind the Matrix movie worked with Paul to use this exact technique in the film.

Pretty impressive eh?  Now imagine going this for an entire campus, or an entire city, or the entire world.  Without human intervention. At 10cm resolution.

This is what C3 Technology and Nokia came up with, and it runs inside a web browser.

A better writer might be able to describe to you the magnitude of what you are witnessing, but I am truly at a loss at conveying the significance of this to the future of mapping.  Click on the image to see the demo for yourself.  You’ll need to install a plugin, but it’s well worth the trouble.  Someone less technically might not fully appreciate the complexity of what’s going on behind the scene, and as someone who only knows enough to be dangerous, I am still not convinced technology like this even exists today.

Wow.

You might notice that some of the shader code looks strange, that’s because I am trying to keep things simple by forcing myself to use the latest version of OpenGL Shading Language available on my computer hardware, so for a Geforce 8, that’s OpenGL 3.3 | GLSL 3.3.

#version 120
#vertex shader

in vec4 vertex;
uniform float timer;

void main() {
vec4 v = vertex;
v.z = sin(timer+v.y+v.x)*0.5+v.z;
v.x = sin(timer*10.0+v.y+v.y)*0.2+v.x;
gl_Position = gl_ModelViewProjectionMatrix * v;
}

#==========================

#version 330
#geometry shader

layout(triangles) in;
layout(triangle_strip) out;
out vec2 texCoord;

#define radius 0.01
#define layer 1

void main() {
//for(int i = 0; i < gl_in.length(); i++) { // avoid duplicate draw

The first section, the vertex shader, is executed for each vertex of the geometry, it is here that I apply the deformation to form the base shape of the particle systems.  The resulting coordinates is projected from modelspace onto viewspace.  This is important, because it saves the next step from becoming overly complex!  The geometry that follows is able to do per-primitive operations on the vertex, here I take each vertex from the previous stage(which is already projected into viewspace), and ‘expand’ that into a billboard by creating a quad for each point.  The quad naturally faces the camera, since everything is already in viewspace.  The final stage of the pipeline is the fragment shader, which applies a texture onto the quad.

One blatant oversight of this approach is that it does not take into account the viewport aspect ratio, thus the generated particles will only look square on a 1:1 canvas.  None unity aspect-ratio will stretch the billboard.

As you can see, the code is very short, but being GLSL, the program is executed on the graphic hardware, which is highly tuned for this type of computation.  Freeing the CPU to do other things.

This is a test with 1million fully textured particles running in Blender’s using geometry shaders and vertex shaders to do most of the heavy-lifting.

With this patch, the Game Engine can use the native  Blender ‘text’ object type in the game, this means you can reuse the same text object inside the Game Engine, without having to fiddle with custom bitmap textures.  Further more, the text engine is now thoroughly Unicode aware, with the right font, you can make Blender talk in any language you want(as shown above).

Oh and in case you are wondering how get that Sony CrossMedia Bar effect in Blender, click here.

My aim is to prepare at least 12 files before Christmas.  If this is not enough, you can always, oh I don’t know, get a book on the topic or something. :)

Merry Early Christmas!

Realtime visualization

Import > Simulate > Export

Going nuts with F-Curves

Update: This project is featured on the Italian Computer Grafica magazine!

Isn’t Relief Mapping great?

Apart from all games that will inevitably take advantage of this technique, another application I can think of that will reap huge benefit from this is the loading and displaying of large-scale terrain visualization at virtually no CPU overhead.  A 4096×4096 DEM texture can be easily displayed at 60fps.  Whereas if the same data were to be converted to real geometry, most computers will die trying to render those 33million triangles.

The effect is achieved by a rather complex fragment shader (pixel shader) that effectively does ray-casting on each pixel to determine the location and visibility of each pixel.  The shader requires at least 2 textures.  A diffuse color texture; and a normal-height texture that contains the surface normal stored in the RGB channel and the height value stored in the Alpha channel.  Supplied with a miminum of these two textures, the shader is able to reconstruct the 3D surface like you saw.  (I also used a specular texture to control the specularity of the lakes, but this is optional)

Download the demo (4MB)

I never finished it. But ever since I posted the above video, I have been getting a lot of inquiries as to how I did the vehicle physics system in Blender. So here is a quick guide followed by the sample file.

The key to stable driving dynamics is to use the built-in PhysicsConstraints module within Blender’s game engine. PhysicsConstraints is a python wrapper for the Bullet physics engine. No any homemade setup I’ve seen is as good as what’s already provided by Bullet Physics. So we’ll use that.  Because there isn’t a graphical interface for setting up the vehicle physics yet in Blender, we need to write a few lines of Python script.  The key component is the car body object, which is linked to the 4 wheels through a logic brick connection so that the script would recognize the linked objects as wheels. (As you can see, all the actual driving logic is all happening on the car body, the wheels have no real logic brick attached).

The entire setup is a bit complex, since there is a mix of logic brick and python. Take a look at the sample file if you are lost.  When one runs the game, the following happens:

0. World is initialized, but we don’t really care about that here.

1. The car body is initalized, scripts.carInit() is ran. In this script, it initializes the car as a “vehicle constraint”, aka constraint type11, and stores it as a Python object called vehicle.  The same script then looks for the 4 wheel by access a gamelogic actuator with specific names (in this case, wheel1, wheel3, etc), then the script attaches the wheels to the car body using the settings specified in the script. Variables such as RollInfluence, SuspensionStiffness, and TyreFriction can all be set on a per-tire basis once the vehicle object is created. The job of carInit() is now done.  Our car body is now considered to be a vehicle by the Blender game engine, and it will behave like one.

2. Every frame, scripts.carHandler() is ran. This script does the actual moving of the car, it applies engine force and steering to the vehicle object. But this script gets the user input (keyboard sensor inputs) from another source. (See #3 below)   Vehicle objects have methods such as applyBreaking(), applyEngineForce(), getWheelRotation(), getNumWheels, which you can all call.

3. Every time a key is pressed, script.keyHandler() is ran. It figures out which key is pressed and set the intermediate variable so that #2 (i.e. scripts.carHandler) would know how much throttle to apply, where to steer, etc.  This script is separated from scripts.carHandler() not because of technical limitations, but by design so that it’s easier to manage the code.

That’s all there is to it.  If the script layout is a bit confusing, it’s because it is.  I originally intended it to be a bigger project, thus everything is separated into nice neat functions.  Again, you can DOWNLOAD the whole setup for Blender 2.5 from here.

Controls:
Arrow Keys to move the car
Space bar for handbrake
R to reset car if it flips over
number row 1,2,3,4,5 to change camera

Hope that helped.