First Look At The .proc File

[OrbWeaver]

I had a look at the text-based .proc files for a few maps, and a large part of the content seems obvious, with the non-obvious part being something to do with the BSP tree.

 

First up are model declarations, like so:

 

model { /* name = */ "trap_button_1" /* numSurfaces = */ 1

/* surface 0 */ { "textures/base_light/reactorlight1" /* numVerts = */ 24 /* numIndexes = */ 36
( 8 -16 16 -0.5 0 1 0 0 ) ( 8 16 16 0.5 0 1 0 0 ) ( 8 16 -8 0.5 1 1 0 0 ) 
( 8 -16 -8 -0.5 1 1 0 0 ) ( -8 -16 16 0.5 0 -1 0 0 ) ( -8 16 -8 -0.5 1 -1 0 0 ) 
( -8 16 16 -0.5 0 -1 0 0 ) ( -8 -16 -8 0.5 1 -1 0 0 ) ( -8 16 16 1.4999991655 0 0 1 0 ) 
( 8 16 -8 0.4999991953 1 0 1 0 ) ( 8 16 16 0.4999991953 0 0 1 0 ) ( -8 16 -8 1.4999991655 1 0 1 0 ) 
( -8 -16 16 0.4999992549 0 0 -1 0 ) ( 8 -16 16 1.4999992847 0 0 -1 0 ) ( 8 -16 -8 1.4999992847 1 0 -1 0 ) 
( -8 -16 -8 0.4999992549 1 0 -1 0 ) ( -8 16 16 0.5 -0.5 0 0 1 ) ( 8 16 16 0.5 0.5 0 0 1 ) 
( 8 -16 16 -0.5 0.5 0 0 1 ) ( -8 -16 16 -0.5 -0.5 0 0 1 ) ( -8 16 -8 0.5 0.5 0 0 -1 ) 
( 8 -16 -8 -0.5 -0.5 0 0 -1 ) ( 8 16 -8 0.5 -0.5 0 0 -1 ) ( -8 -16 -8 -0.5 0.5 0 0 -1 ) 
0 1 2 3 0 2 4 5 6 7 5 4 8 9 10 11 9 8 
12 13 14 15 12 14 16 17 18 19 16 18 20 21 22 23 21 20 
}

}

 

Here we have a model { } decl consiting of a string name, an integer number of surfaces and then a series of surface { } decls. Each surface decl in turn has a string texture name, a number of vertices, a number of indexes (which is the list of vertices which are interpreted in groups of 3 to form triangles), then the vertex decls, then the list of indices (0 1 2 -> first triangle, 3 0 2 -> second triangle, etc)

 

I'm guessing that a vertex decl of ( 8 -16 16 -0.5 0 1 0 0 ) represents a vertex at position <8, -16, 16> with texture coordinates <-0.5, 0> and normal vector <1, 0, 0>. Looking at the other vertices in more complex surfaces seems to confirm this (at least because for the cubes the normals are always unit vectors whereas for other surfaces they take on floating points).

 

After the models is the portal connectivity section

 

nterAreaPortals { /* numAreas = */ 9 /* numIAP = */ 8

/* interAreaPortal format is: numPoints positiveSideArea negativeSideArea ( point) ... */
/* iap 0 */ 4 0 1 ( 320 200 0 ) ( 448 200 0 ) ( 448 200 128 ) ( 320 200 128 ) 
/* iap 1 */ 4 1 2 ( 320 64 0 ) ( 448 64 0 ) ( 448 64 128 ) ( 320 64 128 ) 
/* iap 2 */ 4 3 1 ( 184 64 0 ) ( 184 192 0 ) ( 184 192 128 ) ( 184 64 128 ) 
/* iap 3 */ 4 5 4 ( -344 256 220 ) ( -344 376 220 ) ( -344 376 384 ) ( -344 256 384 ) 
/* iap 4 */ 4 5 6 ( -824 256 220 ) ( -704 256 220 ) ( -704 256 384 ) ( -824 256 384 ) 
/* iap 5 */ 4 7 5 ( -372 248 220 ) ( -418 248 220 ) ( -418 248 314 ) ( -372 248 314 ) 
/* iap 6 */ 4 4 3 ( -200 -128 48 ) ( -200 0 48 ) ( -200 0 176 ) ( -200 -128 176 ) 
/* iap 7 */ 4 8 6 ( -696 0 220 ) ( -696 -128 220 ) ( -696 -128 384 ) ( -696 0 384 ) 
}

 

