The Bright Building

Problems and Solutions

Problem #1 - No free edicts

Solution -

I encountered this problem during some preliminary size tests. I wasn't sure what the limits of the Quake engine were, and whether this project might exceed them. So, I threw together a .MAP using the 3rd floor as model for all seven floors.

I had placed "light" entities throughout the floor -- in hallways, in each classroom, everywhere. End result, the test .MAP had over 500 lights. Yikes! Doing a little research, I discovered that the limit for dynamic entities was about 450. That included the players, and any rockets/spikes they might have recently fired. So, if I wanted to support 32 players, I had to drastically reduce the number of lights in the .MAP.

The problem then became, where to strategically locate a minimal number of lights so that all of the walls in the .MAP were lit. At first, I tried cranking up the intensity of each light (from 200 to about 500), but that just resulted in some places being really bright, while others were still pitch black.

I recalled from posts on r.c.g.q.e that there was a utility for setting the ambient lighting in a level called MINLIGHT. So, I downloaded it and was quite happy to find it would light walls that weren't lit by light entities.

This allowed me to knock my entity count down to about 300, with about one third of them being lights (which worked out to about 10-12 lights per floor).

Towards the end of the project, ARGHLITE was released. Not only did it support ambient lighting like MINLIGHT, it also provided a way to control the "fade" of the lights. This allowed me to lower the light intensities without sacrificing the distance the light would travel.

The final .MAP used lights with intensities of 350. It was compiled using ARGHLITE with "-light 24 -dist .666" as parameters.

Without MINLIGHT/ARGHLITE, there would have been no way to properly light a .MAP of this size.

Problem #2 - ReadClipHull: MAX_MAP_CLIPNODES

Solution -

I encountered this problem after I had completed my first version of the .MAP. The first version had about 2000 brushes. However, I wasn't completely satisfied with its appearence. The walls were all very flat -- a little too Wolfensteinish. The textures I used for each of the seven floors were "horizontal" -- that is, their lines ran from side to side. So, I thought of a neat trick using BMP2MAP to help fill out the walls. I outlined each wall with a window color. I then adjusted the window tops and bottoms to be properly aligned with the horizontal lines in the textures. The end result was walls that that had a nice 3D effect. However, it created this MAX_MAP_CLIPNODES problem.

The limiting number was 32767, since clip nodes each have an ID represented by a short int. At first, I thought this might just be a limitation of the version of QBSP that was used. However, further investigation revealed that this was actually a limitation of the .BSP file format -- so upping the level in the QBSP compiler would not have helped.

I thought I had found a neat solution at one point by eliminating the clip nodes in what reported as being an empty hull. However, John Carmack at id Software indicated that this wasn't an acceptable solution, so I had to figure something else out.

In the end, I ended up using the "skyed window" option of BMP2MAP using the special "CLIP" texture for the sky for the small lips on the walls. I left the larger lips empty, so players could actually hop up onto the lip.

Below are my postings to r.c.g.q.e on the subject.

jkp2866@unix.NOSPAM.tamu edu (Jack Perdue) wrote:

>Howdy all,

>I posed this question to the gods, but I know they're busy,
>so I thought maybe one of my fellow mortals might be able to help.

>If QBSP indicates:

>Hullnum 2: No entities in empty space - no filling performed

>is it safe to toss the clip nodes in the .H2 file?

>At present, the .MAP I'm working out has about 38K clip nodes
>between .H1/.H2 (26K/12K) when QBSPed.  Thus, I receive a 
>MAX_MAP_CLIPNODES error at the end.  From what I can glean
>from the Unofficial Quake Specs, there is no way to overcome
>the limit of 32767 in the .BSP file because the child node
>id's are short ints.  Is this correct?

>Some quick testing has revealed that if I edit the .H2 file
>to have 0 clip nodes after receiving the above message, and then
>run QBSP with the -usehulls option, everything _seems_ to be okay
>(i.e., I don't fall through the floor, I don't walk through walls).  

>It _seems_ the .H2 file only contains the clip nodes
>from the outside, and since nothing can get outside, they are
>not needed.  Is this true?

>Any answers y'all can provide are greatly appreciated.


>jack (aka Silicon Slick - 300 miles and 5000 clip nodes too far from Quakecon)
>Clan 13th Man - ../../fromhttp/Clan13thMan/

>ps. FYI, the level I'm working on is currently documented at:


>    My last successful build had about 2000 brushes.  The version
>    I would like to do has about 6000.  

Howdy all,

Well, one of the gods spoke to me (actually it was e-mail... and he's 
not quite immortal yet... but his initials _are_ JC) and here's what 
I've learned.

1) The empty Hull 2 problem (I didn't think it was a problem) is caused by:

   "That usually means that you don't have any entities more than 
    32 units away from a wall.  Drop a light in the middle of a room 
    and it should go away."

   Well, I'm sure that I had such a creature (indeed I do), and 
   replied thusly. 

2) In addition, I asked of the significance of Hull 2/the .H2 file (since
   I was pondering the effects of my statements above).  The short and
   sweet response was:

   "No, every map needs a hull 2."

So... I'm screwed... too many freaking clip nodes, whatever the heck they
are, so I can't do what I set out to do...  

Bull[snip], I'm not buying it... (my defeat that is)

So, create a cube.  QBSP it.  Analyse the clip nodes.  Okay.  Create
a hollow cube. QBSP it. Analyse the clip nodes. Okay.  Read the source
to QBSP.  Read it again.  Keep reading it even though I don't have a clue
what a surface and an edge and a node are.  Okay.  How about...


 Part I: Eliminating the empty hull error -- 32 units may be right for the
         horizontal, but looking at the .H? files, I'm not sure that's 
         sufficient on the vertical.  For example, I have a light in the
         middle of a room, but the ceiling is at +60 to it's center and
         the floor is at -60 to it's center.  That should be at least 32 
         on each side.  So, I'm thinking the clip nodes on the floor 
         are much higher at this point.

         Anyway, suspending an info_intermission in the middle of a cavern
         has seemed to do the trick.  I didn't think it was a problem,
         but I'm only knowledgeable enough to be dangerous. ;)

         The fact I didn't get the empty hull 2 message signficantly
         decreased the number of clip nodes.  However, it wasn't enough...
Part II: I figured out a way to reduce the number of clip nodes from 
         39K to 25K (the .MAP is still ~6000 brushes) by thinking a little 
         about what they were used for.

         Basically, I've filled in the gaps using the CLIP texture (whose
         very existence is to define clip nodes).  Here's an example in
         ASCII (W=wall, C=CLIP texture):

             WWWW              WWWW
             WWWW              WWWW
             WW                WWCC
             WW                WWCC
             WW                WWCC
             WW      o         WWCC    o 
             WW     /|\        WWCC   /|\
             WWWW    |         WWWW    |
             WWWW   / \        WWWW   / \
                 old               new
                 wall              wall

         So, instead of three clipping surfaces facing the player on each
         wall, now there's only one (at least that's my present theory).

Anyway, it works and I'm a happy camper.  

Thought I'd pass that along.  I'll go away now (you wish ;).  

I'll be  buried in my .MAP if anyone needs me.

jack (aka Silicon Slick)
Clan 13th Man - ../../fromhttp/Clan13thMan/

ps. using wQBSP/ARGHLITE/RVIS, a -fast (no -extra) build only took 
    two hours on this latest version, if anyone is really interested.
    "Size isn't everything." :)

To do Main Main

This page was last updated August 17th, 1997
Jack Perdue /
Department of Computer Science
College of Engineering
Texas A&M University