Might be helpful to some for a better understanding why things sometimes take so long.

Courtesy of BJP:

OK, this is just my interpretation of how vis works, it may not be correct.

Apart from its normal bsp building from the map, qbsp also generates the portal (prt) file. This is done by dividing all the empty volumes (player space) in the map into smaller pieces, called vis leafs. The more complex solid architecture, the more leafs you get.

These leafs are just convex polyhedrons (like brushes) with at least four sides (the simplest pyramid). All the sides of the leafs are the vis portals ("doors between leafs"), but I'm not sure if the sides against the solids are also counted or it's just the sides between the leafs.

When calculating visibility, all these leafs have to be checked against each other to determine which ones that are visible from a certain leaf through all of its portals. It's assumed that the player can be in any of the leafs (no matter how small they are) and look in any direction.

To make things worse, visibility is checked twice for each portal, one in each direction (back and forth). I don't know why this is.

It should be noted that this "leaf visibility" calculation is a simplified variant of the more realistic point-to-point visibility, which would probably take even longer time since the position granularity is higher. The leaf visibility method also increases engine overdraw, i.e. it'll have to render stuff even if it's actually occluded, thereby increasing r_speeds.

Since all leafs have to be checked against each other, this is a variant of [at least] an "n x n" (n being # portals) problem, which will scale very badly as n grows. This is the main reason why more complex maps take so extremely long to fullvis.

In fastvis, vis first makes some simple analysis and determines which leafs that can be trivially rejected as being invisible and all others are marked as "potentially visible", i.e. need more calculations using fullvis. If you just run a fastvis, all the potentially visible leafs will be rendered by the engine as visible, slowing things down. When building a map to be fullvis-time-effective, it's probably vital that fastvis can trivially reject as much as possible.

In fullvis, vis goes on to the significantly more complex algorithm, where it "flows" through all the potentially visible paths, checking if there's a way through. This work is divided so the simpler paths are calculated first, since they will probably be used in the more convoluted paths later. This is the main reason why vis slows down so much while running, it has left all the heavy parts for later.

The division also lets vis manage the multithreaded aspect by having several threads doing different paths (but still the simpler ones first). I can't say though if it's guaranteed that all simpler paths have been done by all threads when the more complex ones are about to begin. In my version (and most others), that's a non-issue, since the paths are all done sequentially by one thread in the right order.

With increasing # leafs and portals (which you can read at the beginning of the prt file), you can probably realize that the amount of calculations grows very quickly. 100 portals will generate 40,000 "work items", for 1,000 portals it'll be 4,000,000, 10,000 portals is 400,000,000 and so on. I don't want to think about 100,000 portals ... 

Hi thanks for the answers.
Ricky, here are the screenshots and compile logs.
http://rapidshare.com/files/302918736/quake_screenshots.zip

With light.exe -dist 0.6 -range 0.6 -light 15 -soft it's like no rad / fullbright.

But I didnt' know that you can configure the light.exe thanks for that info MadDog. Maybe someone know how to set my light settings right.If not, i will put some more light enities and a higher brightness value in my maps. This will work i think...

The lighting in the compiled originals quake maps have irritated me. 

Well I need that actual light entity information, you have sent me the information for somebrushes with a light texture on them.
The light entities will be at the bottom of the document (the .map file that is) and will look like:

{
"classname" "light"
"light" "200"
}

As for the command line options well I would use (for a map the size you have) -extra4 and nothing else.

But yeah you can use a "wait" key in your entities to make the light spread out further or be more concentrated.

A wait of >1 will make the light more concentrated, i.e.

{
"classname" "light"
"light" "400"
"wait" "2.5"
"origin" "blah, blah, blah"
}

And a wait of <1 will make it go further, i.e.

{
"classname" "light"
"light" "200"
"wait" "0.3"
"origin" "blah, blah, blah"
}

You can also use "delay", but Im no expert on that one. I seem to remember delay of 2 being nice effect. 

That's a door that's fullblack? If it a door or other entity (func_wall or whatever) then it fullblack because the origin is outside of the world.

This means that it doesn't start inside the vis'd (lit) space.

Select it, the red X in the centre is the origin - if that's outside of the lit space (inside a wall, like yours seems to be) then the whole thing won't be lit at all. So make a recess for it to fit into or make it smaller so the origin is inside the world.

It's worth remembering that although entities look like they're normally brushwork in many ways they behave like point entities.

In other words, they only care about where their origin is when it comes to light and vis. 

Those were missing from the above post.

Also 'brush entities' as opposed to 'entities'.

Having a baby is the greatest thing in the world, but your head is all over the place for lack of sleep. 

Its an optimisation (AFAIK) of AguirRe's that the compilers don't light all brush entities no matter where they are, like id's did.

Definately a plus, but also shows another b0rky map feature common in the originals.

Mind you, very easy to be aloof ten years+ after the fact. 

Thanks for the help! The last post is what i wanted to know. I found it weird that the original quake maps had different lighting when starting in Worldcraft. Thought it was a problem in my Worldcraft configuration or something.But that explains it all.

And i am not sure if you notice that the in_game_screenshot.JPG was a screenshot of the original E1M1.bsp not mine small testing maps.

Anyway Big thanks! 

That's why I said that AguirRe (who's compilers come bundled with the wc3.3 adapter) made optimisations that id didn't.

