I really prefer subtractive mapping, I find it a huge timesaver. Consider the following scenario:

have 2 cube rooms with a single straight corridor connecting them.
Minimum amount of brushes for additive: 22
Minimum amount of brushes for subtractive: 3

Of course, there's no reason you cannot just carve out a big box and map additively inside it, just like you do with Quake style map editors. The only difference is you don't need to bother with sealing your map. 

maybe because i'm used to it (17 yrs. experience!), additive building doesn't bother me. But it seems like, when dealing with very detailed architecture and not cube rooms like in the example above, the advantages of subtractive are reduced. Instead of 22 brusehs vs. 3 brushes, it's more like 1022 brushes vs. 1003 brushes.

If you are additive building all the details in a room, and you produce what would have been a leak in an additive map, instead what you will get is a contained, unfilled void with a bunch of unneeded faces, between the back of the additive brushes and the edge of that room. So it's better but, better still is to fix the leak.

Or map with a modern engine where details are provided by meshes and polygons don't count as much as draw calls. Then quake's building technique is pretty obsolete. :) 

Well, I think it's a moot argument. 'Subtractive' maps in UDK were really just additive maps, except with a huge brush covering the entire world to begin with, which meant you wouldn't do that if streaming the maps together. So in making a map, you really just have both methods, and they work fine together. You just add brushes as you do in Quake, and can do subtraction because it's handled gracefully without excessive polygons being generated. Any you aren't limited to convex brushes. It would honestly be great if something like that could be handled in Quake, but I realize that would be a huge change to how maps are even handled in Quake to be done right. 

then there's the quake3 method where you build a caulk hull and then fill it will detail brushes. I guess that is closer to the unreal method? I remember that being a lot of work, though, tagging the back of every detail brush with nodraw shaders... a lot of tedious work. You're basically making one brush per poly at a certain point, or using flat 3x3 patches to mimic quads... i don't miss that. 

Edge extrusion looks like a nice method, then merge vertices with the same location.

http://youtu.be/IpQelCVPPZg?t=6m50s 

box modelling workflows are pretty good for mapping. 

for me meant working inside this sold block and generally meant carving out a lot of very boring shapes. There are some things in Unreal ED I would love to see for trenchbroom (2d shape builder yes please!!) but I find working with an open space is more creatively freeing than trying to carve out something interesting.
I made a lot of UT maps back in the day and it felt restrictive. 

that probuilder app looks awesome. 

http://www.celephais.net/board/view_thread.php?id=23978

Does any of you know where to get the tutorials that are mentioned in here? At most i can only find the one by Metlslime, after checking Quaddicted webarchive and other places

It would be nice too if we could revive that thread or make another similar ... 

http://web.archive.org/web/20050304015712/http://www.planetquake.com/polycount/cottages/rorshach/ 

How would you approach a huge, huge map, something like all original levels combined into one?

Is it possible? Does Q3BSP or BSP2 offer this? 

All original maps in 1 wouldn't actually be that big. 

... episode 1 maps joined together into a single map in normal bsp format, with the version of e1m6 that wasn't used too in there. If you use teleporters, i think it would be posssible to put the four together.

Ne_qep1 is its name, from the mod ne_dynamic, made by necros. 

Hi, i am experimenting with some hollow pipe bw,
and when it comes to light the scene, i get this:

http://www.quaketastic.com/files/screen_shots/hollow_odds.jpg

Tyrlight 0.14 with -soft 1 extra 4 set.
minlight value 10.

and thats one light only in this shot, value 300, delay 2.

Moving it around, and adding more light doesn�t change this significantly. Any clues anyone? 

can you take another screenshot with r_showtris 2? the face topology looks messed up. 

indeed, the faces are split in an unusual manner.

http://www.quaketastic.com/files/screen_shots/odd_tris.jpg

Though its on grid. TB screenshot:

http://www.quaketastic.com/files/screen_shots/ongrid.JPG 

i forgot to mention, i used an experimental build of txqbsp_xt, which has HL facesplitting algorithm implemented (and is incredibly fast).
Switching back to older version fixed it:) 

those faces are split ok. this is actually the way it usually ends up looking with any qbsp compiler. 

Except you don�t count my dumbness as one.

Those lighting oddities were caused by a abandoned .lit file with same filename.

Took me ages to figure that out(well, actually it was rebb who had that guess). Sorry for the disturbance, i go now standing in the corner for a while.

Sorry. 

 

 

Heh, I did this myself a couple of days ago, but caught it quick. Drag and drop from the build to project folder. 

sometimes it the simple things.
Man, i really got rebb to sweat on this, i can tell you!

Sorry rebb! 

Hi, can anyone point me in the direction of some literature that covers proper brushwork and bsp optimization?

In other words, I'm looking for ways to get the most (most being brushes, models, etc) out of bsp1.

I think max verts is around 65k, not sure about models and other things.

I'm thinking about converting a majority of the complex geometry into static meshes giving me more room for brushes. Is this a bad idea? What are the drawbacks?

Also, is there any way control how faces are split?

As I said, I just want to find the best way to maximize every little bit of space in bsp1, completely fill it to the brim in the most efficient, optimized way possible.

Any input would be greatly appreciated.

Thanks! 

I'm thinking about converting a majority of the complex geometry into static meshes giving me more room for brushes. Is this a bad idea? What are the drawbacks?
Sort of a bad idea. Static meshes in quake don't really blend in with the rest of the level the way they do in modern (or even semi modern) games. They also don't have any collision.
You can use .bsp files as models though. This is a better solution as you get proper collision and it will blend in with the map but the lighting will not match unless you light the bsp model in a way that matches the area in the map in which you're placing it. Also you can't rotate them without breaking collision (eg: if you rotate a bsp model, you loose collision)

Also, is there any way control how faces are split?
Nope.