InsideQC Forums

Is there any documentation that goes into detail on the .map build process, other than the source to the tools (I already searched google)? More specifically, what treeqbsp, light, and vis do when they are running. I made a small two room map and it took vis (bjptools for linux) eleven hours to... do whatever it does. It would be nice to know what is happening during the stages of the .map building process.

Wow, could you share that .map file?

My stupid understanding:

BSP creates triangular faces, the mesh the whole map consists of.

LIGHT creates the lightmap.

VIS calculates what faces can be seen from which portals (polyhedrons that are formed by the faces, darkplaces r_showportals 1).

qbsp builds a basic bsp. This is the stage that reads the wad and map.
light generate the lightmaps for your map. Without this it'll be fullbright.
vis generates the visibility information (the pvs) so that you don't have to redraw the entire world unconditionally.

vis and light utils can and generally should be threaded. Their output quality can also vary without significantly affecting play (useful for development). When vising for development you should use -fast.

with vis, its not the size of your map that increases times, its the complexity. Lots of tiny details = greater complexity = exponentially longer. Back in the day it was not entirely unexpected to see vis times of 4 days. Quite a few maps were released with only fast vis.

Thanks for the info, Spirit and Spike. I also remembered to check the quake wiki at quakedev about 5 minutes after posting my original post.

Spirit: the map can be found at http://omploader.org/vNWJlZg.

That is a spiral stair case of doom. Try to stay on a bigger grid, do not use some rotate function in your editor but place clean brushes manually. Also the big open space around it makes it worse.

Spirit wrote:That is a spiral stair case of doom. Try to stay on a bigger grid, do not use some rotate function in your editor but place clean brushes manually. Also the big open space around it makes it worse.

I figured it was something I did. I used grid64 for most things, but in the case of the starcase I used grid16 (iirc) so the stairs would be thin enough to walk up (ironically, you have to jump on the first stair).

Hm, that should be fine. I only took a quick look and assumed you had rotated one shape off grid. I guess it is the big empty space then. Still hardcore.

Indeed, spiral staircases are evil, they crate a shitload of portals. Especially if they are done sloppily like here. Still, 11 hours sounds extreme, old computer? Make the thing a func_wall and vis will run like a breeze.

negke wrote:Indeed, spiral staircases are evil, they crate a shitload of portals. Especially if they are done sloppily like here. Still, 11 hours sounds extreme, old computer? Make the thing a func_wall and vis will run like a breeze.

It's a pretty old laptop, about eight years old, 2.2ghz pentium pro.

still has a higher clockspeed than my laptop which is only a year old...

Spike wrote:still has a higher clockspeed than my laptop which is only a year old...

LOL. My 2002 desktop is 2.0 Ghz and I am left wondering what has happened to the world when my relatively ancient Win XP SP1 machine blows away Vista/Win 7 machines and why the clock speed hasn't advanced much over the years.

And most software isn't designed to take much advantage of multiple cores.

Or why a Visual Studio .NET compiled exe is a big phatty 1.3 MB when it is 500 Kb in Visual Studio 6.0. Or even why Visual Studio .NET freebie version is 1 GB download.

The world is strange I have my thoughts. Old skool is where it is at! New school is DRM, sloth machines, phatty builds, style over substance.

Oh well ...

pentium 4s with their 3.8ghz clocks suck, what can I say? :P
instructions per second are more useful than clock speeds (especially when those clocks are used waiting for ram!).

I wouldn't worry too much about big executables - anyone who frets over 1.3MB vs 500KB mustn't have any real problems in their life I say - but the underuse of multicore capabilities in the majority of apps is an unfortunate but inevitable consequence of the fact that current multithread APIs are crap.

I predict that whichever OS wins the next round of the war will be the one that gets a really good multithread API first (i.e. one usable by mere mortals without having to worry about arcane terminology, deadlocks, race conditions, etc).

Of course Intel or AMD could surprise us nicely by coming up with a CPU architecture that distributes workload among multiple cores automatically for you, but I wouldn't hold my breath for it.

mh wrote:I predict that whichever OS wins the next round of the war will be the one that gets a really good multithread API first (i.e. one usable by mere mortals without having to worry about arcane terminology, deadlocks, race conditions, etc).

Of course Intel or AMD could surprise us nicely by coming up with a CPU architecture that distributes workload among multiple cores automatically for you, but I wouldn't hold my breath for it.

Well, I'm not claiming to have answers.

But I do have questions ...

mh wrote:I predict that whichever OS wins the next round of the war will be the one that gets a really good multithread API first (i.e. one usable by mere mortals without having to worry about arcane terminology, deadlocks, race conditions, etc).

OSX 10.6 has an API called "Grand Central Dispatch" which looks pretty nice, at least for some classes of parallelism. They also added "blocks" (closures) to Objective-C to make this a more inherent part of the language.