mitering corners - reduce visleafs? good for optimization?

[2d-chris]

This is what happens when people get it in their heads that BSP editing should be more like modeling in max I'm going to say it again but there are hundreds of more important optimizations to consider before fecking about with this.

Sure you could do this at the end if you want to make a tidy map in editor, but lets face it who is going to care once it's been compiled and turned into a horrible mess anyway?

Nodraw applied to every face not seen is anoyying, I used to do it but then the automatic vis groups messes up ;(

[KungFuSquirrel]

Sure you could do this at the end if you want to make a tidy map in editor, but lets face it who is going to care once it's been compiled and turned into a horrible mess anyway?

Keeping clean and tidy in the editor where possible is still useful, and after going back to the godawful mess that is the ns_eclipse .rmf file (which is technically "clean," but basically a giant solid block as a result of HL1-style brush sharing to reduce plane counts and all that silliness) and not recognizing a damn thing, I still recommend it. The way I built for HL1 maps was great for keeping things way under the limits, but is a nightmare and a waste of time to work with now, and kills any attempt to make a quick change, which is one of the most important things to be able to do in a level in development.

It's also really important to be as clean as possible in a team environment, which is why I dropped the habit of brush-sharing on Q4. If someone else gets onto the level and can't easily make out what you're doing, it's going to be a problem - likewise if you go onto someone else's map and are presented with a sloppy mess. I also once worked with a guy who would stack all his critical game entities in one vertical location, or on top of each other, so multiple lines would appear to converge on the same point and you couldn't tell what was what without deconstructing the whole pile. Infuriating!

But yeah, as it applies to mitering, you can of course build cleanly without doing it to everything. Only matters when you want to more quickly texture stuff or anywhere you can see the top of a corner/curve.

[dux]

I didn't have fun with your ns2 map btw andrew

[KungFuSquirrel]

Yeah, I didn't either.

[2d-chris]

Oh please retail levels for games are usually more messy than my ass after a strong curry ... for many reasons ;p Who gets time to convince their publisher that the game should be delayed because you want to make things tidy

I'm not against rules and keeping things organised, but in reality it's never as clean as you'd like.

Sorry kinda off topic I know ;]

[omega322]

I can give you the bottom line to this Topic, It does nothing.

In the above pic, When the compiler runs the vis leafs and comes to the corner, it sees the same thing, the compiler doesn't care what the shape of the block is, it only counts whats within the boarders of that block (Hence why when you compile and run around a map, if you no cliped outside the map, you don't see a hulking brush emitted from the wall.

BUT

Mitering your Corners does have one major Benefit. When your compiler compiles lighting, it bounces from the light source around itself to the nearby walls, it calculates which walls or faces are hit and saves the shadow/light data of each face.

So now, as seen above, when you don't Miter your corners, you end up with 3 separate faces being stored or "hit" by light, mitering however limits it to the two faces allowed! This may not seem like much, but, if you have a map with about.....125 corners (Which is really small TBH, you other Level designers can back me on that) that means your map is collecting light/shadow data on over 375 faces VS. Mitering, you'll only use 250. (Basically it will streamline your lighting/shadowing and make the overall file size smaller)

[Zeta]

I find this works well for interiors, each half of the wall being 8 units.

[Ginger Lord]

I always do this out of habit, but I also only ever create one brush in any map, the rest are all copy and pasted then edited to whatever I need, so if I need a mitred corner wall I copy and paste one I've already made. I also spend hours nodrawing hidden faces, ie inside a mitred join or flush with another face, which looking at Valve's maps and what other people have said I don't think is necessary? I've never heard a proper answer either way on that.

Same as I do, habits die hard.

[omega322]

I always do this out of habit, but I also only ever create one brush in any map, the rest are all copy and pasted then edited to whatever I need, so if I need a mitred corner wall I copy and paste one I've already made. I also spend hours nodrawing hidden faces, ie inside a mitered join or flush with another face, which looking at Valve's maps and what other people have said I don't think is necessary? I've never heard a proper answer either way on that.

