I've started my new sp project, and I made the first level, but when I compile it takes like 30.000 million hours before its compiled. I didn't even got it to compile. Anyone tell me, whats the fastest and best way to compile a *.map file to *.bsp ?
"Q3Map2: (single) BSP -meta" is the fastest way to compile (but it isnt compiling lights - the whole map will be lighten automaticly) and for fastest with light, then i prefer: "Q3Map2: (single test) -light -faster" good luck. and if you want to get the best result, then use some "Final"
Unless you are using P1 90 MHz for the job, an overly long compile time means there's something wrong with your map. The most common cause for new mappers is not using detail brushes, but leaving everything structural. Now, which brushes to turn into detail and which not is a lenghty issue and subject to many different opinions and disagreements, but generally speaking the finer details of detailing aren't as necessary as doing it at all is. The other factor might be the number of light entities and light emitting shaders. If you have showed no restraint with lighting, your compile can indeed take a long time. Especially if you are using a bounce with a large factor in your compile. Of course there are some unnamed mapping errors that simply make the compile take forever, but those are pretty rare. Still, new mappers are known to be the targets of all kinds of misbehaviors...
Newb question: What's the difference between a "detail" rush and "structural". I'd also like your opinion on "which brushes to turn detail and which not" (you said it's a lengthy issue, so a tut, or a short simple explanation will do). Thanks.
I have 2 misc_model s in the map, and when I compile it talks about FilterStructuralIntoThree and ClipSides blah blah, is there anyway to slow it down or can I use another compile program?
It's a DOS screen. Pause should pause it. Or you could press ctrl + c, since it prompts whether you want to terminate it or not. Did you use autoclipping with those models? Generally speaking most of brushes that don't touch void are to be turned into detail brushes. This includes all small details in your map, like brush based tables, columns along the walls (unless they are part of the wall touching void) etc. Only very large brush blocks should be left structural. Since structural brushes block vis, you should consider whether the brush could actually benefit the VIS process in an intelligent way. In simpler terms, when the player stands next to the brush, do you think the brush might block from his view singnificant portions of the map, thus saving some processor time when those portions are not drawn. A wall between two halves of a large hall could be a brush like this. Normally when you filter out detail brushes, entities and patch meshes, your map should look almost devoid of anything but empty boxes (when looked at the insides) of various forms connected to each other, with possibly occasional large brush blocks, if you have large halls with suitable architecture.