Source Code Available

I made the effort to figure out exactly how to get launchpad code hosting to work, and put the code up for the world to see.  As you can see it is still very messy, but serves as a simple example of an opengl program using vertex buffers.

It uses a map I downloaded for free from the internet, I do not have copyright to this map, but since it is available from many places I believe the author has placed it in the public domain.  If anyone is skilled at creating quake3 maps and wishes to donate one to this cause please let me know and I will use it in favour of the one I have at the moment.

To run the viewer run the command:

python map3.py

Once the viewer is running the left and right arrow keys can be used to rotate the view, and the w, a, s, and d keys can be used to move the camera in typical FPS style.  The script only redraws the screen on a keypress and prints the time it takes to redraw the screen to the console.  (approximately 0.05 seconds on my slow macbook).

Any comments are appreciated, but please understand that it is still in a very rough stage.

Have fun,

Naltai

Sick

Sorry to everybody, but I have been horribly sick for the last week or so, so there have been no updates.  I'm starting to feel better, so I might get around to writing the texturing code next week.

Cheers,

Naltai.

Speed Demon

Well, using the C like functions makes another huge difference to the performance, It is now hitting about 20 FPS without any kind of visibility culling algorithms.  Also, I don't know how optimized the string indexing functions I am using are, they might be causing additional performance overhead.

I think the next thing to do will be texturing and light mapping, to give more impressive screenshots :)

Cheers,

Naltai 

No More Troubles

Well, that was fast.  It seems merely writing about the problem allowed me to step back from it, and realize that vertex arrays have to be explicitly enabled using glClientStateEnable before using them.

So the demo now has the same functionality as the original, only it now runs at about 9 FPS rather than 3 FPS.  Next I will try going back to c-like calls since I now know I need to enable the arrays.

Till next time,

Naltai

glVertexPointer Troubles

I decided to optimize the drawing first by using glVertexPointer and glDrawElements, however this has turned out to be more trouble than I expected.  It seems that no matter the way I play with the functions I cannot get them to work correctly.

I started off by using the C-like versions of the functions, but have since moved on to trying to get the pythonic versions to work.  Neither will draw anything to the screen.

I'll keep chipping away at it, but it is really annoying, and there are no good references on how this is meant to work in python.

On the plus side, it appears to have improved render times by at least 500%, of course - nothing is showing on the screen, so that could be misleading.

Cheers,

Naltai

It Works!

So a couple of hours of hacking today have gotten me over the initial OpenGL pains, and given me a basic render of the map. It aint pretty, it aint fast, but it works.

Put simply I took the vertex list from my previous post, and ran it through a GL_TRIANGLES call. Put in a simple lighting model, and some appropriate camera movement code and voila, a working map viewer. Of course it has it's problems, using such a simple scheme the viewer crawls (maybe 1 fps?), but it has been great for increasing my confidence that I am getting this stuff down pat.

anyway here is the core of the code and a screenshot to prove it works, I am not sure whether to work on the speed next, or get texturing and lighting working better to give better static screenshots :)

I am not sure why I can't pass the arrays as is to glColor and glNormal, maybe it is a bug in pyopengl, it needs further investigation.

Cheers,
Naltai

  glBegin(GL_TRIANGLES)
  for v in self.vertices:
      glColor(*v.color)
      glNormal(*v.normal)
      glVertex(v.position)
  glEnd()

Open Dynamics Engine

Following some advice from the gamedev forums I have started looking at some physics engines to simulate the racing physics. The first one I have chosen to investigate is ODE, simply because it has python bindings which makes it much easier to play with.

According to the advice I should be able to get a cartoonish feel to the racing by messing with the simulation parameters of the car.

Once I get some working code I'll post it, but I am just exploring the documentation for now.

Extracting Vertices

The parser turns out to be even easier to use than I expected.  The attached python script will give all the vertices in order to be passed to OpenGL for rendering model zero (the static portion of the map).  This is of course a very dumb way to render the map, not taking any advantage of BSPs and visibility information, but it should do for a test render.  I hope to get a test render working in the next couple of days, but it may take a while given my general lack of OpenGL experience.

def get_vertices_from_model(ibsp, model):
    vertices = []
    face = ibsp.models[model].face
    nfaces = ibsp.models[model].nfaces
    for f in range(face, face+nfaces):
        type = ibsp.faces[f].type
        if type not in [1,3]:
            continue
        vertex = ibsp.faces[f].vertex
        meshvert = ibsp.faces[f].meshvert
        nmeshverts = ibsp.faces[f].nmeshverts
        for m in range(meshvert, meshvert+nmeshverts):
            vertices.append(ibsp.vertices[vertex + ibsp.meshverts[m]])
    return vertices

Physics of Racing

I don't know if I mentioned it before, but the eventual game I want to create is a cartoonish type racing game in the tradition of Mario Kart. (I played that game to death).

Anyway some searching turned up this excellent treatise on the physics of racing.  I am a bit concerned that it is too in depth and may not lead to a particularly fun game.  Nevertheless it is engrossing reading, I would suggest anyone interested in cars or racing to check it out.

Till next time,

Naltai

Why Quake3 BSP?

So I was thinking today, why quake3 BSP as a starting point?

1. Id software has a good technical reputation, their format should be a good example

2. quake3 was hardware accelerated only, so the format won't be bogged down with software rendering cruft

3. There are lots of quake3 maps freely available

Anyway, I added a bit of documentation to the parser, I will look at putting the code up somewhere soon.

The next stage will be to read out the basic vectors in the order required to render a view of the entire map.  

Stay tuned.

Python Quake3 BSP Parser

So I spent a few hours working up a parser for quake3 bsp files in python. I intend to start writing a couple of simple opengl display modules using various methods to show the BSP files.  Maybe I will post this to google code or something when I am done.

The main thing I like about my parser is that it is very simple, only 200 lines or so including some basic test code.  Currently it handles all of the format except for the game specific information, such as spawn points, doors, etc.  I think I will need to modify it more when I get around to rendering through vertex buffers though, as it currently pulls all data out into classes before returning it, which is great for usability, but poor for performance.  

At the moment it is more meant as a self education tool while I continue to play with 3d graphics.  stay tuned for my findings :)

Quake3 BSP

I am thinking of writing a simple 3d game.  Something fun and easy to play for 5 minutes and put down.

As an exploration of 3d programming, something I have had only limited experience with before, I have been looking at the Quake3 BSP format.  It's interesting how the format has been optimized for quick processing.

A simple example of this is all of the data organized in vertex buffers with double indirection for simple processing by 3d hardware.  Also more subtle things like the simplicity of the BSP algorithm and pre-computed visibility data, an algorithm that would probably entirely fit in the L1 i-cache of the processor.

Anyway for anyone looking some good  references on this, google says the best are this format description and this usage description.