Modified June 7, 1997
|
|
|
|
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... |