Thursday 13 September 2007

Just a short post.

Bounding-box culling is now being performed between BSP leaves and the view frustum. The modelview and projection matrices are used to calculate 6 planes. If a box is entirely outside of this convex space (a VERY easy test to do, just dot products), then there's no point attempting to draw it. I want to extend this so a new set of planes are formed for portals. If this works out fast enough, then I can replace the existing hardware occlusion queries (they seem to have high bandwidth usage because they stall the pipeline in some way).

Also, I managed to get multiple Orb modules co-operating. This was difficult because it's easy for a pointer from one module to point to something belonging to a different module. When the pointer is serialized, a domino effect would occur which would result in the entire other module being archived in the same file. NOT desirable.

I'm having problems with the map loading code, which is delaying the implementation of normal mapped surfaces. The structures are there, but I can't use them yet. Frustrating.

Friday 7 September 2007

Why does id Tech 4 employ so much markup?

Something about Drift I didn't mention in my last post:

  • Terrain generation. A cuboid region can be created, and control points used to make outcrops of varying height and radius. Very easy to do, since the control point is added as a point entity with one extra field, 'radius'. I really want this to have dynamic level-of-detail in the form of quadtrees, and I have done some research into that, but it may be a while before I get round to implementing it.

I have just been rooting around the packages that come with Quake 4 and it seems that much of the resources in that game are plain-text. The level geometry is entirely in markup, which is largely human-readable and specifies everything from AI accessibility and entity dictionaries to brush planes and general decomposition (this appears to still be BSP but it's not clear). I say 'largely' human-readable, since sometimes all you are looking at is numbers. In the md5mesh format, there are tables of indices which are completely useless to a person, so exactly why has this move been made?

My first thought is machine independence. At load time, you simply parse the text into whatever is easiest for the machine to deal with, and these days that's not much of a speed hit. In the past, id has byteswapped structures when needed, and that's not a brilliant solution since it means machines engineered for architectures that require this byteswapping, will suffer a small performance hit. The solution I've gone for is to swap at the lowest level of the stream. This doesn't overcome the extra time needed, but it's as transparent as it's going to be. It's very nice to only care about these things once, and then be confident that all the upper layers will benefit.

I've been working on a way to serialise objects across the native filesystem, and I currently have a package file format, and cross-package references within the format. Each package provides a table of exports and imports, but the major problem is verifying that the data in the other package does indeed represent the original object that was pointed to. All I have right now is a unique number, which may become an MD5 hash or similar. Furthermore, is it really desirable to only allow the original object? The ability to 'supersede' the object with a modification would be interesting, but potentially unsafe. Adding an extra verification function to each class is a daunting task, but that might be the best option.

This weekend I plan to write a Quake 4 .map parser. I can already see how to parse the brushes. They are just a list of planes. Maybe that's why there's so much markup. To allow people like me to do things like that!

Why does id Tech 4 employ so much markup?

Some things I didn't mention in my last post: