logo
Main

Forums

Downloads

Unreal-Netiquette

Donate for Oldunreal:
Donate

borderline

Links to our wiki:
Wiki

Walkthrough

Links

Tutorials

Unreal Reference

Usermaps

borderline

Contact us:
Submit News
Page Index Toggle Pages: 1 Send TopicPrint
Sticky Topic BSP error observations (Read 8793 times)
GreatEmerald
Oldunreal MasterPoster
*
Offline


The Great Emerald

Posts: 5361
Location: Vilnius, Lithuania
Joined: May 21st, 2007
Gender: Male
BSP error observations
Nov 13th, 2010 at 9:18pm
Print Post  
I've found a few interesting things I'd like to point out. I'm doing a BSP error hunt in my map right now, and there are a few things worth noting:

First, if you don't use build all, but use the three other buttons, you get this on semi-solid brushes:


This is seen in Zone/Portal view while inside a solid brush (void). The faces that are not the same colour like the rest of the zone are invisible.

I looked it up on Unreal Wiki and it's as I suspected: these surfaces are by mistake assigned to a zone other than the one they actually are in, and that zone they are assigned to is not visible to the player. That means that the face in question is never seen by the player, because the engine thinks that the face is irrelevant.

Interestingly, this is solved by doing a BSP rebuild - the part of Rebuild All that you omit when you use the buttons one by one. It appears that the BSP rebuild part is in fact very important for the whole BSP tree - it essentially rebuilds and optimises it, thus things like zoneless polygons get assigned to the right zones. It also solves a lot of performance problems.


Another good thing (this is done by a geometry rebuild) is merging planar polygons. That is in fact very important for lighting. If you have a complex brush, you get lighting problems since the engine gives up calculating the right lighting for each and every polygon there. In the image you can see this problem in the upper brush, to the right - the triangle there doesn't get lit correctly since it's not merged with the rest of the face's polygons. The lighting issues on the pillars are similar, but so far I can't find a good way to get rid of that problem.

It is also very, very important to merge polygons after everything you do in the 2D shape editor, or getting these light errors + worse performance is guaranteed. Also note that polygons will only be merged if the textures are aligned in a way that they could be merged - that means you need to use Align to Floor/X/Y in order to make them aligned, and only then do a Brush-> Polygons -> Merge. Also, you should merge them before aligning your texture correctly since that just makes it a lot easier - you don't have to select all faces all over again if you accidentally misclick and deselect everything. An easy way to select all those faces is to do a Surface -> Select Surfaces -> Adjacent Coplanars, but beware that those polygons selected will not be strictly from the same brush. It would be a really nice feature, though...

Another thing I've noticed is that the two types of BSP errors are dependent on the brush type. If the brush is semi-solid, you will never get a HOM - you will always get an invisible polygon. It's the opposite for solids - you will never get invisible polys, but you will always get HOMs. That means that the errors you get with semi-solids are when a polygon is assigned to a wrong zone; the errors with solids are when a polygon is assigned nowhere at all, thus you see the void. But the lighting problems occur for both types of brushes, meaning that there is something wrong in the lightmap...

Apparently, it also helps if you do a Transform Permanently after rotation, vertex editing or brush scaling. There will be less maths to perform by the engine, thus less BSP errors and better performance.

One more note about BSP rebuilding - when you click "Rebuild geometry", the current BSP tree seems to be thrown out the window, that is, you will see polygons assigned to wrong zones again. You must rebuild the BSP tree to get those stray polygons fixed. So it would be a nice feature to have a "BSP [tree] rebuild" button near the others, although you can get a temporary one by simply going to rebuild all options, unchecking everything but BSP and hitting Build/Build all.

- Balance Tree 100%, 70% portal cut, no geometry optimisation, lame tree optimisation
- Minimise Cuts (Balance Tree 0%), 70% portal cut, no geometry optimisation, lame tree optimisation
About the Minimise Cuts/Balance Tree slider - it seems that it affects the way the rebuilder dissects the geometry. Balance tree makes the maximum polygon depth as low as possible, that is, every cut will be as similar in size to other cuts on the same surface as it can be. Minimise cuts, on the other hand, makes the tree disproportional with as many levels as possible.

If you can see one cut, all of its children will also be rendered, but not its parents or its brothers. So simply put, Balance Tree creates more brothers to every smallest cut; Minimise Cuts creates more parents. Since both are not rendered, it shouldn't matter much - the BSP errors you see will simply be put to different shapes, that is, with Balance Tree they will be of medium size, with Minimise Cuts they will be of small and huge size.

Though Minimise Cuts tends to create less nodes all in all, and that means less calculations for the engine, yet bigger nodes. That would mean that you will generally see bigger holes than with Balance Tree; however, Balance Tree can have so many nodes that the engine will give up calculating and will create new holes (in fact, using 100% Balance Tree will create more nodes than without the tree at all!). Thus the default setting is 15/100, which means that your standard BSP hole is quite big, but the performance is good and thus new holes don't usually form.

- 15% cut minimisation, 0% portal cut (Ignore Portals), no geometry optimisation, lame tree optimisation
- 15% cut minimisation, 100% portal cut (Portals Cut All), no geometry optimisation, lame tree optimisation
About Ignore Portals/Portals Cut All - The Ignore option should make the BSP tree lighter, that means less nodes, faster framerate and less BSP holes; however, if there is a BSP hole on a portal, no matter how small, you're in s world of trouble. The Cut All option should make portals have a bigger priority when cutting geometry, that means BSP holes have a lot smaller chance on forming on them, but the tree gets heavier, you get less framerate, more BSP holes on non-portals and more nodes. The default is 70 since leaking zones is one of the worst things that can happen in a map which wreaks havoc on the whole portal generation system and thus optimisation as a whole.

However, if you select all zone portals and use Order -> To Last, they will get a higher priority naturally, meaning that you will be able to lower the slider there and thus getting better performance and less cuts out of it. You could also experiment with this option - set it to as low as possible while zones aren't leaking yet, and you will get it optimal. In fact, as you can see in the pictures, the node count decreases dramatically if you set the slider to Ignore Portals.

In my case, I still don't have many zone portals in the map, so anything I set on the slider didn't affect the node count at all.

- 15% cut minimisation, 70% portal cut, no geometry optimisation, lame tree optimisation (these are basically defaults without optimisations, I used them for all the other tests, so compare them to this one as default)
- 15% cut minimisation, 70% portal cut, with geometry optimisation, lame tree optimisation
- 15% cut minimisation, 70% portal cut, with geometry optimisation, good tree optimisation
- 15% cut minimisation, 70% portal cut, with geometry optimisation, optimal tree optimisation
Now a few notes on BSP optimisation. The more BSP optimisation is applied, the less nodes there are, thus the better framerate and less BSP holes. However, it takes longer to build; yet it seems that it takes a long time one way or another, so you should simply stick with optimal. Hence why it's the default.

Geometry is the same thing, just without the settings. Leave it on for better results (I get a +0.07:1 node count boost with it on on default settings). Note that BSP and geometry optimisations are different settings (hence unticking Geometry optimisation will allow you to change BSP optimisation settings).

There is also a very interesting thing I've noticed - rebuilding BSP several times leads to better node count. That's very interesting, because on first BSP rebuild I get 1.97:1 ratio, on the second - 1.90:1, on the third - 1.88:1. So if you have a lot of BSP errors, rebuilding BSP several times seems to help; probably because the engine has the old tree there and simply does additional optimisations where it sees fit. Building more than tree times gives no more optimisation. I've been able to replicate this every time I tried with the default settings + all optimisations, so that's certainly new and something to consider. Another thing I've noticed is that if you rebuild several times without any optimisations, you will actually get worse and worse node ratio!

Rebuilding Geometry together with BSP is exactly the same as clicking the buttons one by one. But generally don't rebuild geometry too much since you'll lose the BSP tree, and if you rebuild the geometry, build BSP once, and three time before release.

Build Visibility Zones means it builds zones. Always keep it checked. It should actually be called "Erase zones" and be unchecked, since building geometry only means it builds zones, too, but building BSP without Build Visibility Zones means zones will be erased (zone count becomes -1!).

- BSP tree not built, 70% portal cut
So what happens when the tree is not built at all? It seems that the same thing as when you place a light in the world and don't rebuild lighting - it will build something, but it will be very suboptimal. In the picture above you can see that no BSP build makes it like an extreme case of BSP Minimise Cuts & No Optimisation - the depth is insane, and for that kind of depth there are loads of nodes. What does that give you? For one, loads and loads of BSP errors due to the high node count, like the aforementioned surfaces being assigned to wrong zones; low performance, since the cuts are so small you will be able to see the parent of a whole lot of them at any given time.

So, in conclusion, it seems that using the BSP rebuild is in fact very important, since it gets rid of a lot of BSP holes. The defaults are good enough, but you can tweak them by getting all zone portals to last brushes and setting the zone slider towards Ignore Portals, but you will have to be careful and do several attempts (best way is to find the right value by halving the percentage and then checking if portals still hold in the editor). If you don't get a lot of BSP holes, set the Minimise Cuts/Balance Tree slider to Minimise Cuts side to gain some extra performance and kill off the remaining BSP holes; if you get a lot of holes, set the slider towards Balance Tree and you will be less likely to notice them, but be careful or you will create more holes by setting it too high. Always use Optimal BSP optimisation and geometry optimisation.

The best result in terms of node ratio that I had was 1.73:1, and I got it with 0% on both sliders, full optimisations and rebuilding BSP three times on one Geometry build. That's quite a bit better than 3.04:1 with no optimisations and Balance Tree. Though it took quite a bit longer; in fact, three rebuilds took around 20 minutes!

Also, one more thing to note is that if you have a lot of BSP holes, you also probably have really bad performance. They appear only when the engine gives up on the maths. So lower node count = better performance = less BSP errors.

So, if anyone have some comments or if I got something wrong, please tell me. This is quite important for all mappers, so it's always good to know everything about what options do what correctly!

EDIT: Just playtested the map with 1.73:1 node count, and it was interesting. I saw only a single BSP error (and that with only a few zones in the map, most being for lava!). Due to a really high node count, though, it was quite big - the whole corridor was one, but then again only when I was a few steps away from that place. Interestingly, I experienced no zone leak whatsoever. Probably not enough zones to leak or something.

EDIT2: I tried and rebuilt nyLeve (to a new file, of course), and that's interesting: the original had a ratio of 1.88:1, after a full rebuild with the defaults I had 1.66:1, and no BSP holes, just like in the original. And I remember that nyLeve was one of the hardest maps to rebuild properly... So good job on those optimisations!

EDIT3: Yeap, just tried rebuilding it on UT UEd 2.0, and guess what? An invisible collision hull! But the node count did go down just like in UEd 2.1.
« Last Edit: Nov 13th, 2010 at 11:19pm by GreatEmerald »  
Back to top
WWW  
IP Logged
 
Hellkeeper
Global Moderator
*****
Offline


Soulless Automaton

Posts: 2780
Location: France
Joined: May 21st, 2008
Gender: Male
Re: BSP error observations
Reply #1 - Nov 13th, 2010 at 11:02pm
Print Post  
Surfaces being assigned to a wrong zone can also be flagged as "Force View Zone". The exact purpose of this flag is to set polygons visible when they are erroneously set to inexistant zones (and it goes hand in hand with the No Bound Reject flag, for when annoying polys won't stop flickering in and out of view).

About merging polygons and transform permanently : I think (I hope) everyone knew that already.
Yes, rebuilding geometry rebuilds the BSP tree. That's what it's supposed to do, guessing from the "rebuild" part of the name Wink

And yeah, many HOMs means bad performances, because poorly made brushes means poorly used engine.

About rebuilding several times leading to further optimisation : interesting, that might be useful. I will perform a few test builds to see how far it goes.

Now, for your conclusion, I have only one thing to say : why the hell wouldn't you rebuild BSP ? Isn't it obvious that they didn't just implement a function for the sake of it ? That it has some kind of use, especially when its name pretty gives away that it's supposed to make the most important part of your map clean ? Huh

(I guess that's why you often said that we shouldn't use Build All but the three separate builders separately. That always seemed black magic and superstition to me, which was obvious to anyone using the zone/portal view on his map before and after regular build : most of what you say about the BSP rebuild is something many people had noticed long ago without knowing exactly and in details how it as done).

Anyway : good infos here, useful tests, even though I didn't quite get everything about the BSP tree (because I don't understand how bsp trees work). i will also add that merging polygons may in fact not solve lighting issues on adjacent surfaces (alas).
  

You must construct additional pylons.
Back to top
WWW  
IP Logged
 
GreatEmerald
Oldunreal MasterPoster
*
Offline


The Great Emerald

Posts: 5361
Location: Vilnius, Lithuania
Joined: May 21st, 2007
Gender: Male
Re: BSP error observations
Reply #2 - Nov 13th, 2010 at 11:35pm
Print Post  
Hellkeeper wrote on Nov 13th, 2010 at 11:02pm:
Surfaces being assigned to a wrong zone can also be flagged as "Force View Zone". The exact purpose of this flag is to set polygons visible when they are erroneously set to inexistant zones (and it goes hand in hand with the No Bound Reject flag, for when annoying polys won't stop flickering in and out of view).

About merging polygons and transform permanently : I think (I hope) everyone knew that already.
Yes, rebuilding geometry rebuilds the BSP tree. That's what it's supposed to do, guessing from the "rebuild" part of the name Wink

And yeah, many HOMs means bad performances, because poorly made brushes means poorly used engine.

About rebuilding several times leading to further optimisation : interesting, that might be useful. I will perform a few test builds to see how far it goes.

Now, for your conclusion, I have only one thing to say : why the hell wouldn't you rebuild BSP ? Isn't it obvious that they didn't just implement a function for the sake of it ? That it has some kind of use, especially when its name pretty gives away that it's supposed to make the most important part of your map clean ? Huh

(I guess that's why you often said that we shouldn't use Build All but the three separate builders separately. That always seemed black magic and superstition to me, which was obvious to anyone using the zone/portal view on his map before and after regular build : most of what you say about the BSP rebuild is something many people had noticed long ago without knowing exactly and in details how it as done).

Anyway : good infos here, useful tests, even though I didn't quite get everything about the BSP tree (because I don't understand how bsp trees work). i will also add that merging polygons may in fact not solve lighting issues on adjacent surfaces (alas).

Force View Zone also has a nasty habit of making the polygon unlit, so it's better to use normal means.
No Bound reject? Haven't come across this before. What do you mean, flickering polygons?

Well, I knew about them, but not exactly when to use them. And I keep forgetting to transform things permanently until it's too late and I don't want to realign the surfaces... But those two are the most important for the 2D shape editor, namely arch creation: you have to rotate it so it would be on the right axis, transform permanently, then align polygons, merge them and do any additional alignment.

Uhh, no, rebuilding geometry rebuilds, well, geometry Tongue It just previewbuilds the BSP tree. Rebuilding the BSP rebuilds the BSP Tongue

Not really poorly made brushes, but rather complex ones. And even then, when you rebuild the BSP well enough you can get away with those.

Yeap, that's why doing research is a great thing Smiley This proves that it is in fact very important to build the BSP tree, unlike I believed earlier, and it's very much worth the wait.

Basically what you need to know about the BSP tree is written here:
http://wiki.beyondunreal.com/Legacy:BSP_Tree
And so far merging polygons has solved all of adjacent surface lighting problems for me. Probably if you have a really small surface, it won't help. In fact, I think that this might be why I'm having problems with the pillars there - the surfaces are so thin that the engine ignores them. The problem is that I can't really do anything about that without losing graphics detail... And same goes for the stairs. (Oh, and merging side polygons of the stairs is very important, too.) Though I guess a nearby light source would help, but then again, it wouldn't be very realistic that way.
  
Back to top
WWW  
IP Logged
 
Hellkeeper
Global Moderator
*****
Offline


Soulless Automaton

Posts: 2780
Location: France
Joined: May 21st, 2008
Gender: Male
Re: BSP error observations
Reply #3 - Nov 14th, 2010 at 12:19pm
Print Post  
I tried to read stuff about the BSP tree : I just gave up. And yes, rebuilding geometry rebuilds only world geometry, that's what I thought but I was alreadyt hinking about the next stuff I wanted to write and so I got confused by myself. Read what I thought, not what I wrote Tongue

As for the No Bound Rejects flag: You may notice sometimes in UnrealEd that polygons on the edge of the 3d viewport get blacked out (as if you had a BSP hole), but only when they're on the edge of the viewport (this is after all proper building). Usually, this doesn't appear ingame, but I had cases where it happens : the polys seems to go in and out of view repeatedly as they let a BSP hole when you're moving around and suddenly magically appear when you look directly at them. It's ugly, annoying and very unprofessional Cheesy
(and I personally never had problems with the ForweViewZone, wans't awar of that problem, interesting)

As for arches : I like to keep them unmerged so that I can use a trim texture that wraps nicely on the arch (think bended metal or brick arch). On stairs however, yes : unskippable.
  

You must construct additional pylons.
Back to top
WWW  
IP Logged
 
GreatEmerald
Oldunreal MasterPoster
*
Offline


The Great Emerald

Posts: 5361
Location: Vilnius, Lithuania
Joined: May 21st, 2007
Gender: Male
Re: BSP error observations
Reply #4 - Nov 14th, 2010 at 12:36pm
Print Post  
Oh, that! Huh, I never knew you could do anything about it. Plenty of holes like that in nyLeve when you look at the sky. And the problem I had when I rebuilt it with maximum optimisations was also of that sorts.

By the way, I just rebuilt my level with the defaults, and eww, it's considerably worse than with 0% on everything. When I had 0%, when I looked straight at the castle, I had 30 FPS. With the defaults, I get 10 FPS! And one, gigantic BSP hole in the living quarters + another gigantic BSP hole in the throneroom. So the settings are very important indeed.

On a related note - what about zoning? I've seen that in nyLeve, in the main outdoors region, where that little pond with biterfish and a clip is, they have zoned the whole area off. Personally I don't think that it was a good idea since water is a zone portal by itself. But, for example,  in my map I have complex towers, and they should probably be best zoned off. But if I was to zone off only doors and windows, I would essentially zone off a single cylinder (since inside is a shaft with a mover, which by itself is not a part of BSP). It would make more sense if I zoned off the whole tower by using a cube brush, right? Well, that and the shaft, since I need EAX support.

Another question, about Transform Permanently - if you vertex edit the builder brush, then transform it permanently, do you need to transform the brushes you add with the builder brush as well, or does transforming the brush do that for all added brushes automatically?
  
Back to top
WWW  
IP Logged
 
.:..:
Oldunreal MasterPoster
Developer Team
*
Offline



Posts: 1463
Location: Finland
Joined: Aug 16th, 2005
Gender: Male
Re: BSP error observations
Reply #5 - Nov 14th, 2010 at 12:44pm
Print Post  
As for collision code I painted this primitive image describing it:
www.klankaos.com/downloads/BSPTrace.JPG
So to explain it, there is a simple mathematical calculation (dot product) to figure if a point is on back or front side of a plane (a plane is a surface with infinitive distance to the edges) as-well as distance. So when doing 'trace' line check, simply check where starting point (A) and ending point (B) are located at and figure out closest surface to point A.
So in my example it only needs 10 dot product checks to figure out exactly which surface was hit at and at what distance, while it would be a lot more if there wasn't any BSP tree setup for the collision.
  

Shivaxi wrote on Jul 25th, 2013 at 12:50pm:
...and now im stuck trying to fix everything you broke for the next 227 release xD Tongue

(ಠ_ಠ)
Back to top
IP Logged
 
Hellkeeper
Global Moderator
*****
Offline


Soulless Automaton

Posts: 2780
Location: France
Joined: May 21st, 2008
Gender: Male
Re: BSP error observations
Reply #6 - Nov 14th, 2010 at 1:16pm
Print Post  
@GreatEmerald : I don't understand the situation with your tower zoning...
As for brushes transformation, transforming permanently the builder brush does mean all subsequent brushes made with it will be "permanented".
It's simple to demonstrate : use the snapped scaling brush tool, and double the size of your brush on one axis, say the "width" one, which will be, for our test, along the X axis (which is absolute to the world). When rotating this brush, the rotation will still be applied to the X axis and not the brush's width (which means you will see, at all steps of the rotation, the brush get further deformed to fit the scaling). This is also true of all brushes that are made with this scaled builder brush.
Now, transform it permanently, and both the builder brush and the brush that are made with it, will keep their shape and not be deformed by the scaling (acting as if the scaling was applied to the brush's width, which is relative to the brush's rotation, and not the absolute axis of the world).

As for Nyleve's pond, my opinion is that they zoned it because they are many ways you might look at this direction and not see the pond (most notably when on the other side of the wreck), so they zoned it to avoid all these polys to be loaded uselessely. Of course, I'm no expert, but that would make sense.
  

You must construct additional pylons.
Back to top
WWW  
IP Logged
 
GreatEmerald
Oldunreal MasterPoster
*
Offline


The Great Emerald

Posts: 5361
Location: Vilnius, Lithuania
Joined: May 21st, 2007
Gender: Male
Re: BSP error observations
Reply #7 - Nov 14th, 2010 at 2:19pm
Print Post  
Well, I have towers that have crazy walkways on the sides and spikes protruding out of it. Inside the tower, however, there is only a single subtracted cylinder with a mover in it. If I was to zone off the cylider, I don't think it would make things much better, but if I zoned off the whole tower like the pond in nyLeve, maybe it would be more useful, since when you look at the castle, you can't see 3/8 towers either way.

About the pond - hmm, I'd zone off the building as well in that case. You can't see it from the other side just as well. Zoning off the pond just zones off one rock and a bit of the terrain brush.
  
Back to top
WWW  
IP Logged
 
Page Index Toggle Pages: 1
Send TopicPrint
Bookmarks: del.icio.us Digg Facebook Google Google+ Linked in reddit StumbleUpon Twitter Yahoo