i don't know why, but overlapping brushes will cause zfighting in newer engines like q3 and d3. in quake, qbsp will manage to remove overlapping WORLD brushes without any issues. (overlapping func_ or other visible bmodels WILL cause zfighting with other bmodels or the world).
afaik, it doesn't cause any problems once the bsp is in the engine.

i'm not sure where we are atm concerning the compiling aspect of overlapping brushes. i don't overlap because i like to work clean, but it's just personal preference. 

OK thanks necros. You have an alarm going off when there's a new post? You seem to be on top of things :)

Is there anyone who can comment on the Detail/Structural question pls? 

Change brush groups into func_walls or func_illusionaries to avoid breaking up surfaces, or float them 1 pixel off the floor/wall. 

Overlapping brushes are ok, especially for weird off-angle arches and such. 

Anyone got any tips/tutorials/techniques for creating the best rocky/uneven terrain in Quake 1 bsp? :E 

Can anyone tell me what kind of triggers connections i have to do in order to make 4 buttons to trigger a door ? like if all are ON then the door should open .. if 1 is OFF the door shouldnt open (logical "AND" condition) i use the Quake 3 engine (GTK Radiant). Thanks in advance :) 

Create a Trigger_Counter (with a name of course :) )that activates at 4, and make it's target the door. Make each button target the counter, and make each button's reset time -1 so a single button can only be used once. 

OK thanks that explains why setting detail doesn't work in BSP or Radiant. I guess the option is in the editors for Quake2 and higher.

So when I got a cemetery full of fancy gravestones, I make the gravestones funk_walls or func_illusionaries. The downside of this seems that the func_walls/illusionaries don't cast shadows... I've read you can built a simple solid brush in them to cast shadows.. but I wonder if I can just copy the complex/detailed architecture, duplicate it and turn it into invisible brushes that will speed things up and DO cast shadows... For instance, here's a tutorial once from a guy who used a sky brush to cast a Quake logo shadow on the ground...but I can't duplicate it:
http://bspquakeeditor.com/q1tutor/q_lights.html 

IMO the best way to do terrain in Quake1 bsp is to use triangular prisms. I use ones with a depth of 64 units. You just lay the triangles out as a mesh, then move the corners up or down to make a nice uneven surface.

Also - ALWAYS overlap brushes in Quake1 maps. I used to think it was bad, but it turns out that its actually one way of making sure an area is sealed, for starters.

And you dont get in-game z-fighting. But if you get z-fighting in your editor, the newest brush will win. After you have compiled the map, any parts of a newer brush which were visible in your editor will be visible in the bsp. But they wont flicker. 

Does z-fighting actually happen (in advanced engines) into brushes that intersect each-other, without any coplanar face? Such as overlapping perpendicular walls as generated by some hollowing commands in some editors... 

Man I shouldn't post at 3 in the morning, didn't see you were referring to quake 3, so ignore me :E 

hmm, okay. Off to give it a go :)

As I understand it then the main limitation with quake 1 BSP is that if a square face is twisted across where the polygon seam would be it just breaks? Like 3D modelling if you couldn't flip edges...? 

I quote a recent post :

Can anyone tell me what kind of triggers connections i have to do in order to make 4 buttons to trigger a door ? like if all are ON then the door should open .. if 1 is OFF the door shouldnt open (logical "AND" condition) i use the Quake 3 engine (GTK Radiant). Thanks in advance :)

I want to do the same thing in Quake 1, but a little different. The door should open at a combination of opened and closed buttons - some sort of cippher :)

Can that be done ?

Let's say you have 4 buttons - all closed. You push one - it remains open until you push it again - same for all. The door should open only if button 1 is opened, button 2 is closed, 3 closed, 4 opened (an example). 

But without new code it's a bit fiddly to set up.

Basically, you have a hidden tunnel somewhere outside the map which has four doors in it, a shootable button and a nail shooter.

The player never goes into the tunnel - you're just using it to set up a logic gate.

The four doors are controlled by your four buttons, and they're all 'toggle' so that the buttons can turn them to on or off states.

The button inside the tunnel is shootable (health 1) and is behind all the doors.

The spike shooter is at the opposite end, and just shoots forever.

The idea is that if the doors are in the right places then they'll allow a nail to go from the spike shooter into the shootable button, which triggers your event.

Problem is, there's no real way to show when a button is on/off - which is a must for the game play not to be confusing and frustrating. 

Also - ALWAYS overlap brushes in Quake1 maps.

ignore this 

Problem is, there's no real way to show when a button is on/off - which is a must for the game play not to be confusing and frustrating.

How about creating a little "indicator light" above the button; a func_door with a fullbright texture, that appears/disappears from inside another brush to indicate state. You can build a nice frame/socket around it so it looks like some kind of light fixture or computer terminal. 

Ok seems silly but i just found the solution for my problem :D seems silly but it works :

for only 2 buttons to trigger the Door i did this:
2 func_button each of them triggers a shooter_plasma which shots to a door(1). that door(1) opens and behind it there is another door(2) that opens my Door(3) .. that way i can have my Door(2) opened when both doors (1 AND 2) are opened
(some images for better understanding http://img411.imageshack.us/img411/7038/multipletriggersand1.jpg http://img688.imageshack.us/img688/9168/multipletriggersand2.jpg )
is there an easier way ? 

Could you not just make the buttons only trigger once (wait value of -1 iirc) and a trigger_counter with a count value of 2? 

That'll do nicely. 

in gtk radiant 1.5 for quake 3 engine i tried trigger_counter but it doesn't work aand if i put wait the value -1 it will do exactly what the manaul sais : "wait : number of seconds button stays pressed (default 1, -1 = return immediately)." 

So I'm dabbling with the dark arts and trying to make some rotating stuff, and I've got a nice door opening and closing but it's insanely jittery, as though the axis of rotation is bouncing up and down... Any idea what I've done wrong? :E 

sounds like one of two things:

you did not target an info_rotate with your rotate_object

or

your compiler does not support rotating entities (very unlikely at it would have to be a compiler made before the hipnotic mission pack came out).

so make sure you add in an info_rotate that should be placed somewhere in the center of your rotating brushes.
next, add a 'targetname' to it.
now, for all the rotate_objects applicable, add a 'target' that points to that info_rotate. 

hrrmph. At the moment I have a func_rotate_door targeting a rotate_object. The object is rotating around the rotate_door. I can't find an info_rotate in my entities list :/ 

Duh, I think I've worked it out. The rotate_object has to target back at the rotate door. Duuuh... 

you will need to create an entry for info_rotate if you don't have it.

rotate_objects don't rotate around info_rotates.
info_rotates are used explicitly in the bsp process to define the origin of the rotater, otherwise the rotater's origin is simply '0 0 0'.

try this: make a rotating door right on the '0 0 0' origin of the world and it will work perfectly without an info_rotate.

it has to do with quake's angle accuracy (or lack, thereof). as you know, the farther from the center of a rotation you are, the bigger the gap between one degree to the next.
quake has a pretty low resolution when it comes to angles, so once a bmodel is far away from the origin, rotating it makes it 'snap' to the next angle.
targetting object_rotate to an info_rotate tells qbsp to move the bmodel onto the origin with the info_rotate as the center.