News | Forum | People | FAQ | Links | Search | Register | Log in
Mapping Help
This is the place to ask about mapping problems, techniques, and bug fixing, and pretty much anything else you want to do in the level editor.

For questions about coding, check out the Coding Help thread: https://www.celephais.net/board/view_thread.php?id=60097
First | Previous | Next | Last
A Bit Of Bsp Theory 
I've done a few practical experiments today to test how BSP responds to the order of the brushes in a map, so I'll write up and post all about that later - and hopefully explain why adding a brush can reduce the marksurfaces. For now, a bit of reassurance for rebb.

Once the compiler has created a list of surfaces from all the brushes in the map, it has to decide which one to compile next. It has two methods of choosing the next surface to split along, which we will call "fast" and "slow".

The slow way is easiest to explain. It tests every surface in the list, and checks exactly how many splits will be made. It then chooses the surface which will create the fewest splits.

The fast way is more complex conceptually, but quicker to compute. The engine looks through the list of remaining surfaces to find the ones which are axis-aligned. Of these, it chooses the one which best splits the area of the map into two evenly sized halves. If there are no axis-aligned surfaces, it just takes the first remaining surface.

The old rule for the bsp tool was to use the slow way for the visible surfaces, on the grounds that reducing visible surfaces matters. For the clipping hulls the fast way was chosen, either to save compile time or to make a more balanced bsp tree, not sure. However, once you're running up against the marksurface limit, then minimising the number of splits in clipping hulls suddenly has value. This is where rebb's modification pays off, as it applies the slow way everywhere.

Fun little idea which has seems to hold up from all that above(bear in mind I'm not that knowledgable on bsp stuff): If you've got big chunks of map with trisoup walls, maybe a cave...if you build some nice axis-aligned brushes to contain the cave walls, even ones which will eventually be clipped away, that ought to improve the compilation in the "fast" phases of compilation. Those brushes should be compiled early, and act like proto-hint brushes.

So coming soon - why all that minimising splits stuff is not what it sounds like. And how adding brushes can reduce splits! 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.