.map build process
-
- Posts: 268
- Joined: Tue Nov 24, 2009 2:20 am
- Contact:
.map build process
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.
Get off my lawn!Ken Thompson wrote:One of my most productive days was throwing away 1000 lines of code.
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).
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).
Improve Quaddicted, send me a pull request: https://github.com/SpiritQuaddicted/Quaddicted-reviews
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.
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.
-
- Posts: 268
- Joined: Tue Nov 24, 2009 2:20 am
- Contact:
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.
Spirit: the map can be found at http://omploader.org/vNWJlZg.
Get off my lawn!Ken Thompson wrote:One of my most productive days was throwing away 1000 lines of code.
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.
Improve Quaddicted, send me a pull request: https://github.com/SpiritQuaddicted/Quaddicted-reviews
-
- Posts: 268
- Joined: Tue Nov 24, 2009 2:20 am
- Contact:
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).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.
Get off my lawn!Ken Thompson wrote:One of my most productive days was throwing away 1000 lines of code.
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.
Improve Quaddicted, send me a pull request: https://github.com/SpiritQuaddicted/Quaddicted-reviews
-
- Posts: 268
- Joined: Tue Nov 24, 2009 2:20 am
- Contact:
It's a pretty old laptop, about eight years old, 2.2ghz pentium pro.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.
Get off my lawn!Ken Thompson wrote:One of my most productive days was throwing away 1000 lines of code.
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.Spike wrote:still has a higher clockspeed than my laptop which is only a year old...
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 ...
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
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.
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.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
Well, I'm not claiming to have answers.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.
But I do have questions ...
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
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.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).