This again seems to be self-evident -- each portal has a number of points (almost always 4, because they are rectangular), then a positive "area" and a negative "area". If you look at the names for the model decls you see that they have names like "_area7" and "_area8", which seem to correspond with the "area" numbers in the portal section. Following this is a list of 4 vertices, clearly the bounding points of the portal.

 

Next is the bit I don't understand, about tree nodes.

 

nodes { /* numNodes = */ 218

/* node format is: ( planeVector ) positiveChild negativeChild */
/* a child number of 0 is an opaque, solid area */
/* negative child numbers are areas: (-1-child) */
/* node 0 */ ( 1 0 0 0 ) 1 45
/* node 1 */ ( 0 1 0 0 ) 2 32
/* node 2 */ ( 0 0 1 0 ) 3 0
/* node 3 */ ( 1 0 0 -184 ) 4 28
/* node 4 */ ( 0 1 0 -64 ) 5 23
/* node 5 */ ( 0 1 0 -200 ) 6 12
/* node 6 */ ( 0 1 0 -320 ) 0 7
/* node 7 */ ( 0 0 1 -248 ) 0 8
/* node 8 */ ( 1 0 0 -192 ) 9 0
...

 

I'm guessing that this is something to do with placing geometry into nodes in a tree, so it can be more efficiently culled -- but why is this not handled by the area portal system already? The comments helpfully explain what negative child numbers mean but not positives, although the plane vectors presumably specify an infinite plane which divides the geometry into two (this is how BSP works).

 

Finally there is the shadow model information, which is similar to the model decls

 

shadowModel { /* name = */ "_prelight_light_3"

/* numVerts = */ 74 /* noCaps = */ 60 /* noFrontCaps = */ 96 /* numIndexes = */ 132 /* planeBits = */ 10
( 184 64 0 ) ( 76 46 -49.5 ) ( 184 64 128 ) ( 76 46 150.5 ) ( 184 -96 0 ) 
( 76 -204 -49.5 ) ( 184 64 0 ) ( 76 46 -49.5 ) ( 184 64 128 ) ( 76 46 150.5 ) 
( 184 -96 51.5820884705 ) ( 76 -204 31.0970134735 ) ( 184 -96 51.5820884705 ) ( 76 -204 31.0970134735 ) ( 184 64 128 ) 
( 76 46 150.5 ) ( 184 -96 194.8656768799 ) ( 76 -204 254.9776153564 ) ( 184 248 240 ) ( 76 333.5 325.5 ) 
( 184 248 240 ) ( 76 333.5 325.5 ) ( 184 -96 240 ) ( 76 -204 325.5 ) ( 184 -96 194.8656768799 ) 
( 76 -204 254.9776153564 ) ( 184 64 128 ) ( 76 46 150.5 ) ( 184 192 128 ) ( 76 246 150.5 ) 
( 184 248 0 ) ( 76 333.5 -49.5 ) ( 184 192 0 ) ( 76 246 -49.5 ) ( 184 -96 0 ) 
( 76 -204 -49.5 ) ( 184 64 0 ) ( 76 46 -49.5 ) ( 184 248 240 ) ( 76 333.5 325.5 ) 
( 184 -96 240 ) ( 76 -204 325.5 ) ( 184 -204 0 ) ( 184 -204 0 ) ( 184 -204 0 ) 
( 184 -204 0 ) ( 184 -96 0 ) ( 76 -204 -49.5 ) ( 184 -96 51.5820884705 ) ( 76 -204 31.0970134735 ) 
( 184 -204 240 ) ( 184 -204 240 ) ( 184 -204 0 ) ( 184 -204 0 ) ( 184 -96 51.5820884705 ) 
( 76 -204 31.0970134735 ) ( 184 -96 194.8656768799 ) ( 76 -204 254.9776153564 ) ( 184 -204 240 ) ( 184 -204 240 ) 
( 184 -96 240 ) ( 76 -204 325.5 ) ( 184 -204 240 ) ( 184 -204 240 ) ( 184 -96 194.8656768799 ) 
( 76 -204 254.9776153564 ) ( 184 -204 0 ) ( 184 -204 0 ) ( 184 -96 0 ) ( 76 -204 -49.5 ) 
( 184 -96 240 ) ( 76 -204 325.5 ) ( 184 -204 240 ) ( 184 -204 240 ) 
0 2 1 2 3 1 34 36 35 36 37 35 38 40 41 38 41 39 
2 28 3 28 29 3 30 18 31 18 19 31 28 32 33 28 33 29 
32 30 33 30 31 33 66 68 67 68 69 67 50 42 43 50 43 51 
70 72 73 70 73 71 5 7 9 5 9 11 13 15 17 21 23 25 
21 25 27 29 19 3 29 31 19 33 31 29 45 47 49 53 55 57 
53 57 59 61 63 65 8 6 4 10 8 4 16 14 12 24 22 20 
26 24 20 2 18 28 18 30 28 28 30 32 48 46 44 56 54 52 
58 56 52 64 62 60 
}

 

Again this is vertex and index information (but without normals or UV information this time), and some global parameters which make some sense in the context of shadow volumes although it is not obvious how they are used (or what planeBits means).

[sparhawk]

Why are there 24 vertices for the cube? I would expect either 8 or 36, but I don't see where the 24 comes from.

[OrbWeaver]

Why are there 24 vertices for the cube? I would expect either 8 or 36, but I don't see where the 24 comes from.

 

Because each square face has its own set of 4 vertices, so that it can have its own texture projection (a single vertex may only have one set of texture coordinates associated with it).

[greebo]

You might want to take a look at this: http://developer.infi.nl/index.php?ID=5

 

This guy managed to write a level viewer that makes use of the .cm file. That's where I got some of the information from when writing the CM-Exporter.

 

It's of course the opposite direction he's taking, interpreting instead of generating, but maybe the source gives us some clues. I don't think that he uses the shadow stuff, or even the .proc file, but it may be of some help. That and the quake3 source code.

[OrbWeaver]

That's useful, it looks like one of those demos uses portal information which might shed some light on the node/portal stuff.

 

That said, working out the format is the easy part, probably 5% of the total map-compiling solution. Beyond that, it is necessary to

 

1. Flood fill the level, detecting any leaks and placing primitives into portal areas (which may involve splitting brushes if they cross a portal boundary).

2. Merging adjacent brush surfaces into planar windings, and turning these into triangles

3. Optimise the generated triangles to reduce polycount

4. Generate the shadow volumes based on light volume positions and the geometry within them.

 

It is of course possible that 1-3 are already covered by the Q3 map code. It would probably have to be done in stages -- first step would be to spit out a basic non-optimised, non-portalled map from the brush and patch information.

[New Horizon]

Wow, that guy is doing some pretty cool stuff. Wonder if he's available? Ha ha.

[greebo]

While I agree that such a feature would be really nice, I don't think that we should try to implement it before any DarkRadiant 1.0 release. It's very likely that we need months to mimic the dmap command, so that we should rather rewrite DR's nodesystem or the renderer before attacking this.

 

I mean, hey that would definitely be cool, but the benefit vs. expense ratio is very low in this case, as it takes only 2 seconds more to call the dmap command in the D3 console.

 

Hah, I guess I sound like grumpy old man again. I better shut my mouth and get back to work now.

[OrbWeaver]

I agree, it is certainly not a high priority feature. It is nevertheless desirable at some stage, and having at least a vague idea of how it could be implemented is better than just a "Wouldn't it be nice if...?"

 

The main disadvantage of dmap in Doom 3 is that it takes absolutely ages compared with the DoomEdit dmap. I suspect this is because of the low text refresh rate of the Doom 3 console, which can slow things down.

[sparhawk]

Yes. The console blocks a lot of speed. You can see this when dumping info to the console in the SDK. The code slows to a crawl with this, because it seems not to be optimized so well.

 

I also agree that this is not really an important feature, but it would be nice to have it. My hopes would be that a much improved leak detection would be possible, because with the Doomedit solution, I never really know where to look.