I donn know much about the technicalities of VIS, or BSP tree's for that matter. I do know that the VIS program creates portals, which are sort of like ares that are visible, while other areas are not, because they are hidden bu occulders (or something like that). I believe that it's also used to like determine the visibility of the surfaces which are affected by the lighting in the level. Perhaps I got it all wrong. 

If your map is like one big arena this is the worst possible scenario, because each portal can see most of the other portals and this takes a lot of time for the program to process. JPL's Castle of the Dark Ages is a very bad map for this and took 50 days for his computer to run vis. Three Towers and a Sick Base was a harsh learning curve for me in the wonderfull world of vis, that map took 6 and a half days to vis. Some of Tronyns maps are also like this. So making a huge map like you describe could work but you will have to keep the details pretty low, so that there are minimum portals.

Some of Ijed's maps in WARPSPASM are massive, some of the biggest levels ever, but he used effective vis-blocking (making sure that the map is broken up by walls and cleverly placed bends in corridors) amd vis times we're comparitively short for him.

Dont confuse vis-blocking with Worldcraft's vis-groups feature, they are completely unrelated.

A massive city could work if all of the buildings touch the sky and are flat on top, and all of a similar height (they will act as barriers and stop the vis process from considering too much of what is on the other side of them), but if you make it so that all of the rooftops are accessible then your finished map will take a huge amount of time to vis.

And your r_speeds will be very high, causeing even modern machines to stutter and suffer frame rate drops.

Please go and make a huge map with good gameplay and vis-blocking :)

Also hmap2 tools are not the best (sorry Lordhavoc), better use these:

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

:) 

Thanx for all that info,and I downloaded your tools, so I'll check them out. Is there perhaps some official guide (as in more technical), that specificaly covers what each compile tool does and how to get the most out of it? 

Look in Quake 1 Tooltips at the bottom of the page.:)

The tools are probably the best for the Quake engine generally, rather than Darkplaces specifically. The idea of doing a GTA style mod would work if you meant GTA1 or GTA2, but seeing as you're asking about a skybox I figure you had a greater vision ;)

Lordhavocs website has all of the details for his tools and engine, but it really is the compiling which would screw you up! You could do a fast-vis "vis.exe -level 1" release which wouldnt take so long as a full compile, but it's not a healthy way of doing things.

Or so they tell me... 

"You could do a fast-vis "vis.exe -level 1" release which wouldnt take so long as a full compile, but it's not a healthy way of doing things. "

Not sure what you mean here but it's definitely a good idea while working on the map. You don't want to eat 6 days every time you want to test the map. :) 

Generally during map development only fastvis is usefull... and then you can face really evil runtime on final fullvis if your vis blocking is crapy.... believe me :( 

You and me both :)

I have never released a final version with a fast-vis, it gives crappy performance :) 

The main problem is that fullvis runtime can vary in between minutes, and months !! And there's no possibility to predict what it will be before the first test... that is generally for me the last run :P 

Work with fastvis but do a fullvis a couple of times a week - so there's no nasty surprises later on. 

me to, at least once a week i made one 

That's really wierd, seeing as most people have like quad core CPU's and gigabytes of RAM, I'd imagine it would take at most a few hours. Then again, I do come from a general 3D background, where I'm used to seeing fully raytraced renderes scenes in minutes (sometimes hours). 

I'm with you there. I don't know how people are invoking levels that take weeks or months to VIS on modern day machines, but they claim they are. :) 

They could blame QuArK, but for some reason they are even defending it. 

I remembered with the Koho-vis test my computer ended upon 11 minutes, which I thought quiet fast.

The map I was making turned out on 87% after 5 days and it was there already 2 days.
I scratched the map because of 3 homs and started all over again.
Now making sure all polys were on integer grid.

The map turned out alright. And it still takes 6 houres, but that's understandable, having all on grid.

Still 2 homs prevent me from publishing it. 

It is not the tool you are using (i.e QuArK), in my case this is the size of the map (i.e 7915 brushes), and the way it is built.

If you are doing crap, you can have the best equipment, it will not help you :P 

if you have a map which has 8000 marksurfaces and r_speeds never go past 400 then it will vis in a few minutes.

If you have a map with 40'000+ marksurfaces and r_speeds rarely drop below 20'000 (at level 4) then it will take days. 

If you have a map with 40'000+ marksurfaces and r_speeds rarely drop below 20'000 (at level 4) then it will take days.

You are wrong: it can take a month !!! 

Around 30. 

that's still very very slow for something which todays machine should be able to compute in minutes. 

just a tought, huge Q3 map take much time to compile? 

that's still very very slow for something which todays machine should be able to compute in minutes.

I would say yes and no: the limitations come from the VIS algorithm itself that is a recursive algorithm, so with very huge and complex map that has tons of volume to inspect (VIS is based onto volume rendering) the runtime becomes very high...

Also, a big processor, not to say a multi core processor, does not help that much. First because most of VIS tool are not coded for multi-core processor, and also compared to what I have, it would only save 20% of the runtime best case I guess (i.e i have an AMD Athlon 2600+), and the bottleneck is not only the CPU only but the motherboard fequency and peripherals access (i.e to memory particularly)

Anyway, when a process run for thousand of hours (more than a month) you have to be patient, so 2 or 3 days less will not make the difference there IMHO... as I don't have any manager pressure to sort out my map ;) 

This is very interesting. We were just talking about the saturation of CPU speeds in my computer and graphics architectures class today, especialy things like how the cpu works with fetching instructions (particurarly in terms of arithmetic processing dependacy and parallelism). It would be cool if there is a way to make this whole VIS process faster , actualy the entire compilation process, without having to sacrifice detail in the 3D model of the level. But I guess that would require re-writting a lot of things from scratch.

My interpretation of this is that the build tools such as the BSP, CSG, VIS and RAD perform a lot of heavy computations, which require CPU level ALU's (arithmetic logic unit) to compute. Seeing as todays dedicated graphics cards hold a lot of processing power, especialy when it comes to floating point calculations, and fully programmable rendering pipelines, I'm guessing it would possible to re-write and optimize the code to work the GPU's, which I'm assuming would speed things up dramaticaly. But who would want todo all that work :)? 

The Old One. 

what makes the Q1 model files so irritating incompatible to handle...argh!

repeated message, i know but I almost learned Max3d manual on importing and exporting them.
They keep dragging on verticejumps and triangle catches.
Finally had my model boned and animated then it turned out rejected.

Starting from scratch won't mind, but manipulating excisting files can be a doughnut. 

I'm guessing it would possible to re-write and optimize the code to work the GPU's, which I'm assuming would speed things up dramaticaly.

Indeed, I know some application prefers to use GPU instead of the CPU, because of the ALU performances, but it needs to adapt the software to be adaptable to the GPU... though...

Anyway, Quake standard does not like big map. It has not been built for what we are asking today. The community is constantly asking for bigger / better / more detailed maps, even if the VIS tools have made impressive progresses (thanks aguirRe !), the overall runtime is suffering... but this sacrifice is worth supporting it, as it enables fabulous maps and projects...

I think I'll try to contact aguirRe to get his point of view about using GPU instead of CPU, maybe he would accrpt to try the porting... who knows ?