 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
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. 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. 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. Haha
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
...you can generate them yourself from the BSP. Use for example BspInfo (delivered with aguirRe's visbjp suite) and the -prt flag.
...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!
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |