Brush Work/BSP Best Practices

Tutorials and discussions about Mapping - Introduce your own ones!
Red_Fist
Godlike
Posts: 2163
Joined: Sun Oct 05, 2008 3:31 am

Re: Brush Work/BSP Best Practices

Post by Red_Fist »

" Hourence's tutorial on BSP literally says to avoid using intersect/deintersect"

Provided you have perfect fitting brushes, they do everything by the grid and 2,4,8,16,32 so they would never make a doorway with some odd numbers, is why.

If you make that brush by just putting brushes together that fit perfectly and all is good, just take the builder brush and surround the whole thing , use deintersect and it will make the one brush shape from all of those, then transform permanently red working brush, export it right away for stash later. (I work in the void a lot for this using subtracts, not in a working area cube box, ) otherwise you need to make an add brush and intersect not De,,intersect.

Then if you import that brush you must transform it right away. I always use a new import because the last one large brush I deinterseted to the wall, so I need a new one. Now if I just placed the brush I could use it over and over.

However if you use intersect(s) on each brush first, then surround to make one brush, all the extra intersects will make the one brush have more nodes.

"13. Is there any other brush order view or can you only use To Last and To First?"

If you have an add brush inside a subtract room, if you send that add brush to last, you will see the brush because it HAS to be last INSIDE of the subtracts. But you can't just do that after a map is all done because you pile things up, pillar, door, etc etc and you get into a catch 22, you need to send whatever should be last, first and work your way layer out.

But I always send all the green ones to last, then I select ALL the brushes, then I hit the ying yang icon (invert), it will select all the actors and then send all those to last at once. because they must be last to be INSIDE the map. After I do that though I still send the green ones to last because they can cut through the other brushes to form zones and cut through actors and movers. And they should never cut through a semisolid, pink.

When I speak of deintersect, would be basic brushes up against a wall, like a cube, not just placing the cube, it does not give more vertexes. I think what they do is make complex brushes and just hit add and it just sits there.
However, I have fixed tons of things and BSP holes by redoing the brush and actually intersecting it. Seems like it give the map a reference point to work from and creates a BSP not just things shoved in a hollowed out space.

I had a problem with movers, no sound, what it was is I had to click on a vertex to show a line going to trigger, even though the mover worked it had no reference point. Well I think the same for intersect, it makes the BSP know there is cuts. You also get messed up things, if you suspend a brush in the air, a big map, all the sudden you get holes all over the place. Other times I will raise a huge pillar off the floor by 2 units, but some other brush still gets intersected into it, but NOT the main floor, causing cuts on the whole damn map. But the brush still has a reference from other brushes, not just slammed into a map.
Last edited by Red_Fist on Sat May 16, 2020 7:27 pm, edited 1 time in total.
Binary Space Partitioning
truije15
Novice
Posts: 19
Joined: Thu Nov 21, 2013 9:11 am

Re: Brush Work/BSP Best Practices

Post by truije15 »

@Red_Fist this is the kind of stuff I've been wondering about for awhile.
Provided you have perfect fitting brushes, they do everything by the grid and 2,4,8,16,32 so they would never make a doorway with some odd numbers, is why.
Isn't that more to do with the initial brushes being good/bad more than the intersect/deintersect function? Say your vertex is a perfect 128.000000, 128.000000, 128.000000, is intersect/deintersect going to screw it up and turn it into 127.999873 units and cause BSP issues later? Aside from the additional nodes being added I always assumed intersect/deintersect caused issues from vertex positional errors or something to that effect.

That decoration I shared was made from 2D extrudes and 2D revolves after getting terrified of vertex editing and clipping the last few days lol I could have made it out of standard cylinder and cube brushes + intersect/deintersect which would have been my preference. However, to get a 90 degree bend like that with the standard cylinder I have to intersect/deintersect (can't remember which one), it doesn't create excess nodes or anything strange so it seems fine to me and the correct use of those functions right? But, in either case, the vertices of the revolve are obviously not a perfect 2,4,8,16,32 etc unit, does that mean it should never be combined into a complex brush? Or is that detail about the grid intervals regarding how each brush mates together?
If you make that brush by just putting brushes together that fit perfectly and all is good, just take the builder brush and surround the whole thing , use deintersect and it will make the one brush shape from all of those, then transform permanently red working brush, export it right away for stash later.
So when creating complex shapes you export the red brush immediately? Do you manually correct vertex positions on the exported file so it imports perfectly? Do you adjust the textures prior to export so its' stored? I'm guessing not if the first step is transform permanently. So do you intentionally create complex brushes that are easy to retexture (basically using a lot of base textures on large merged polygon surfaces)? If you import it why do you need to transform permanently right away? Does the exported brush retain some kind of translational data?

I used to work in a large subtracted cube (my first tutorial did so I continued it all these years later 8) ) then create the additions followed by [massive subtract cube]->polygon->to brush->intersect/deintersect->boom my brush. I recently stopped doing that and started working in the void, it's just easier now that I understand what I'm doing a little bit more.

Honestly after reading through this thread it sounds like I should be using transform permanently all the time. Say the brush is already transformed permanently, if I do it again will it unalign the textures? If it doesn't I can at least do a massive select all brush and transform permanently when I have BSP issues or am finalizing a map. If it screws up textures then I have to keep track of what brushes have had it done on them, that sounds like a nightmare.

This whole discussion is pretty eye opening, I've been slapping cubes together this whole time :P
Anderson
Red_Fist
Godlike
Posts: 2163
Joined: Sun Oct 05, 2008 3:31 am

Re: Brush Work/BSP Best Practices

Post by Red_Fist »

No, the textures are work, a separate issue, function.

Plus I am not very good at brushwork, FNB and Swanky make things that I would never attempt. I am more into gimmicky things, stretching the imagination to accomplish goals in some funky UEd idea I have. But I don't make very complex brushes or intricate looking maps. Like in my funky DM-Zonetube map I wanted to see the outside of the map I was playing in, as a skyzone looking out a window that you can jump out of into the skyzone, but you are in another section of the map that is the exterior shell of the map (low grav) not the skyzone, the skyzone was only the window you see before you jump out of it. and I made zones tubes that thrust you through the regular map. Still can't believe it worked LoL.

Transform just makes it so you start out with a legit mathematical brush that was already modified. If you want to make another different one, hit reset all and make another and transform it.

When you import your old brush you will see the lines disappear when you zoom out, right after import transform it and the lines will stay no matter what the zoom is. But it will keep what you exported, I think it even imports to the same spot in the map.

You are mixing things,

Say you make that sectioned beam, each section gets a 45 degree rotation.
Start with a RESET ALL, rotate, transform permanent
Second section, RESET ALL, rotate to next position, transform permanent
This has nothing to do with intersection

Intersecting in my mind is melding it to the map, or to make inverse shapes, whenever I add a brush to a map I deintersect and hit add brush.

But if I am making something that messes with the brush itself for sections, or movers, I always transform each section from a reset all brush.

If you have a corner and carve out an indent to fit a cube on the corner through the 2d editor or by editing vertexes you could transform it and plop it to fit. But why ? all you need to do is hit deintersect and it will wrap around the corner right away. It won't add polys or nodes and it will fit better without having to edit the brush to fit first.

Those pro guys make each brush then it fits in the exact spot, because they make complex brushes good and plan ahead for the least amount of polys. But if you had an intricate high poly doorway and need 20 of those high poly doorways. Intersecting would create tons of nodes. so when they make things they do good brushwork to minimize polys, and fit exactly.

But if you had a 200 node brush and intersected it with another 200 node brush, it will create piles of nodes. and problems.
Binary Space Partitioning
User avatar
Barbie
Godlike
Posts: 2792
Joined: Fri Sep 25, 2015 9:01 pm
Location: moved without proper hashing

Re: Brush Work/BSP Best Practices

Post by Barbie »

Red_Fist wrote: Sat May 16, 2020 3:31 amI had a problem with movers, no sound
What I have found is that the sound is emitted at an Actors's pivot point (shown as a small red cross). You can set the pivot by selecting the Actor (Mover), then right clicking in a 2D view and choosing "Pivot > ...". Sadly the suppressed vector component (for example the z component in the x-y-view) seems to be set randomly - I have not figured out how to set that component correctly yet. In most cases I fix that by copying the Mover to a text editor, removing the line with "PrePivot" and copying it back to UnrealEd.
"Multiple exclamation marks," he went on, shaking his head, "are a sure sign of a diseased mind." --Terry Pratchett
User avatar
Hellkeeper
Inhuman
Posts: 903
Joined: Tue Feb 25, 2014 12:32 pm
Personal rank: Soulless Automaton
Location: France
Contact:

Re: Brush Work/BSP Best Practices

Post by Hellkeeper »

truije15 wrote: Sat May 16, 2020 3:05 am10. When does UED write the transformation data? Every rebuild I'd guess?
It depends on what you mean by "write the transformation data". If you transform permanently the red builder brush, whatever brush you make with it from now on will be safe. If you transform permantenly a brush which has already been added or subtracted, then, as with all operations on a preexisting brush, you must rebuild. You'll see this clearly as textures will reset (if you don't use textureloack as papercoffee advised).
truije15 wrote: Sat May 16, 2020 3:05 am11. Does UED keep stacking the transformation data? Say you rotated 90 degrees clockwise 2 times then counterclockwise 2 times back to the original position without rebuilding, did it just store that or is it safe to use the brush still?
I think it doesn't stack, if you rotate clockwise 90 twice and then counterclockwise twice again, it just resets to a rotation of 0.
truije15 wrote: Sat May 16, 2020 3:05 am12. Does vertex editing count/get added as a transformation? Or is vertex editing separate from the transformation data? If I only vertex edited without rotating, scaling, etc. is there any reason to transform permanently?
Vertex editing is not a transformation, it changes the physical location of vertices. It is easy to understand: a transformation is applied globally to a brush while vertex editing acts on individual vertices. You can easily translate "scale X by 2.75" from a cube to a sphere, but how do you translate something like "the two rightmost vertices are moves by 8 on x and 6 on y" on something like a capped cone? In other words, vertex editing is not a "global modifier" like scale or rotation and so transform permanently has no effect. If you vertex edit a cube and create another cube, you can see the cube resets and does not keep your vertex edit in memory, while it would retain the scale or rotation modifiers.
truije15 wrote: Sat May 16, 2020 3:05 am13. Is there any other brush order view or can you only use To Last and To First?
I don't understand.
truije15 wrote: Sat May 16, 2020 3:05 am14. I usually reserve intersect/deintersect for where there's too many vertical surfaces I can't align the textures on and it's a brush I want to reuse several times (is that what a prefab is?), I'll combine together, align textures, then merge polys. I actually attached an example of one of the decorations that's an issue for me right now. It's a bent "I" beam consisting of 5 brushes total, everything is vertical so I have no nice tool like align to floor to use (unless that's a thing these days). Normally it's only a few surfaces and I'll bite the bullet and manually align the textures with the brush in place. I want to use intersect and turn this into 1 brush that I can easily rotate around a couple times, align all the surfaces, and merge the polys. I can then later vertex edit the length to fit it wherever I want and keep the polys merged together for quick texture realignment. What is the consensus on the proper use of intersect in this kind of situation? How would you guys clean up the textures? Hourence's tutorial on BSP literally says to avoid using intersect/deintersect. This particular set of brushes won't rotate together, is that what transformation permanently can fix? I'll test that last comment right now but I might as well have it here for visibility.

@FraGnBraG I agree this is a really informative thread. There's a good amount of tutorials out there on things like BSP holes/HOM's and semi-solids (BSP related) but I don't think I've ever seen one about proper brush work best practices, vertex positional errors from manipulating the brush, and this whole usage of transform permanently. Take that comment about Hourence mentioning to avoid using intersect/deintersect, I want to know why though so I can use it properly and when I can use it. Does it cause massive positional vertex errors? Are the added vertices not worth it? How do I use it correctly?
The deal with deintersect/intersect is not linked to small decimal errors, it does not create the .002947 problems, it inherits them from the bushes used to create the original structure. Hourences advises against using these tools for simple reasons:

- They create very complex shapes and add a number of edges to keep all faces convex, but usually it adds a bunch of useless ones, they are created seemingly randomly and often come with new useless vertices creating a brush which is much worse than the original combination of simple brushes.
- The process is not flawless and you might get a face which bugs out and disappears from the intersected brush.
- All this can be mastered and avoided but this takes a lot of preparation and work on your original brushes, and it requires a very good understanding of how brushes and the engine work. People who resort to intersect/deintersect are usually the kind of people who have a shaky understanding of things and use it as a shortcut, meaning they didn't prepare their brushes with care, and this results in horrible messes.


As for your beam: if I understand correctly, the problem is that when you want to rotate it, all brushes rotate differently? First, try to set the pivot by selecting all these brushes and right-clicking on a snapped vertex of one of these brushes. This sets the pivot to where you click and usually helps by giving a common pivot to all the selected brushes.
But, in either case, the vertices of the revolve are obviously not a perfect 2,4,8,16,32 etc unit, does that mean it should never be combined into a complex brush? Or is that detail about the grid intervals regarding how each brush mates together?
That has no bearing on your issue, revolve makes vertices which are not snapped to the grid but have very precise locations and, most importantly, makes a brush with only convex surfaces, so if you intersect it, the resulting brush will be exactly similar to the original, with no added edge or vertex and no positionnal error apart from those inherited from the original (these errors come from rotating the brush around, but don't worry too much, really, their influence is minor: this is as old as the engine and I've only seen them being noticed and discussed recently, meaning they've never been that great of a problem).
You must construct additional pylons.
User avatar
Swanky
Adept
Posts: 462
Joined: Sun Mar 16, 2008 9:06 pm
Personal rank: Brush Commander
Location: inside ze bocks
Contact:

Re: Brush Work/BSP Best Practices

Post by Swanky »

13) There is no dedicated view panel for brush orders. Brushes are ordered numerical with highest having precedence before other factors. A brush' number can be looked at in brush properties -> object (as can everything else' number, too).

The reason Hourences mentions not to use De/Interset too liberally is because a) the new brush may be way too complex for the geometry to be displayed correctily - the intersected brush' algorithm on how to compute the new brush is wonky. You can sometimes see new brush lines between the vertices and because of how the ue works those things out, it can and does cause errors. And b) For the new brush new cuts have to be generated which are again, often more complex as the simple structure's cuts which again can result in weird effects, and this time on the brushes surrounding area, or, if you are unlucky, on the other side of the map. It's one of the reasons I'm often using many smaller (semisolid) brushes in favor of an intersected one.
User avatar
Barbie
Godlike
Posts: 2792
Joined: Fri Sep 25, 2015 9:01 pm
Location: moved without proper hashing

Re: Brush Work/BSP Best Practices

Post by Barbie »

Swanky wrote: Sat May 16, 2020 1:00 pm 13) There is no dedicated view panel for brush orders. Brushes are ordered numerical with highest having precedence before other factors. A brush' number can be looked at in brush properties -> object (as can everything else' number, too).
I think this is done in another way: every time you insert an Actor into a map, its name it build from the class name plus the lowest unused number for this class. The algorithm might be like this (pseudo code)(1)

Code: Select all

i = 0;
while (ActorNameExists(NewActor.Class.Name) $ String(i))
  i++;
NewActor.Name = NewActor.Class.Name $ String(i)
This is the name of the actor and it has nothing to do with the building order. Instead inside a map must be an Actor list that is used for building a map. If you use "Order > To First" or "To Last", the Actor is moved in this list. You can verify this by exporting a map to T3D: here all Actors are listed in order of their building sequence. If you put an Actor "to last" for example, it will be the last in that T3D map.

These are all guesses from working with T3D and binary versions of a map, so correct me if I'm wrong.

1) If a class name ends with digits, they are removed before a new name is requested.
"Multiple exclamation marks," he went on, shaking his head, "are a sure sign of a diseased mind." --Terry Pratchett
User avatar
Feralidragon
Godlike
Posts: 5489
Joined: Wed Feb 27, 2008 6:24 pm
Personal rank: Work In Progress
Location: Liandri

Re: Brush Work/BSP Best Practices

Post by Feralidragon »

I will just add the following since I am pretty sure that a lot, if not most, of even the experienced mappers around do not really know about this when it comes to semi-solids:
  • you're able to achieve near-zero (and even absolute-zero) BSP errors with semi-solids in almost every map.
Many do not realize this, but semi-solids are actually the most stable type of BSP that you can possibly have in a map, meaning that most mappers steering away from them are actually making things much harder for themselves.
I kept mentioning this over and over, maybe over the past couple of years at least (when I did some more serious mapping), but rarely anyone believes me, and many continue to stay away from semis while constantly complaining about BSP issues that they have to spend hours or days in, which is quite tragic.

So here's the thing: it just so happens that when you do a normal BSP build, the main issue you notice right away with semi-solids is disappearing surfaces.
This seems to be the main reason mappers stay away from them, and the advice generally given even by experienced mappers is generally: if it has problems, turn it to solid, which 98% of the time is the wrong advice.

The real reason why you have all sorts of issues with semi-solids in the first place is because you have been using a BSP build meant to be quick, and not good.

When you click the Build BSP button, you're actually performing a relatively quick, but unoptimized, poor-quality, error-prone build of your BSP, and as such you will always have all sorts of trouble with every type of BSP, especially semi-solids, and the map will perform worse on top of that, since no optimizations to the tree will be made.

This type of build is only meant for you to have a rough visualization of your own work while you're working on your map, without waiting too long between builds.
It's not meant to be the type of build you do when you intend to play-test and release the map in the end.

However, if you click the Build All button, the way BSP will be built will be fairly different.
It will do a much longer BSP build, since it will build an optimized, high-quality tree, with little to no errors whatsoever most of the time, and suddenly all those disappearing surfaces are no more, all semi-solid surfaces will properly appear without any bugs.

But Build All will build everything else as well (lighting and paths), but you can tweak what it actually builds and limit it to BSP alone by clicking on Build Options.
It's also worth noting that the current editor version (2.0) has a bug where only visible BSP is built this way, meaning that if you have hidden brushes, this type of build won't add them to the tree, so you have to click Show All before, but this is a bug which has been fixed in later versions (at least as of 2.2).

Of course, there's still a tiny chance of some bugs even with this build (namely collision bugs), and that's where you may try things such as turn something from semi-solid to solid to try to fix it, but most of the time you don't really need to do this at all, it will just work.

There are also some myths circulating about semi-solids which are absolutely untrue.
For example: many believe that the brush order of semi-solids changes anything, with some mappers even advising to always order them to last, but well, they don't.
The order of semi-solids is completely irrelevant, since they are always built last in the BSP build process, as they are simply added into the already built BSP tree as addons, and nothing more.
User avatar
Barbie
Godlike
Posts: 2792
Joined: Fri Sep 25, 2015 9:01 pm
Location: moved without proper hashing

Re: Brush Work/BSP Best Practices

Post by Barbie »

Let me add a possible fix to avoid invisible surfaces with semi- and non-solid brushes: keep them away from other brushes, for example 1 UU. In many cases this small distance is not noticeable for players.
"Multiple exclamation marks," he went on, shaking his head, "are a sure sign of a diseased mind." --Terry Pratchett
Red_Fist
Godlike
Posts: 2163
Joined: Sun Oct 05, 2008 3:31 am

Re: Brush Work/BSP Best Practices

Post by Red_Fist »

"I can at least do a massive select all brush and transform permanently when I have BSP issues or am finalizing a map."

It's , per brush, usage.

BEFORE the program builds the map. to have a good reason to use.