If you used their compilers it'd work without showing the door black but take alot longer. and run very slightly slower in game I think as well. 

you lucky father and happy mother.

apparently the same goes for a good map:
Having a map is the greatest thing in the world, but your head is all over the place for lack of exit. 

silver_key-gold_key-exit.

change-feed-sleep.

Now that's a nerd comparison. 

PakExplorer: 'explorer' type view, limited to 8 character filenames. sucks.

PakScape: 'explorer' type view, not limited to 8 character filenames. converts all upper case chars to lower case and progs.dat is case sensitive. sucks.

DZip: not limited to 8 chars. doesn't change char case from upper to lower. is NOT an 'explorer' type view, just a long list of crap so very difficult to organize pak files. (as it's primarily for zipping demos anyway).
sucks.

are there any other pak file programs? one that doesn't limit file chars to 8 or change the case around and that has a proper way of displaying files so as to be able to organize things well? 

That is one thing QuArK can do very well. 

there is a pak plug-in for total commander. It satisfies my needs for exploring pak files. 

i was under the impression that both of those could only open and extract files from paks? 

Nope, QuArK let's you save just fine. 

I have just tested and the tc plugin is creating pak's as well. Very straightforward 

Pakker 

thanks :) i wasn't able to check myself today.
wasn't able to find pakker though, but i should be able to use quark as i've already got that. 

http://www.gamers.org/pub/idgames2/utils/bsp_pak_tools/pakker10.zip 

so, i made a few pathetic textures and im trying to get texmex to put them in a wad, like i did once before i think, but now when ever i try to import it gives me "was ignored" on all the textures

the textures are in .bmp format and i believe they are 8 bit color

...i don't get it any clues? 

i remember that happening, and don't really recall why it did, but i'm pretty sure if you convert your bitmaps into 24bit targas, the problem should go away.

it might have to do with the 8bit bitmaps not having the correct palette (it's not enough for it to be 256 colours, it has to be the correct 256 colours). 

Are the bitmaps compressed? That might be it. 

Your texture, then 'paste image as new mip' in TexMex. 

those both worked :D

... i don't know how to compress bitmaps so i dont think i can decompress them :S 

I'm working on a terrain map. I use triangle shapes to lift the corners to equal heights and then use force to grid 1 to fit the brush.

Sometimes the brush takes the grid on a counter line and it is possible to move the brush back into its original position, gaining a clean, converted brush.

Othertimes it gets out of grid and causes the vieuw to get out of position.
http://members.home.nl/gimli/align.jpg

The first method , without forcing to grid, brings a well compiled map with errors, caused by the compiler with warnings and heling points. But a fitting brush order.

The second , with force to grid and reposition, brings a misaligned map with less errors and a better compile log, and a rather blurry brush fit.

How to avoid the process and which would be best suitable?
I never minded thes misalignements, I'm already glad the compiler takes it. But then again, the small difference could change vistime considerably.