Taken from The QuakeLab: Editing website http://www.planetquake.com/quakelab/ Used by kind permission of Steve Fukuda [The QuakeLab] [Compiling and Editing Problems and Solutions] [Editor] [BSP] [Light] [VIS] [Startup] [Gameplay] Modified June 7, 1997 |------------------------------|----------------------------------------------| | Problem | Solution | -------------------------------|----------------------------------------------| | |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, | |leaf with too many portals |by moving the second grate up out of the | | |way by a mere 32 pixels or so, out of the | |The map was made of two |same Z axis, the level compiled just fine | |areas; as separate areas they |and VIS ran without a hitch. So what I did | |compiled without a problem, |to get that second grate to sit back where | |but after combining them and |I wanted it was to turn it into a | |running VIS, the error |func_train and start it high, so it'd | |occurred. |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 | |------------------------------|----------------------------------------------| | |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 | |---- vis ---- |leaf is convex, and therefore cannot see | |fastvis=true |into itself. This is a bug in the VIS | |470 portalleafs |algorthm, and my guess as to what would be | |1561 numportals |causing the problems would be: | |*********** ERROR ********** | | |Leaf portals saw into leaf |Either, due to small, complex areas, a leaf | | |has been created which is so small that | |Message displayed when |proper calculations cannot be performed. Or | |running VIS. |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 | |------------------------------|----------------------------------------------| | |Of course its not going to VIS! What is | | |happening here is that every node of the | |RemovePortalFromNode: Portal |current hull has a linked list of portals | |not in leaf |for that node. If that node doesn't | | |generate a portal then you are hosed | |When running the QBSP that |because VIS requires a list of portals to | |comes with Worldcraft, no |do anything. Have you tried a different | |errors but the level still |version of qbsp? The one that comes with | |does not vis, with qbsp DOS, |WorldCraft has a lot of constants decreased | |gives the above message. |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 | |------------------------------|----------------------------------------------| | |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 | |vis-ts -level 4 mymap |just a modification after all). In general | | |I have found that vis -fast is absolutely | |Half way through the full |worthless. The dataset that it generates is | |calculation (i.e. not the |very unreliable at best because it relies | |base vis) VIS halts with with |on a precursory visibility check rather | |the following error message: |than examining via portals and seperating | | |planes. My suggestion is to avoid vis -fast | |leaf recursion |because even though it is faster the actual | | |performance is not worth the cpu time. | |Second try: | | | |The leaf recursion error has to do with the | |vis-ts -fast mymap |threads of vis testing to see if the | | |correct data is being used. And the leaf | |VIS halts with the following |portals saw into leaf error is a result of | |error message: |checking visibility bits in the working | | |thread. These errors are very common when | |Leaf portal saw into leaf |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 |I think the problem lies in complicated | |well. A regular qbsp finished |brushes. I had a medium to large level with | |in about five minutes. The |a LOT of 4 sided spikes in it, with a 1 | |only problems noted were a |pixel tip. Small on the ceiling and large | |few |in a pit. As it wasn't fully finished I | | |only had one STRONG light in the room for | |CutNodePortals_r:new portal |testing purposes (about 1000 for value), I | |was clipped away |think that VIS can get stuck trying to | | |figure out how to tackle the problem. Try | |which for better or worse |getting a new or better set of utils. Also | |I've learned to ignore. The |I ended up deleting the spikes and my level | |real problem is that vis |is now vising in about 1250 secs on a P120 | |never seems to finish. I've |with 32mb Ram. It has WELL over 2000 | |had it running for 24 hours |numportals. | |now on a MediaGX and it has | | |been running for 12 hours on |So just get a better version of VIS (256c?) | |a Pentium 133. Can Vis get |and if that doesn't work delete the | |stuck? The only messages so |complicated brush(es) and see what happens. | |far have been |- Alex Gingell | |------------------------------|----------------------------------------------| |342 portalleafs | | |928 numportals | | | | | |- David R. Wiley | | | | | |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 |And here is the corresponding solution... | |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 | | |------------------------------|----------------------------------------------| |QBSP runs without incident. | | |VIS runs but displays this | | |message for a particularly | | |long time: | | | | | |---- vis ---- | | |53 portalleafs |And here is the corresponding solution... | |126 numportals | | |leaf flow for leaf 0 | | |leaf flow for leaf 0 | | |leaf flow for leaf 9 | | | | | |- Jason Spencer | | |------------------------------|----------------------------------------------| | |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 | |Excessive VIS times (>24 |another way to monitor VIS' progress: get | |hours.) |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 |And here is the corresponding solution... | | | | |When vising the same level | | |with | | | | | |vis -level 2 -v | | | | | |it runs up to mightsee:335 | | |and gets stuck... but no | | |error - Eric Braun | | |------------------------------|----------------------------------------------|