The QuakeLab
Compiling and Editing Problems and Solutions
Editor BSP Light VIS Startup Gameplay

Modified June 7, 1997

Problem
Solution
leaf with too many portals

The map was made of two areas; as separate areas they compiled without a problem, but after combining them and running VIS, the error occurred.
This occurs when you have large or extremely complex rooms with lots of architecture. Another fellow was having the same problem. He e-mailed me that he got the source code for VIS and edited the header to double the MaxPortalLeafNum. He recompiled it and it worked just fine. - Ed Cope

(ed. Source code may be forthcoming in future.)
This occurred when I tried to construct a grate on top of a trench filled with water. At first the grate was small; and it compiled ok. When I made a second grate over a trench further down the hall, it came up with that error. Bear in mind that these two grates, which were far apart from one another, were in the same Z axis. So, by moving the second grate up out of the way by a mere 32 pixels or so, out of the same Z axis, the level compiled just fine and VIS ran without a hitch. So what I did to get that second grate to sit back where I wanted it was to turn it into a func_train and start it high, so it'd compile, then when you run the level it'd drop into place and stay using a path_corner with a wait of -1. Then again, this was what worked for me, there may be more to that problem. Apparently a "leaf" is broad region of a map following the same axis, or so it'd seem. - Chad (last name unknown)
This problem is due to the leaf data structure in vis. Each leaf has a fixed array of portals that can be on the leaf. The array size is 128 normally. If you want to increase this just change a constant in vis.h, Its MAX_LEAF_PORTALS if I remember correctly. (256 is probably a good value. only once did I need to set it to 512 to make it work). A few people have complained to me about it and I cobbled together the change for them. As far as I know it has no detrimental effect on either the effect of the vis or the time it takes. - Troy Mann
---- vis ----
fastvis=true
470 portalleafs
1561 numportals
*********** ERROR **********
Leaf portals saw into leaf


Message displayed when running VIS.
Try running a full VIS instead of -fast. Possibly caused by overstacking of brushes (too many floors in a bell tower, for example).
Oh, this is a nasty one. For some reason, vis has found a leaf which can see into itself, which is not possible since each leaf is convex, and therefore cannot see into itself. This is a bug in the VIS algorthm, and my guess as to what would be causing the problems would be:

Either, due to small, complex areas, a leaf has been created which is so small that proper calculations cannot be performed. Or some error in the basic algorithm used which only comes up in rare situations...Since Vis was run in -fast mode, the algorithm used is much simpler, and tends to overestimate what you can see. Running in normal mode might actualy work, but I'd rebuild the last area created before the error just in case. - Jason Booth
RemovePortalFromNode: Portal not in leaf

When running the QBSP that comes with Worldcraft, no errors but the level still does not vis, with qbsp DOS, gives the above message.
Of course its not going to VIS! What is happening here is that every node of the current hull has a linked list of portals for that node. If that node doesn't generate a portal then you are hosed because VIS requires a list of portals to do anything. Have you tried a different version of qbsp? The one that comes with WorldCraft has a lot of constants decreased so it works in less memory - that may have an effect on this problem. Also the original qbsp source has this as an error and not just a warning. - Troy Mann
vis-ts -level 4 mymap

Half way through the full calculation (i.e. not the base vis) VIS halts with with the following error message:

leaf recursion

Second try:

vis-ts -fast mymap

VIS halts with the following error message:

Leaf portal saw into leaf

I remembered seeing somewhere that a guy was having problems (can't remember what) so he copied his whole map into the Clipboard then pasted it into a new file. I tried this and it worked. - Eric Conway
I wrote vis-ts and used the same algorithm for vis that is found in the id code (its just a modification after all). In general I have found that vis -fast is absolutely worthless. The dataset that it generates is very unreliable at best because it relies on a precursory visibility check rather than examining via portals and seperating planes. My suggestion is to avoid vis -fast because even though it is faster the actual performance is not worth the cpu time.

The leaf recursion error has to do with the threads of vis testing to see if the correct data is being used. And the leaf portals saw into leaf error is a result of checking visibility bits in the working thread. These errors are very common when using -fast in my experience too.

The moral of this whole thing is if you are going to vis dont be a wuss about it, go ahead and vis with a level 2 vis. (Although I have not had time to test, I believe a level 2 vis to be the most efficient. Many people do level 4 to be thorough but its probably overkill). Forget fast vis. Its not worth it. - Troy Mann
I have a medium-small-sized level (224 brushes) that has been built piecewise. I stuck all the pieces together for the first time in a while to see if the level still runs well. A regular qbsp finished in about five minutes. The only problems noted were a few

CutNodePortals_r:new portal was clipped away

which for better or worse I've learned to ignore. The real problem is that vis never seems to finish. I've had it running for 24 hours now on a MediaGX and it has been running for 12 hours on a Pentium 133. Can Vis get stuck? The only messages so far have been

342 portalleafs
928 numportals


- David R. Wiley
I think the problem lies in complicated brushes. I had a medium to large level with a LOT of 4 sided spikes in it, with a 1 pixel tip. Small on the ceiling and large in a pit. As it wasn't fully finished I only had one STRONG light in the room for testing purposes (about 1000 for value), I think that VIS can get stuck trying to figure out how to tackle the problem. Try getting a new or better set of utils. Also I ended up deleting the spikes and my level is now vising in about 1250 secs on a P120 with 32mb Ram. It has WELL over 2000 numportals.

So just get a better version of VIS (256c?) and if that doesn't work delete the complicated brush(es) and see what happens. - Alex Gingell
Small DM level, just brushes and lights, all leaks fixed, fas VIS performed no problem.

Added health, ammo, armor, and weapons. Level will not VIS anymore. When I used the level with WINQUAKE I noticed not all the items I added were present. When I used the level in Quake run from DOS, I got a msg. at the start that items "fell through."

I attributed this to placing an item inside a wall or touching the outside but I check the map and no such item exists, especially the ones that disappeared. The pointfile is not much help either - just a big loop. - Sandy Cormack
And here is the corresponding solution...
QBSP runs without incident. VIS runs but displays this message for a particularly long time:

---- vis ----
53 portalleafs
126 numportals
leaf flow for leaf 0
leaf flow for leaf 0
leaf flow for leaf 9


- Jason Spencer
And here is the corresponding solution...
Excessive VIS times (>24 hours.) I've noticed quite often complaints about a very long vis time (>24 hours) and asking if vis may have got stuck. It hasn't - some levels just take incredibly long to VIS. If you can abort VIS by pressing ctrl-c it was still running (not very useful to see if vis IS already running, though ;)). Besides just waiting another day or so there is another way to monitor VIS' progress: get QUBE.ZIP from ftp.cdrom.com - it has enhanced versions of the Quake utilities, that are running a bit slower but show you just about everything that the program is currently doing. The Qube VIS, for example, has an indicator for every face that was/has to be calculated, so that you can see well how much VIS has to do yet. - Matthias Worch
When vising using

vislight, level 2, verbose
Critical Ratio:3.00


it breaks right after it finishes with the base vis. with the error:

leaf recursion

When vising the same level with

vis -level 2 -v

it runs up to mightsee:335 and gets stuck... but no error - Eric Braun
And here is the corresponding solution...