Brush Work/BSP Best Practices

Tutorials and discussions about Mapping - Introduce your own ones!
User avatar
papercoffee
Godlike
Posts: 10443
Joined: Wed Jul 15, 2009 11:36 am
Personal rank: coffee addicted !!!
Location: Cologne, the city with the big cathedral.
Contact:

Re: Brush Work/BSP Best Practices

Post by papercoffee »

Swanky wrote: Sun May 17, 2020 4:57 pm ...unless the red/blue one gets a supercut through half your level.
Yeah strange... why is there such a cut anyway. Must be the skybox cube in the background.
Red_Fist
Godlike
Posts: 2163
Joined: Sun Oct 05, 2008 3:31 am

Re: Brush Work/BSP Best Practices

Post by Red_Fist »

What is fun is, sending things to last and watching the BSP view to see it change in various ways. Or switching things to solid or semisolid.

I wish I knew more but my guess is when that BSP view shows organized larger areas per color is what one would want. Not a scattering and broken colors. The reason I say this is because a one large cube map with nothing in it shows only one color. :noidea
Binary Space Partitioning
Myth
Inhuman
Posts: 988
Joined: Tue Feb 12, 2008 5:57 pm
Personal rank: Low Poly Freak

Re: Brush Work/BSP Best Practices

Post by Myth »

I find it most interesting how everyone seems to have a different approach to this. So I'll be speaking about my experience.

First to understand what brushes are:

- Brushes are mesh data with a transformation and an operator
- Mesh data is a list of planes defined by list of vertexes
- A transformation is any rotation, scaling, movement, shearing
- Operator can be add, subtract, semisolid, non-solid

And how they interact:

- Level geometry is built out of a list of brushes.
- When you move, scale, shear or rotate a brush you change transformation.
- When you vertex edit or clip you act upon mesh data.
- When you "transform permanently" you commit the transformation to mesh data
- You cannot edit the mesh origin, however, you can select all other points and move them around the origin to edit the origin.
- Brush order affects geometry when you have different operators, add after subtract not the same thing as subtract after add.
- Brush ordering affects BSP cuts, so if you swap the order of two additive brushes you might get completely different BSP
- Planes defined by more than 3 vertexes are very fragile, if you add a 4th vertex which is not on the same plane you get invalid mesh data.

When you build the level, the editor's job is to take the list of brushes one by one in a well defined order and compile them into level geometry. This is a complicated algorithm, so you got to forgive it for sometimes messing things up. It does a poor job at handling edge cases. It's sensitive to what you feed it with. If you feed it with bad corrupted brushes, you will get a bad corrupted geometry. You need to feed it with valid mesh data and a clean brushwork to simplify it's job.

These were facts until now, it's just how it works under the hood. It makes logical sense.

This is the more "subjective" part of the post, the practices I follow. They are not hard rules, everyone has their way of working, here are mine:

- Mesh data must be valid: all vertexes belonging to a plane must be coplanar, mesh data used for collision (solid/semisolid) must not have gaps. Trash mesh data will trash your level, no matter what other tricks you employ. It's very easy to mess this up with vertex edit, for example if you have a cube and pull just one of the corners diagonally, you messed up all planes to which that vertex belonged to. I end up deleting and remaking brushes because of if this rule, because I find a possible issue with them and I don't want the error to propagate through the level. Sometimes to fix a BSP hole, I need to go on a hunt to find the offending brush, sometimes it's impossible to find if you have a complex level so it's better to make sure that they are correct from the beginning.
- Keep strict brush ordering: 1. Subtract -> 2. Solid -> 3.Semi-Solid -> 4.Non-Solid, sometimes this is not practical, it's okay to have a few subtract after add, but keep them in check. I usually keep them in a group. If something else works for you, it's fine, just keep control over your brush ordering, this has the 2nd most impact on avoiding errors after having correct mesh data.
- Brushes need not be aligned to the grid, go wild! The build works fine with planes of all angles in 3d space. If it wasn't then we would all be limited to cubes and only have minecraft levels. You are free to rotate brushes. I build some parts of my levels with grid disabled, I did not have any more BSP issues than the usual.
- Have clean mesh data before transform: I find it useful to have the brush origin point in certain places on the brush to be able to use it as a snapping or rotation pivot. While for other brushes it's useful to have it in the center or bottom of the brush. For some brushes I make sure that they are correctly textured, so after that I can scale, rotate and place them around the level without needing any further adjustments.
- Group brushes where they make sense: My most common groups are: red-base, blue base, mid section, skybox, light type groups, subtract-after-add. Grouping is useful if you need to select or deselect this group again which can be a major timewaster if you need to re-select manually. I shift around section of my level throughout editing, and sometimes I disable some parts of the level so I get faster builds for the parts I'm working on. But this is something you have to figure out how it helps you. I sometimes end up with, I should have made a group out of that, would have saved a lot of time now.

What I'm trying to do is to make levels that are not aligned to the grid so much. I find it limiting to see most game level, even newer titles in the more recent years, most have a grid based level layout. So I'm trying to take my layout into different directions, and it makes it all the more important to have clean brushwork. See my attached screenshot.
Attachments
Unrealed.jpg
Post Reply