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! 

 

...but it comes with zero assurances of it actually working or not corrupting data. :P

I took some of my lunch hour today to see if this could be done quickly.

http://files.getdropbox.com/u/161473/Vis.zip

That should be a multi-threaded version of BJP VIS. When you run it, you'll see some additional text appear like:

"Using X threads."

The X will be however many cores/processors you have in your machine.

The percentage and progres stuff is all kinds of messed up and I don't have time to fix it today - lunch time is over! But I'll take a look at that in the future once the basics are nailed down.

Anyway, try it, run some side by side timings and let me know if I'm crazy or if this actually works.

The best way to see it work is to start up your Task Manager and look at the processor activity. All of your cores/processors should be pegged at 100% when this is running.

Thanks! 

swapping to your vis for all my vising needs. i'm seeing 100% cpu usage, so it appears to be working fine. i'll let you know if anything weird happens.

you are currently on my list of people made of awesomeness for this, btw. ^_^

damn, i wish i had a quad core though. :( 

The part that scares me is if the map will load into Quake when it's done. That's something I can't test here. :) Let me know, plz! 

Despite it may load, it also can generates HOMs and leaks.... wait and see :P 

I don't see why it shouldn't load into Quake. After all, all you changed was the resource management. The actual vis calculation and state file handling remains untouched.
I'm running a test at the moment. One hour of willemvis vs one hour of regular (single-threaded) vis. The time estimations would help here, but whatever. No idea if there's much of a gain. I don't have a real multicore machine, just one of those p4-hyperthreading dudes (I was always suspicious about this being a possible bottleneck). 

How many threads does it say you're using? If it's more than 1, you should see SOME improvement. 

I also renamed the EXE for easier use.

http://files.getdropbox.com/u/161473/WVis.zip

Give that a shot if you want the time estimates to be useful.