metlslime explanation is quite clear, and well depicted: vis process is a recursive algorithm. checking the code you can easily see it... However the stop condition is pretty unclear to me, still today.
It explains why it is exponentially runtime consuming regarding the map geometry... the more portals/volume you have the worst the runtime will be. The only way to improve it is "donuts" vis blocking, and map occlusion, in order to cut the map into pieces, and limit the number of branches in the recursive tree... though...
I don't whether it would be possible to rework the Quake engine to make it working with 3D GFX in order to let it in charge of the map rendering.. As far as I understood, today the Quake engines are software rendering only.. or am I wrong ? Please correct me if so..

PS: Please read me correctly, I don't want to port Quake up to nowadays engine level complexity... The fun with Quake is that it is easy to map for. Being able to build beautiful maps with lot of limitations inherited from the game engine makes the fun, else if it would have been possible since the very beginning to do giant wide open map, I think it would have been that fun... my 2 cents ;) 

...I think it would NOT have been that fun.... 

yes yes 

Shambler, i don't even understand half of what they're talking about myself, and look how many maps I made. it's no wonder they were all so small. 

Really I don't understand why it has not been done for Q1 yet, DETAIL BRUSHES!

All these crazy VIS times would just go away as the compiler would work with simple shapes again. Lets face it, all of the latest Q1 engines everyone uses are so far away from the original Q1 spec, why not just add a special new detail brush switch? So people can go nuts and create crazy angled stuff.

@Trinca, terrible comment. >:( 

sock I had worse comments on some of my maps and i didn�t deserved or died... 

"Shambler, i don't even understand half of what they're talking about myself, and look how many maps I made. it's no wonder they were all so small."

Well, that was part of the beauty of Quake. You didn't HAVE to know any of that stuff to produce a map. As long as you had a copy of VIS.EXE, you were good to go. :)

"All these crazy VIS times would just go away as the compiler would work with simple shapes again. Lets face it, all of the latest Q1 engines everyone uses are so far away from the original Q1 spec, why not just add a special new detail brush switch? So people can go nuts and create crazy angled stuff. "

It's not the engines that need to support that, it's the tools. I tried to add detail brushes to QBSP but that code is, quite honestly, a god damned nightmare. It's a horrid mess and I wasn't able to figure out what to do to make it work fully. 

I wasn't able to figure out what to do to make it work fully

I believe the solution involves a large mallet... 

Would be like mapper crystal meth. 

@Willem, the source code for the Q3 compiler tools is publicly available, can't it help with the detail brush problem with the Q1 tools?

I still think the engine will need some changes, the AI will certainly need to know about the detail brushes, with maybe some monster clip so they have a simple brush hull as well.

I know Q1 mappers want to create crazy angle stuff but waiting 700hrs for a compile to finish is just barking mad! :P 

But, detail brushes have been done in Quake. Firstly, the Quest compilers have them. They would feel incredibly primitive compared to aguire's tools however.

http://quest-ed.sourceforge.net/

If you have a PowerPC Mac (hah!), then there's a port of said tools with some added features:

http://quake.chaoticbox.com/downloads/equakeutils.sit
http://www.quaketastic.com/upload/files/tools/mac/misc/eUtils_r10.zip (same tools, just more compatible compression)

I'm guessing that Willem was looking at the source of one of these?

Finally, here's a fascinating possibility I found, from the q3map2 readme:

2.5.4 (2003-04-01)

- New: support for Quake 1, Quake 2, Half-Life, Unreal, and UT2K3.
On BSP/-light/-vis, use the -game argument: -quake1 -quake2 -hl -unreal -ut2k3

I have not tested this, and I don't know what it actually means, but there it is, q1 support in q3map2. If it could actually output q1 bsp format, and not just take it as input, then that would almost certainly be the best solution for cutting compile times. 

estimate jumped up to 260h last night so i canceled again.

going to try something else now. i've selected clumps of terrain that are roughly the same height and i chopped all the tops of them off and turned them into func_walls.

this should hopefully preserve shadows a bit but will make the terrain have common planes instead of all different slopes.

if this isn't enough, i'll do the same for all the ground terrain which will be probably 10x more work but should yield good results. it also won't really affect shadows as it's the floor. 

At which percentage did it jump up? Just asking because VIS tend to get slower the further it progresses.

Autist optimization tip: load the prt file with Gtkradiant's prtview plugin and arrange the brushes/portals orderly. 

I think, since the main issue is vis times, the best approach is making changes to the vis process in ways which result in a backwards-compatible bsp file. Rather than making a new bsp format. 

Screenshots:
http://h.imagehost.org/0820/MirageDetail1.jpg
http://h.imagehost.org/0386/MirageDetail2.jpg
http://h.imagehost.org/0679/MiageDetail3.jpg
http://h.imagehost.org/0580/MirageDetail4.jpg

DOWNLOAD!
http://www.mediafire.com/file/qmgnjmemjqz/2p_mirage.zip


To play the map, follow these installation instructions:

Download the Zip file.

Extract the contained 2p_mirage.sga file to:
C:\Program Files\Steam\steamapps\common\dawn of war 2\GameAssets\Mods\

Make a new shortcut to play Dawn of War 2 (in steam, right click on DoW2 and go to 'Desktop Shortcut')

Go to the properties of the shortcut and add
-mod 2p_mirage
to the end of Target section.

Play the game with this shortcut and you will see the map in the drop down list when creating a game.

A few notes:
Base areas are not detailed yet, I'm lazy.
Much of the surrounding terrain isn't detailed yet either.
Haven't done an optimization pass or a fully baked lighting pass yet, which may increase the framerate of the map, but shouldn't really matter much since it's not that bad at the moment anyway (that I've noticed!)
Minimap needs some work.

Not sure how many radical changes I'd be willing to make, but it'll likely be few. Most of the time I hope to spend between now and the Sunday night deadline is cleaning up major issues, finishing up detail work, and baking lighting. 

State 'no sharing this outside of relic' or similar? 

The rule was clarified to be "Any map published and shared previous to the annoucement of this contest isn't allowed".

They fully expected and wanted people to have their maps tested. What they didn't want was anyone taking an already finished map previous to the contest and entering it. 

 

@scampie, The screenshots look really cool with all the plants and cliff sections but I have to confess not having played the game (DOW) I have no clue what stuff in those screenshots are your creation. Which nicely brings me to a nice tangent or 'shoe on the other foot' situation.

I recently posted screenshots of map stuff on an art portal/site, they branded me a cheat for posting stuff which they thought belonged to others and cast me out. Fair enough I suppose because they did not understand or could not work out easily from my screenshots what was my stuff. It is certainly strange seeing this situation from their perspective with your DOW screenshots. 

that razor sharp waterline hurts my eyes but I guess there's nothing you can do about it? never played dow. 

http://zfight.com/misc/images/maps/m8/m8_12.jpg 

Looks nice ! 

 

http://www.simonoc.com/images/design/maps_q3/moteof1bw1l.jpg
http://www.simonoc.com/images/design/maps_q3/moteof1bw2l.jpg

Not totally finished with them, need more detail ... 

I want those textures.