overlapping func_wall
Post Reply
Quote
Re: overlapping func_wall
Posted by Tracer Bullet on Sun Dec 14th at 7:16am 2003


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? [addsig]



Quote
Re: overlapping func_wall
Posted by wil5on on Sun Dec 14th at 7:21am 2003


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.





Quote
Re: overlapping func_wall
Posted by Cash Car Star on Sun Dec 14th at 7:55am 2003


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.)



Quote
Re: overlapping func_wall
Posted by Orpheus on Sun Dec 14th at 8:39am 2003


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.

[addsig]




Quote
Re: overlapping func_wall
Posted by Dr Brasso on Sun Dec 14th at 2:59pm 2003


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"....

Doc Brass...

[addsig]




Quote
Re: overlapping func_wall
Posted by ReNo on Sun Dec 14th at 3:12pm 2003


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

PS. Should I detail this further in a tutorial?

[addsig]




Quote
Re: overlapping func_wall
Posted by Orpheus on Sun Dec 14th at 3:16pm 2003


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.

[addsig]




Quote
Re: overlapping func_wall
Posted by Tracer Bullet on Sun Dec 14th at 6:01pm 2003


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.

[addsig]




Quote
Re: overlapping func_wall
Posted by Campaignjunkie on Sun Dec 14th at 6:40pm 2003


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"

[addsig]




Quote
Re: overlapping func_wall
Posted by fizscy46 on Sun Dec 14th at 6:44pm 2003


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.

[addsig]




Quote
Re: overlapping func_wall
Posted by Tracer Bullet on Sun Dec 14th at 8:04pm 2003


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. [addsig]



Quote
Re: overlapping func_wall
Posted by Jinx on Mon Dec 15th at 12:16am 2003


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.)





Quote
Re: overlapping func_wall
Posted by ReNo on Mon Dec 15th at 1:52pm 2003


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.

[addsig]





Post Reply