1. When you were building your walls you used your pre made modules. Would it not have been better to make the walls to size instead of using a series of modules? I would think there would be a performance drag using so many individual modules (especially in larger maps).
Ah, good question! I should have talked more about it in the video.
Here I had a simple walls without any features and I still used the modules. It is true that I could have gotten exactly the same result by simply making the walls the traditional way by dragging new brushes between the window/door modules. Sure, using the modules will result in little bit more tris than using the traditional way, but the small extra amount of tris is so little, it does not matter.
But imagine if I had spent more time in the module building and made some really fancy looking wall modules. Now I would immediately benefit from the modular approach over the traditional way, because making a single high detail module and cloning it around gets me more details very quickly rather than building each detailed wall section the traditional way. Also the modules give be these benefits: 1) I can control each modules piece shadow casting (a performance improvement tool) and 2) it is very quick to re-arrange stuff with the models (if I build the traditional way, I cannot just reshuffle geometry pieces to get the resut I want.) If the modules were of very high detail, I could also make each module to have LOD detail models (but that's a lot of work). Oh, and also, the wall modules had already textures that were perfectly aligned with all the other modules (I used the FIT operation in the surface inspector). If I would build the traditional way, I would be facing the extra work of aligning every single wall piece textures by hand (lots of boring work).
2. I know you wrote in your previous reply that there was no incentive to avoid overlapping your modules. Is that solely because they are "func_static"?
Yes, the engine treats func_statics differently than worldspawn. Someone more proficient with the engine, may correct me, but I think that dmap does not optimize func_statics in any way. This way they can have any kind of weird arrangement of brushes and the engine will just treat it as a model. Worldspawn gets optimized during dmap. This may result is unexpected results if you have made weird brushwork. Thus, IMHO, worldspawn should be just used for simple geometry of sealing brushes (and floors.) Everything else is good to be func_statics. This makes the work less error-prone.
The floors must be worldspawn so that the AI can walk on it. The AI does not see or feel func_statics! The AAS nagivation mesh will be applied on worldspawn.
When talking about func_statics, I must remind that the AI does not 0see of feel it. All func_statics must be monsterclipped. This will have it's own part in the mapping blog later.
3. Also, you mentioned that if you were using "worldspawn brushes", you would be more careful, is that the reason you are making your structures from "func_static"?
Yes. The engine treats func_static and worldspawn differently. The main benefit is that the func_statics are grouped (they are quick and easy to clone around), and I can control the shadows of each individual module, and the func_static can be anything and the dmap will not try to optimize/change it. I always try to build so that floors, monsterclip and sealing walls are worldspawn. Everything else if func_static. It makes life so much easier.