overlapping func_wall

I'm fully aware that overlapping world brushes are the ultimate lazy noob error, but are there similar negative ramifications to overlapping func_wall ents?

An entity brush overlapping a world brush is not neccessarily a problem. Ive never had a problem with it anyway...

Ideally, no brushes should intersect. However, if it is unavoidable, its a good idea to make one of those brushes a func_wall.

The way I believe it works is that each entity (worldspawn being a whole entity) has it's own branch of the bsp from which cuts into the brushes are made. Therefore, one func_wall into a seperate func_wall would be the same as a func_wall into a worldbrush. One brush inside a func_wall into another brush inside the same func_wall will cause facesplitting. (I'm assuming you're asking about facesplitting, since there's not many other major negatives other than how clean you want the map to be.)

i just have to ask, if one knows its overlapping, why not fix it?

i mean really, all unknown overlaps are unavoidable, even i find a few i have made accidentally, usually after i have released, so its too late to fix it.

but really, isn't this a redundant or rhetorical question? since knowing its overlapped, shouldn't you fix it in favor of either proper mapping technique, or at the very least to prevent the outside chance it could cause issues?

personally, the perfectionist in me, won't let me knowingly leave a defect in my map.

sadly, few others share my passion.

i say, if you know its overlapped, fix it.

as to the question at hand, it is my understanding, that any unseen overlaps are clipped out during compiling.

well, correct me if im wrong, but not only does it increase compile time exponentialy, especially id its in a seen or accesable area....if the geometry is really complex, it can stop or freeze the whole process...yer forcing the compile tools to calculate the same mass multiple times.....eh? seems that was one of the first rules pounded into my head by one of the ...ahem...."alum".... :heee:

Doc Brass... :dodgy:

There are scenarios where letting brushes overlap can save a lot of hassle and even faces. For example, imagine you have some really simplistic triangle terrain, and put a 10-sided cylindrical object sort of "dug in" to the ground. Now if the terrain is really simple the entire cylindrical object sits inside the bounds of only one triangle. to make the objects NOT overalap would require you to either...

1. Clip the base of the cylinder to meet the gradient of the terrain. In the case of the terrain sloping over two axis, could be tricky, and if the gradient doesn't line up exactly you could get some dodgy light artifacts around the base OR satchels / snarks could fit under the object.

2. Manipulate the terrain to meet all 10 sides of the object. Doing this would mean your single triangle that previously made up that part of terrain would be split into around 10 triangles, wasting loads of faces.

If however, you just let the object overlap the terrain and turn it into a func_wall, then none of the disadvantages of the two above solutions will rear their ugly heads :smile:

PS. Should I detail this further in a tutorial?

Duncan, you are suggesting the exception, i think TB was asking about the rule.

i can see advantages like you say, but as a rule, no solid should overlap, if the only reason was laziness i mean.

yeah, i overlap water onto solids in every map, its far better than piecing them together around things.

Actualy, I am in pretty much exatcly the situation which ReNo describes. in my dod map I am trying to model debries with triangle terrain, but I would like to imbed some bricks and bits concrete to increase realism, but as reno suggests, it would require some pretty laborious work and many extra faces to fit them into the terrain neatly.

I guess this is the question I should have asked to begin with. I'm still not sure though, because in the case of making debries, I'm going to have to put probably 30-40 of these in the map, which makes me very nervous. I normaly don't overlap anything; not even water.

Overlapping is sometimes encouraged and better than fitting things in. Water, for example, is okay if it overlaps. Complex water brushes (as a result of people trying to have it perfect and fit in) will often go haywire and screw up. But sometimes fitting things in is also advised, as it makes your map easier to see/interpret in the grid.

Ever play Someplace Else? All of the cave brushes (where you begin the map) overlap into each other. I guess WhoMe just let CSG and BSP do the work for him, and it still turned out great (r_speeds fairly low in the caves). Sometimes you can be sloppy and sometimes you can't.

In your case, though, I think overlapping would be best. Just func_wall the bricks and such like you suggested. One of the important aspects of mapping is to be flexible and... "creative" :dorky:

Despite said otherwise, overlapping world brushes generally won't do anything. You won't ever see thos intersecting brushes, so it effects nothing.

So long as the textures don't double over, go ahead and overlap. Th main game did that all the time, even in the dam level.

I guess I will go for the overlap then. I'll post again here if I encounter any problems with it so that it will be in the search database.

I overlap func_walls into world brushes all the time. It makes certain things a lot simpler and never hurts anything unless the edge of a func_wall gets outside and 'leaks'. I usually try to avoid world brushes overlapping; usually you can easily make one of them a func_wall anyway, so...

little trick if you don't know it. know how sometimes a sign on a wall (thin brush against another brush) will flicker in the distance? it's a rendering bug with the z-buffer i think.. anyway, if you make that sign etc. a func_wall, then extend it back into the brush behind it a bit, it will fix that bug. very useful sometimes. (making it a func_wall just avoids face-splitting etc.)

Jinx, you should read the thread on leaks up on the forum at the moment, we are discussing entities hitting the void and when they do / do no cause leaks.

Fizscy, how do you know they did that in single player HL? If you are basing that on looking at the decompiled maps, its not an accurate portrayal of how they were built. The decompile tools are not perfect, they don't give "out" the exact source that the mapper put "in". In fact, decompiling maps generally gives out a load of s**t, and its only recommended for looking how particular entity effects and whatnot were achieved. Of course I'm just guessing thats why you think they did it, perhaps you have a different source.

But it is generally accepted that overlapping world brushes is a bad move, and overlapping entity brushes is a bad idea - overlapping one type into the other however is normally seen as fine. All I know is that I used to overlap brushes when I began mapping and despite the simplicity of my maps, the compile times were huge, so I suggest you avoid it where possible.