It scales up exponentially. A single room (how huge is huge in Quake terms) might work, but if most or all geometry is inside a single volume like in a space map, it creates a multitude of portals. There's one for every little edge and slope and all they also affect each other.

http://negke.quaddicted.com/images/coag_prt1.jpg
http://negke.quaddicted.com/images/coag_prt2.jpg

Note the portal jungle in the upper half. 

CDA seems near the magic breaking point, if anything.

That suggests if your map is one large sandbox with all structures open to it, and some triangle mesh etc perhaps, you might have good chances. 

wow, just saw those numbers. You love pain, right. 

get the urge to leave... 

Multithreaded VIS on 8-core Nehalems will make this problem pretty much go away. Remember, id had to use the most badass Alpha hardware available in '96 to compile their Quake maps.

or you know, detail brushes. 

or use Doom 3, no more vis. 

yeah, whatever you say about the lighting, the visibility system in doom3 is badass. 

What system resources uses Vis anyway ?
Does it help to have lots of memory and a good processor or could you just as well run it on a Pentium 1 from the old Quake days ? 

VIS process needs memory and a fast processor to limit its runtime.
It is based onto a recursive algorithm (a kind of "turtle" algorithm)... the faster the CPU will be, the less consuming the VIS runtime will be.. Having GBs of RAM will not help, as I don't think the process needs it... though...
But in anyway, VIS process is the evil one in the Quake map building flow :( 

Also, VIS benefits greatly from multithreading since each leaf can be processed independently of each other (which is how id ran theirs on their Alpha machines). I've enabled this in my Mac version of the tool but I don't think any Windows versions exist like that. 

I'm not exactly sure bout the implementation, but it seems it could be faster with multi core processor indeed.
I already discussed this topic with aguirRe, and he told me that ID indeed had their first VIS process running onto multicore Unix machine, but it has never been ported to Windows in this way: Window VIS tools are single CPU only, and AFAIK.. unless somebody has a specific tool on his own ;) 

The code is in there - it's just #ifdef'd out. All a Windows programmer would have to do is define "_alpha" (or whatever the symbol) is in preprocessor symbols of their compiler and fix the errors that spit out. It was really pretty simple on Mac.

I've not done much multithreading on Windows so I can't say how closely the structures and such relate to what id wrote on their Unix machine but it can't be more than a few hours of hunting around some documentation to find equivalents. 

...care to do me a little favor? 

Haha ... I might take a stab at it. Which VIS do people use? Point me at some source code and I'll take a crack at it this weekend but no promises... 

I didn't mean compiling the vis tool, though! 

negke already in 90% 

Full: 76.65%, Elapsed:359h 37m, Left:885h 2m, Total:1244h 39m, 28% 

negke

Oh, well, the best solution long term would be to get a Windows version with multithreading working. I could run it for you, yes, but that's painful. :P

To be clear, this?

http://user.tninet.se/~xir870k/visbjp.zip 

 

somebody provided be a vis tool that is supposed to run 40% faster than Id's original one... but I never tested it as I did not trust the guy that much: anyone who wants to benchmark it can send me an email: I'll provide the stuf.... at your own risk :P 

... I also have the source... 

Can someone hook me up with a .PRT and a matching .BSP file so I can run some VIS debugging? 

...you can generate them yourself from the BSP. Use for example BspInfo (delivered with aguirRe's visbjp suite) and the -prt flag. 

Ha! So you can, awesome. Thanks!