Same as I do, habits die hard.

Faces touching in hammer are not rendered, so weather they have textures or nodraw doesn't matter. Like in a Mitered corner.

[Steppenwolf]

I always mitter my stuff when i work in bsp. Probably not as important anymore today since most PC's are powerfull enough to run even a messy map in source in highest details and fluid framerates. But it used to be very important in the past. Without mittering 2 triangles more get rendered per corner and if the wall is a static brush it creates a new tiny vis leaf. Now if you have a couple more such tiny vis leafs they will cut each other overproportianaly the more you have and you have very easily a mess of hundrets or thousands of vis leafs where only a couple dozen would be appropiate. This mess has a very negative effect on the vis compile time (what should take 2-3 minutes takes hours) and it also has a bad effect on the performance ingame.

edit:

Found this old pic in my archive:

Pretty much shows what i mean with tiny vis leafs cutting each other and creating a mess. On the button my map after proper mitering, func_detailing and vis optimizing.

[AlexM]

I always mitter my stuff when i work in bsp. Probably not as important anymore today since most PC's are powerfull enough to run even a messy map in source in highest details and fluid framerates. But it used to be very important in the past. Without mittering 2 triangles more get rendered per corner and if the wall is a static brush it creates a new tiny vis leaf. Now if you have a couple more such tiny vis leafs they will cut each other overproportianaly the more you have and you have very easily a mess of hundrets or thousands of vis leafs where only a couple dozen would be appropiate. This mess has a very negative effect on the vis compile time (what should take 2-3 minutes takes hours) and it also has a bad effect on the performance ingame.

edit:

Found this old pic in my archive:

Pretty much shows what i mean with tiny vis leafs cutting each other and creating a mess. On the button my map after proper mitering, func_detailing and vis optimizing.

nice example, I'm convinced

[Lord Ned]

To my knowledge: Mitering is a waste of time.

It only adds hours to development time.. Every time you want to change a wall? Either have to vertex it it, or streach it out and re-miter it via Clipping.

This compared to just stretching the brush.

There is no reason it would affect VISleafs as VBSP merges the faces... Presumably before it creates the leafs.

A mitered corner should be no different from an unmitered one after the face-merging.

In the example Steppenwolf posted: That's deceiving. I bet all of the visleaf reduction is caused by func_detailing, and hints/skips, etc. and not mitering.

Gonna go test my theory.

Well then. A few less portals, but less portals non the less. I'm surprised.

Still not worth the time/effort especially for anything but a final... Unless you're somehow really pressed for leafs.

[Steppenwolf]

In your example you have exactly 4 vis leafs more. Thats the number of extra faces non mittering causes. Now create some more of these rooms on different heights and not paralell to this one and see whats happening.

The only surprising part is where vis cut the leafs. But not really because it always was kinda random. And it gets more random the more complex the geometry gets. Even with hints/skip its sometimes a pain in the ass to properly control it.

edit:

Also keep in mind that the extra time you spent with mittered walls you get easily back on the vis compile time.

Whats true is that func_detailing plays the most important role in vis optimizing. From my experience a lot of level designers dont have the courage to do it properly but thats a different story and worth its own thread.

[Lord Ned]

You wanna know how many threads I've run across where "Compiling takes forever", and how many wrong statements I've seen people give about optimization?

I've heard that Nodraw gives you 95% of your optimization right off the bat...

I've heard that some map compiles can take up to several days. (Seriously what the fuck are you doing?)

I'd write a book on it but well.. Z@C beat us all, except no one bothers to read it when their map takes years to compile.

Also: If you can prove that mitering your corners from brush 1, and going along as you resize and such is faster than the compile times you'll spend, I'll miter my corners.

[Steppenwolf]

For vis its very simple to explain long compile times. The more vis leafs you have up goes the the compile time overproportional. So the difference between a quick compile time and a long compile time sometimes isnt even that big on paper. Just a question of proper optimizing.

Also you have to stop to be so pretentious about it when your test basicly proofed my point. Bsp merging the faces? Take a very very close look at your own example picture.