I was looking at my console window fill up with everything q3map2 was spiting out into the log file…and I wondered what a lot of it meant, Particularly the TraceGrid process.
What does TraceGrid do?
Is there a guide somewhere that explains what all of the q3map2 log output means?
thanks
Very interesting, but what about the other stuff the compiler does? Is this information catalogued anywhere? Thanks
Primarily, Q3Map2 does 3 things, BSP, VIS and LIGHT.
BSP (binary space partition) is how the compiler takes your brushes and subdivides each volume to basically figure out where all the walls are. It builds all the vertexes, vectors and normals for all the surfaces.
VIS starts to sort out visibility clusters, it’s how the engine maps out ahead of time what chunks of the map are visible from each location in the map. It does so by looking at the BSP tree generated in the previous stage to figure out what is beyond the players point of view.
LIGHT obviously compiles lighting. It uses point lights, sky lights and surface lights to do several different lighting algorithms. It calculates lightgrid, vertex light and lightmaps.
The lightgrid is like a giant 3D-grid that spans the map, containing square blocks with dimensions matching your lightgrid size (default 128 units). Q3Map2 calculates a fixed colour value for each of these blocks depending on the brightness, colour and proximity of your lights relative to each block. The lightgrid is used by dynamic models (players, items and weapon models) to run a cheap calculation to light these objects. For example, if your player model runs into a red block of the lightgrid (coloured so because of a nearby red light), the engine takes the player model’s vertex colours and multiplies it with the red colour value of the block, resulting in the appearance that the player model is lit by the nearby light.
Vertex light are colour values assigned to the vertex points of brushes, patches and static map models. These stored vertex colour values are used to approximate lighting. It’s very inexpensive on the renderer which is why on really old systems you can see a performance benefit to using r_vertexlight 1. It also has a tendancy to look better on stuff with lots of small polygons like models than if they were lightmapped (which is why all map models are by default vertex lit). If you think of a wall made up of a single quad (square polygon) that is lit from a light above, it should be light on top and dark on the bottom. The vertex points of this quad will be assigned lighter vertex colour values on the top 2 corners, and darker vertex colour values on the bottom 2 corners. Using these generated vertex colours, the engine will generate a shaded gradient spanning the surface of the quad.
Lastly, lightmaps are textures generated by Q3Map2 from all your light sources using a radiosity algorithm. The lightmap textures are layered over top of your normal textures with a filtering blendFunc, essentially darkening the surface in order to represent shadows. There are all sorts of little things that Q3Map2 does to the lightmap during the radiosity process that could be explained further like filtering and ambient occlusion, but those are a whole different topic on their own.
That explains a lot, thanks Obsidian, excellent posts as always. I don’t suppose this is all written down somewhere? The q3map2 wikibook just seems to cover what the major and minor switches do, and even that’s spotty.
I was watching the BSP process go on my latest map, which is horrifyingly gigantic, and I saw this:
— FloodAreas —
2 areas
What’s an area? Why is it being flooded? How on earth does a map as layered and huge as mine only have 2 “areas”? Does the number of areas effect how the VIS process runs?
Thanks