I'm still looking for a solution to the 'no 3d selection' issue - There are dll's that can be used but they screw up the texture rendering. 

Radiant and Quest run natively under Linux.

Several others run under wine (pretty well actually), if that floats your boat.

I'll learn Radiant soon anyway. 

I fucking love replaying 90% of my old speed maps. I never get tired of them, and I don't look at them critically (probably because I haven't improved much, if at all). 

Full: 75.01%, Elapsed:307h 39m, Left:482h 54m, Total:790h 33m, 38% 

Is it really worth the full vis? After all the map is very open. 

It'll still have an extremly high polycount, but even if the fullvis can only lower it slightly, it'll be worth it. 2000 is better than 4000. 

your computer will burn :|

make a backup of everything NOWWWWWW 

I wonder what the magic breaking point is for VIS. My latest map has gotten larger and is still VIS'ing in under 5 minutes. It has one huge room in it with lots of detail but even that doesn't seem to daunt VIS... 

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%