mitering corners - reduce visleafs? good for optimization?

the debate rages on...

I really dont know which way is best but I hadn't heard before that mitering your corners causes t-junctions to go up, if that's the case I'll make a point to miter less often. T-junction issues are brutal.

copy pasting URLs is a tough job...

i find it funny how you ask designers about engine programming questions. nevertheless, i can see little benefit from mitering corners unless they are crucial to your level architecture. the way that the bsp tree data structure handles the visibility data, there'd be no technical difference - bsp removes all outside of world faces, and each visleaf will still store the same amount of data for each inside world face.

You'd be better off building a level with performance in mind from the start before doing really minor changes like this. If your level is designed poorly no amount of minor fixes will save the day. Do Valve do it? There is your answer ;]

From a workflow perspective it's a bad idea, everything takes longer to edit.

Sentura - don't underestimate the amount of technical knowledge a good level designer will have, we work very close with all departments

Miter corners are good for optimization if they are "inside corners", since you save one "face" on each corner when comparing with a "regular corner" (see pic). It also, in some cases, causes less splitting of the floor, ceiling and adjacent brushes, and they're easier to texture (again because you only have two faces to texture instead of 3).

For outside corners, it doesn't really make a big difference since the compile tools ignore the outside faces, but many people (including myself) still use them because it makes the brush look cleaner, but it's just a matter of personal taste.

[Blocked Image: http://img9.imageshack.us/img9/5954/corners.png]

And i disagree with 2d-Chris, it doesn't take longer to edit miter corners. Instead of for example using the selection tool to resize or rotate the brushes you use the vertex tool, and texturing is much easier like i mentioned before. You just have to use the right tool for the job

in regards to the t-junction issue, I'm thinking about it in my head, wouldnt a non-mitered corner yeild a t-junction and a mitered corner not yeild one?

I do this with everthing I make, but I'm completely with Chris on the longer workflow bit. More recently I try to save it as a final step, otherwise I'll have to re-edit the vertices after any extrusions, which gets annoying.

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.

Quote from barrakid

Miter corners are good for optimization if they are "inside corners", since you save one "face" on each corner when comparing with a "regular corner" (see pic). It also, in some cases, causes less splitting of the floor, ceiling and adjacent brushes, and they're easier to texture (again because you only have two faces to texture instead of 3).

This is incorrect. Since HL1 (and I think as far back as Quake) the CSG process merges coplanar faces with identical texturing. In HL1, it could actually hurt you since the limits on things like planes were so low. I have a screenshot somewhere of a testmap example I made to debunk it for HL1 using your exact example, as well as another one where I took a 128x128 square and clipped it into 1x1 brushes - which were also all combined.

Now, though, it doesn't really matter either way. The faces will still get combined but the limits are high enough that it helps build cleaner and easier-to-read geometry. I got in the habit of doing it on Quake 4 both for cleanliness and the ease of texturing by brush rather than by face (i.e. grab entire brushes and apply texture rather than grabbing individual faces), and tend to do it where possibly in my Hammer work for similar reasons... though it annoys the hell out of me that I can't stretch mitered brushes like in Radiant.

Quote from the0rthopaedicsurgeon

I also spend hours nodrawing hidden faces.

As a rule I always use 'nodraw' as the default texture when creating brushes then manually apply textures to the visible faces.

Alternatively you can do a 'find and replace' for whatever your default texture is and swap them all out instantly with nodraw at the end of development. Works well as long as your default texture is unique, eg one of the dev textures.

Quote from the0rthopaedicsurgeon

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.

Oh, overlooked this when I replied earlier - it's not necessary. The CSG process also strips out all outside faces automatically. But, this is another one where it can still be helpful sometimes to improve readability of the level; it's a little more work and can get a little tedious sometimes, but it won't hurt anything.

Quote from KungFuSquirrel

Oh, overlooked this when I replied earlier - it's not necessary. The CSG process also strips out all outside faces automatically. But, this is another one where it can still be helpful sometimes to improve readability of the level; it's a little more work and can get a little tedious sometimes, but it won't hurt anything.

exactly, although the csg process has been merged with the bsp (tree creation) process from source onwards. you may want to look here for additional knowledge about the data structure that is the bsp tree (every final node in the tree is a visLeaf).

er, yeah. Old habit of calling it that.

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

Quote from 2d-chris

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.

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

Yeah, I didn't either.

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 ;]