BSP secret revealed

[Leo T_C_K]

Apparently I found out that different Unreal or UT versions of UnrealED have different results in rebuiling, I found most acurrate and about no bsp bugs when map is rebuilt by the editor found in 220, but fixed version of that.
I found that out while messing with the UPSX maps and spent endless times trying to rebuild it and optimize the map without any holes.

Could someone port this better BSP builder over to 227?

[Smirftsch]

Although it would be VERY interesting to see why there are differences at all and what differences there are, there is no way to do so. The 220 code is not available.
Also UED is just some gui, a frontend if you wish, it does itself nothing regarding bsp building. The interesting stuff would be in Editor.dll.

Many things rely on maths functions which we tried to clean up and enhance as much as possible. If we would know (feasible) ways to improve it more we would have done already.
Also creavion reported me better results in building with current 227g. Did you compare against it too?

[Leo T_C_K]

Yes I compared it against 227, but still 220 got best results.

Try download this:
http://www.unrealtexture.com/Hosted/Leo ... nother.rar

[Smirftsch]

what map did you use to compare? Can you send me a sample also with a hint to critical places ? Maybe this gives me a chance to try a bit with it. I'm no mapper you know, so this is always not easy for me to reproduce.

The 220 directory will be of little use unfortunately. I have v220 installed also but as said, without the sourcecode there is nothing I can read out or compare.

[[]KAOS[]Casey]

were the ifdef LEGEND checks introduced in 224? I know they're in the headers in a lot of places, maybe in bsp building too?

[GreatEmerald]

Maybe you could get something from the engine.dll function exports? It's something similar to headings I believe.

It's good for statistics, anyway. The 227 Engine.dll has 2664 function exports, compared to 2091 from 226b, that says something, nice work

[Leo T_C_K]

The system folder is a bit different, the one I provided, it doesn't have unrealshare and unreali though (which were bit altered for unreal psx too, but not much), but as for maps to try it with.
Download this one, try E1L1A, rebuilding it for example with setting at 4, if you rebuild it with later ued you can see holes in some places etc, but with this it looks perfect..

http://www.unrealtexture.com/Hosted/Leo_T_C_K/maps.rar

[Leo T_C_K]

Interesting is that when you export the map the brush order gets messed up and all kind of holes appear, bah I hate Unreal BSP really.

[Smirftsch]

found that in render, not sure if really related, but maybe it helps:


// Force View Zone
//
// Render the poly regardless of its zone mapping.
//
// During the zone mapping process, polys will sometimes be flagged as part of
// Zone 0, causing them to be invisible when the player is within the level.
//
// Level designers can detect this class of hole by moving "into geometry"
// (i.e., outside the level) while viewing the level from an editor window
// set to "Zone/Portal View."  If the hole is replaced by a polygon colored
// unlike the rest of the polygons in the zone (usually dark gray), the "hole"
// can usually be patched by setting the PF_ForceViewZone flag.
//
// The patch can immediately be verified by moving inside the level.

[GreatEmerald]

That's interesting, but where is PF_ForceViewZone? In ZoneInfo? In surface properties? In brush properties?

[Smirftsch]

its a flag for Actors (such as in Actor.uc) and not really used so far (yet) in uscript. But this method could be used maybe to see if its a related problem.

[Hellkeeper]

That's interesting, but where is PF_ForceViewZone? In ZoneInfo? In surface properties? In brush properties?

In the surface properties, it's a flag.

[GreatEmerald]

Thought so... But it was used in the Wheel of Time, and ported over to Unreal that flag just makes surfaces unlit.

[Smirftsch]

regarding the notes above it does more than just making something "unlit"

[GreatEmerald]

I was referring to the UT UnrealEd, though. Not tested on Unreal.

[Smirftsch]

Leo, did you cross test this result with any new map to confirm, based on 224+ and the original PC maps? Not that this result is just better on older and/or PSX maps and doesn't apply to newer builds.

[Smirftsch]

another possibility:

//PortalBias -- added by Legend on 4/12/2000
//
// PortalBias enables level designers to control the effect of Portals on the BSP.
// This effect can range from 0.0 (ignore portals), to 1.0 (portals cut everything).
//
// In builds prior to this (since the 221 build dating back to 1/31/1999) the bias
// has been 1.0 causing the portals to cut the BSP in ways that will potentially
// degrade level performance, and increase the BSP complexity.
//
// By setting the bias to a value between 0.3 and 0.7 the positive effects of
// the portals are preserved without giving them unreasonable priority in the BSP.
//
// Portals should be weighted high enough in the BSP to separate major parts of the
// level from each other (pushing entire rooms down the branches of the BSP), but
// should not be so high that portals cut through adjacent geometry in a way that
// increases complexity of the room being (typically, accidentally) cut.
//

[Leo T_C_K]

Leo, did you cross test this result with any new map to confirm, based on 224+ and the original PC maps? Not that this result is just better on older and/or PSX maps and doesn't apply to newer builds.

What result do you mean?

[Smirftsch]

tried E1L1A with current 227g and in all map I found only 1 bsp error at the top of one waterfall. Doesn't seem to be so bad to me....


I meant better BSP building with 220 compared to newer versions.

[Leo T_C_K]

Yes but with 220 the bsp hole in top of waterfall isn't present (plus it doesn't do only that, but also the water is not present sometimes etc due to zone leak), but I didn't really try any other maps than this. When I did MH/coop version of E2L7, then I had better result with 227f btw, but I didn't try it with 220, I am just comparing 225 with 227 on that one.

But I rebuilt it in 220 and moved the waterfalls a bit, it made few temporary bsp holes (due to me moving the waterfalls a bit, it shows how crap Unreal BSP really is) which are visible from certain angles only or flicker and stuff at the first waterfall area when going towards the place with fly and stuff, but I don't care about it, since it is visible only when you go through certain angle and it more like flickers.

[Smirftsch]

after setting Ignore Portals to 100 (equal to pre 221 according to the comments above) even that bsp hole was gone.

[Leo T_C_K]

after setting Ignore Portals to 100 (equal to pre 221 according to the comments above) even that bsp hole was gone.

That hole is gone but there are holes under the waterfall instead, I tried, but latest ver I have is 227g_28, so it still is not perfect and worse than 220.

[Smirftsch]

worse...I'd say different, the question is- where is the difference.
I don't have the 220 code, so I can't easily compare, but I very much assume its only a very small change (which maybe even can affected due to some option).
A lot of testing through all settings is required here.

Edit: after setting optimization to "Lame" I wasn't able to find any BSP holes at all anymore. Maybe optimization failing?

Edit2: It seems this option is very misleading. "Optimal" optimizes for number of polygons not for best quality.
Indeed "Lame" produced in my test about the double amount of polys, but no bsp holes anymore. Could be the difference in 220.

Edit3: after comparing Polycount I'd assume it equals "good" in ued2, to much for "optimal", but to low for "lame"

[Leo T_C_K]

I haven't tried the lame or good, but thx.

[GreatEmerald]

That's interesting, I'd assume lame causes only a loss in framerate, but doesn't make the map file itself bigger? If so, these days the lame optimisation would actually be the best one...
And what about the last slider, balance tree vs minimise cuts?