Level Formats

Fri, 11 Apr 2008 05:03:11 GMT

One major weakness about Fields of Chaos (besides the network code ) was the level format. I actually created the level format less than a week before the game was due, which was crazy, and wrote the level editor in one night, which was also crazy.

Anyways the level format was a heightmap + objects scattered around the level. This might be OK for games that are mainly outdoors, but for a first person shooter, i don't feel its good enough, as you need some indoor areas to be interesting. However, for that project, it was the easiest thing, as I had already coded up a terrain rendering engine (that was my pet project after finishing PsyOps). And it worked OK for our game, the circle level at least was pretty cool I thought - you kind of got the sense of being in a giant valley with mountains around you.

After Fields of Chaos, I was inspired by a better way to represent levels. I was somewhat familiar with the BSP format (having made a few maps for Half-Life and Half-Life 2), and i used some other level editors (i made levels for Dark Forces 1 & 2 back in the day...) The main thing that attracted me to it was that GTK Radiant was open source, and could make BSPs, and is a solid tool.

Thus, I began my journey to write a BSP renderer for Quake 3 levels. Reading in the data wasn't very hard (although ironically more of a pain than in C++ because I couldn't do a direct read from structs, as far as I know... so I used a BinaryReader and had to read each item individually). Displaying most of the mesh wasn't tooo hard, although the double offsets with the meshverts and everything took a little while to wrap my head around. The bezier patches were more of a pain in the @ss but eventually those got figured out too..

The biggest difficulty I had was in rendering the BSP EFFICIENTLY. The problem is, the BSP "idea" is great for having minimal overdraw... However, graphics hardware today is (somewhat) less sensitive to overdraw, but WAY more sensitive to the number of draw calls you make. I was making a DrawIndexedPrimitive call for every single face - which is extremely slow & bad!

My solution was to combine faces - i would group them together in "facegroups", where faces having the same texture & lightmap would be combined using a depth first traversal of the tree. I set a max limit on the number of faces, but I have never hit it yet, thus it doesn't really matter that I used depth-first as opposed to breadth-first... This yeilded excellent performanec gains. Of course, i kind of lost the benefit of having a BSP in the first place - although the PVS data generated was still extremely valuable in culling entities and non-visible facegroups.

However, my rendering was still a bit slow.. I had experimented with Parallax mapping and Parallax Occlusion mapping previously, but I had turned it off (or so I thought). I had thought that maybe fill rate was the bottle neck (even with PM/POM turned off), but it turns out, on both my GeForce 6800 and ATI X1400, that the vertex shader was the bottleneck. The (more than a few) matrix multiplications needed to calculate the tangent, binormal, normal in object space were tearing up my GPU apparently... oh well... once i fixed that, it again greatly improved performance.

Anyway thats its for now for my level saga. Hopefully that wasn't too boring - consider this "to be continued"

Bryan's space: General Game Programming

Level Formats