Back to semi solids.
If you want to use them, sandwich them between two solid blue adds, you will never have a problem, and reduce polys as a bonus. Make sure you deintersect the blue add brush to the subtract-BSP, then deintersect the semi solid to the solid add brush.

WHY ?

Because since that semi solid don't make BSP cuts, the padded first add blue brush deintersected to the subtract brush already affected the BSP making cuts. But the semisolid on top of the solid blue add will only make cuts or effect that solid and not the BSP of the floor-subtract. It works very good to keep cuts out of the main map subtract area but keeps things from messing up.
If you make a tower, use a deintersected SOLID blue add first to the subtract, and build the rest on top, you will never see a BSP problem to make the rest of the tower all semi solids, or will never affect other spots in the whole map.
Binary Space Partitioning
User avatar
FraGnBraG
Inhuman
Posts: 930
Joined: Sun Jun 13, 2010 5:13 pm
Personal rank: Good news everyone!
Location: Canada
Contact:

Re: Brush Work/BSP Best Practices

Post by FraGnBraG »

Thank you ferali :) not sure i'd want to make a map out of semi-solid, lol - i will add another little tid-bit of truth: Semi-solids do not occlude. They do not make cuts in BSP, they do however make cuts in them selves, thus can have co-planer polygon issues same as "solid" surfaces. For fun, go have a look at that little rich akuma urban ctf map (where he first used richrig) it's mostly semisolid, lol! Anyways, the intent of semi-solid type is for decoration purposes, where the collision is required, as well non-solid when no collision required. The ctf face french guy from epic said in an interview back in 98 or 99 that he avoids non-solid type because of rendering issues (?) can't exactly remember. Some other epic guy (polge or sweeny, dunno) said use semi-solid for deco purposes, like making cyinder-based pillars, since these won't affect the bsp. If you use solid bsp to make lots of pillars/pipes or other complex shapes you will shred the shit out of your bsp (i.e. create extras-messy cuts - look in zone-portal view). The affect of these brushes on cuts was covered in several tutorials as well, as i recall.
-=FraGnBraG Level Design=- ***UPDATED! even works on your phone!***
User avatar
sektor2111
Godlike
Posts: 6403
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Brush Work/BSP Best Practices

Post by sektor2111 »

Ye... Veeery big problems with Semi-Solids. Except here...
viewtopic.php?f=5&t=12060&p=95886
Where I did some experiment in using prefabs... of course I used what I found suitable, because that was a "prefabs" collection with a lot of garbage...
And then, in order to ruin all semi-solid threatening stories about some Boo-Boo, when I worked to solve several problems in whatever mapping contest map I did this:
MH-AMC-Mesospheric_sk_tw0.7z
(5.06 MiB) Downloaded 13 times
I think this one I shared privately but... you have captured my attention with these semi-solid problems "aka 50% Solid". I did not check each surface, but I played a few games... Of course, you'll see BSPCuts where are coming from...
To be honest CTF-Face has those problems which RedFist described and I think those are bad practices, this is confirmed if you rebuild map and remove all BlockAll, see result...
Story is longer and I don't have the language for full explanations about what does a brush OUT of grid or having a FAKE grid alignment...
User avatar
Chamberly
Godlike
Posts: 1963
Joined: Sat Sep 17, 2011 4:32 pm
Personal rank: Dame. Vandora
Location: TN, USA
Contact:

Re: Brush Work/BSP Best Practices

Post by Chamberly »

When someone ask the right question, it's here.
Image
Image
Image Edit: Why does my sig not work anymore?
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 »

I don't know... but I like Semi-solids. They make nice clean BSP cuts.
Map
Map
Wireframe
Wireframe
BSP cuts
BSP cuts
User avatar
Swanky
Adept
Posts: 462
Joined: Sun Mar 16, 2008 9:06 pm
Personal rank: Brush Commander
Location: inside ze bocks
Contact:

Re: Brush Work/BSP Best Practices

Post by Swanky »

...unless the red/blue one gets a supercut through half your level.
Post Reply