 |
A 69, Oh!
|
|
#1690 Posted by palldjon [203.29.11.254], 27/09/2001 02:11 GMT
|
My mapping sys has crashed badly. I'll be off line for a week or so while it gets an enema, but just before I go...
I found this gem on a search through the Qboard archive. Most of it applies to Quake as well as Quake2. A more succint and informative piece I have never seen.
A Quake 2 .map file is a collection of convex brushes. Each brush is made up from a number of plane surfaces. Each plane surface has a set of properties. The area the .map covers is a cube, extending 4096 units from the origin coordinates (0,0,0) in the X, Y, Z directions.
QBSP3 reads all the brush information from the .map file, checks for conflicting surface properties, invalid brushes and brushes which extend further than the 4096 unit limit. Intersecting brushes can cause mess later on, and so all intersecting brushes are subtracted from each other. Next QBSP begins to split up the negative (non-solid-brush) space in the map into solid convex volumes called "nodes", each described by its own set of planes just like a brush. To start with, it selects the best candidate plane it can find, and cuts the whole map into two areas, along this plane - the cut is called a "portal". Brush planes with a larger surface area are considered to be better candidates to be used to cut portals. To save time finding the best candidate in large maps, it just cuts the map literally in half along the plane X=0. The two halves are the first branches of a binary tree. The next cut splits the first half in half again, along the plane Y=0, the next splits the second half in half again along Y=0 and so on. Each area is split in half and in half again until the map is split into 64 1024*1024*8192 unit areas called blocks, which are now the lowest 'branches' of the binary tree. Most of these blocks do not contain any brushes, so they are each a solid convex volume and do not need splitting again - they are known as leaves, and each leaf terminates the branch of the tree it is on. The negative space in each of the remaining branches is split again to create more branches, this time using the best candidate plane surface of all the brushes in the branch. This is repeated over and over until the branches are convex leaf-nodes and do not need to be split again.
All surfaces with the "solid" property are candidates to be used by QBSP3 to create "portals", splitting up the space through which the player can move in the map. This information is saved in a BSP tree form - each node is a leaf of the tree.
Portals are cuts in the map chosen by qbsp3 from brush planes. All surfaces along a portal will be split by the cut it makes. The cuts can run the whole length of the block, or just the width of the brush, depending on how far down the tree they are created.
Leaf-nodes are convex, like brushes. When you run QVIS3, it goes through each leaf of the tree, calculating which of the other leaf-nodes it can "see", records this information in a table, compresses it, and writes it back to the BSP.
When you run around the map in Quake2, you're moving through the space which has been broken up into leaf-nodes. At any one instant in time, your position is determined to be in a single leaf-node, so Q2 uses the information which QVIS3 recorded, to decide which of the other leaf-nodes in the map are visible to you. As you move from one node to another, different areas become 'visible', this is very well illustrated by using gl_showtris 1 and walking around any fully compiled Q2 level.
Hint surfaces are candidates for creating portals. In QBSP3, they are given a higher priority than normal solid brushes, and are used earlier to create portals. Using them in your map allows you to more reliably control the location and extent of the portals, and therefore control the shape, position, and number of leaf-nodes in the BSP tree. Theyre called hints because they allow you to give QBSP some "hints" on the most efficient arrangement of the portals and nodes. Using hints creates new surfaces for qbsp to consider when choosing planes for portals, so more cuts are made in the map, increasing bsp complexity and increasing the number of polys created from each surface. To best avoid increasing complexity using hints, try to place hints aligned with the architecture in the map as much as possible. QBSP3 merges faces which are on the same plan and sharing the same properties, however there is a limit on the size of faces in Q2, any face with a dimension >=256 units will be split up, and it will not merge two faces if the resulting face is >=256 units high/wide.
When Willits made Q2dm1 I guess hint brushes were pretty new to him, so he hadn't had time to experiment to get the best use out of them. He's definetly done a better job of it in Q3test1, aligning hints to walls and using them in much larger numbers, and the map layout is also a little more bsp-friendly than Q2dm1. Despite this theres a lot more you can do with hints to improve the efficiency of qbsp3 and qvis3.
-SPoG
Thank you SPoG[Reply]
|
|
 |