MH-AMC-2040

[Buggie]

Wow. Death spot return? I think I fix it turn some brushes to solid. Where exactly is?

[Feralidragon]

And myths and misinformation about semi-solids keep on spreading...

Build BSP - just build BSP. Also it do it very simple.
Build All - Call Build BSP, after that Optimize BSP, Lighting, patching and so on. All options depends from dialog of Build all settings.
Nether Build All or Build BSP is error free.
Build BSP sometimes produce errors which Optimize fix. And vice versa.

But if simple build BSP get errors, better even not try "fix" it with "optimize BSP". This is optimization, not fix.
Try optimized bad built BSP can fix BSP, of course, but it doesn't mean really fix for it.

That is incorrect.

Build All does a lot more than optimization, it does a complete and proper build of the BSP itself, with optimization being just one of the steps that occurs at the end only after a better BSP tree was created in the first place.
In a big enough map, you can see all these steps in real-time, and you will see there are plenty of differences from start to finish, including at the geometry stage.

Build BSP does the least amount of steps possible so you have a working BSP tree the fastest way possible, but is also meant to be dirty.
When working with semi-solids this is especially true: almost every single semi-solid issue can be traced back to using "Build BSP" instead of "Build All", because the BSP tree is not built well enough, nor the semi-solids applied correctly enough, for them to be error-free.

While it's true that "Build All" is not 100% error free, compared with "Build BSP" it might as well be, the difference is that big.
Trying to use "Build BSP" for a release is like playing with matches, and solving BSP issues using that same button is like trying to put out a fire with gasoline, you will just go in circles and spend hours or days solving issues that could be solved much more easily in minutes.

I have built what might be one of the maps with the highest node-count and highest amount of brushes ever released for this game, so much so that in order to be able to finish building it, the 469 patch and 2.2 editor had to raise the node count limit during the BSP build so it could actually build:
viewtopic.php?t=13704&p=116875
which is filled to the brim with plenty of semi-solids, of all forms, shapes and everything, and you know how much time, in total, I took to solve BSP-related issues?

Maybe 20 minutes, total.
I haven't had a single semi-solid related issue at all: all the issues I had were actually from solids and subtracts, mostly related with occlusion errors (like occluding an area too soon, or holes in the corners), and they were fairly easy to fix by just switching their order around, but the semi-solids themselves always remained unaffected, I never had to loose my sleep over them.

That is, as long as I used "Build All": the moment I used "Build BSP" when I needed faster builds to do some brush intersection work, all the semi-solid issues people generally talk about would all appear.
So no, "Build All" is not only about optimization, it actually does a LOT for semi-solids, and all geometry in general.

Semi-solid brush always draw fully. So if they float in air it is good choice,

That is just patently wrong, in every sense of the word.

Meshes draw fully, I think movers also draw fully (didn't test this one yet, but since they move it only stands to reason that they would have their own tree and render fully), whereas semi-solids: NOT.

Semi-solids are no different from the rest of BSP in that regard: what do you think the BSP cuts in semi-solids are for?
BSP cuts are mostly for occlusion in general, that's pretty much the whole point about BSP as an algorithm: occlusion and zoning.

There is absolutely no difference whatsoever between a solid and semi-solid as far as occlusion goes, in other words: only visible surfaces are rendered, regardless of whether the BSP is solid or semi-solid.
And this is painfully easy to prove: just this weekend I made a small test map which I linked in Discord to debunk something related with semi-solids and zones, and the number of polys or nodes rendered between a solid and semi-solid were exactly the same: the sides that were occluded in both cases weren't rendered.

This one doesn't even make any sense to begin with: why would semi-solids receive any cuts at all if they were to be rendered fully (like meshes)?

If semi-solid intersect with solid - you in trouble. There a lot such cases,

Only if you keep using "Build BSP" instead of "Build All", making this also innacurate.
If even with a "Build All" you have an issue like that, then the problem is not the semi-solids for sure, the problem is the solid itself or the geometry around it, which can be easily fixed most of the time.


Either way, if you want to stubbornly keep using "Build BSP" to solve BSP issues, you're only going to perpetuate the errors and spend a whole lot of time for pretty much nothing.
You may get the map to a stable state doing so after who knows how many hours and rebuilds later, but it will never be as stable as if you used the actual proper option to begin with (Build All), this is just factual.

[Buggie]

Nope.

Build BSP produce command:
"MAP REBUILD VISIBLEONLY="

Build All produce set of commands:
"MAP REBUILD VISIBLEONLY="
"BSP REBUILD"
""LIGHT APPLY SELECTED= VISIBLEONLY="
"PATHS DEFINE"

Each one depends from checkboxes on build settings.

So full build include "dirty" build. And next optimization after that.

---

Automatically merged

If you unchecked in setting all except first - build all do same as build bsp.

---

Automatically merged

About semi-solids - not know exactly how. Possible you right about that. IDK.

[Feralidragon]

Nope.

Build BSP produce command:
"MAP REBUILD VISIBLEONLY="

Build All produce set of commands:
"MAP REBUILD VISIBLEONLY="
"BSP REBUILD"
""LIGHT APPLY SELECTED= VISIBLEONLY="
"PATHS DEFINE"

Each one depends from checkboxes on build settings.

So full build include "dirty" build. And next optimization after that.

---

Automatically merged

If you unchecked in setting all except first - build all do same as build bsp.

You're not disproving at all what I mentioned, you're just telling me what commands it executes.

I never said that the full build didn't use steps from the "dirty" build, of course it does.
All I said was that the dirty build did much less steps (hence being "dirty" or "incomplete", but fast), so it wasn't nearly as complete as a full build.

It's not just "optimization" (even the command you listed is "BSP REBUILD" not "BSP OPTIMIZE"), it does form a better BSP tree altogether and fixes all the issues with the semi-solids people usually have, this is just factual, I can prove and have proven as much with the map I referenced, and I can do so with any map (standard maps were built this way, which can be proven by executing one and then the other, the standard maps will universally have tons of issues with the dirty build).

Later on today I will try to run full builds in the map I mentioned to show you all the steps each one does.


EDIT: To be fair, I may be also be partially at fault by erroneously calling this step "optimization" over the years, because that's what I also thought before (before I actually did some serious experimentation and a substantially more complex map):
https://www.oldunreal.com/phpBB3/viewto ... 25&p=30480
I just looked this up to show you that this is something I have been looking at for a while myself when I did my last maps, and that there was even a bug at the time where those 2 main commands were switched over.

However, as you can attest by this post, made by Dots himself (someone with the inner know-how and access to the actual source):
https://www.oldunreal.com/phpBB3/viewto ... 914#p30479
he doesn't call it "optimization" either.

He defined these steps as Geometry -> BSP, not BSP -> "BSP optimization".
So there's some more food for thought for you, until I get around in showing all the steps each one actually does.

[Buggie]

Firstly I can make simple experiment.
make only "BSP REBUILD" on map with empty BSP. Without "MAP REBUILD".
Result is empty BSP.
It is lead to fact "BSP REBUILD" - transform BSP, not built it from scratch. And "MAP REBUILD" step can not be dropped.

Ok. lets see what "BSP REBUILD" do exactly. And what difference with "MAP REBUILD".
https://github.com/TheBearProject/Unrea ... nEdSrv.cpp
"MAP REBUILD":
csgRebuild
"BSP REBUILD"
bspBuildFPolys
bspMergeCoplanars
bspBuild
TestVisibility
bspOptGeom

How csgRebuild work:
https://github.com/TheBearProject/Unrea ... g.cpp#L265
In loop for all not semisolid brushes:
// Treat portals as solids for cutting.
// Perform this CSG operation.
bspBrushCSG

after loop:
bspRepartition
TestVisibility

// Remember leaves.
EnlistLeaves

In loop for all semisolid brushes:
// Compose all detail brushes.
// Perform this CSG operation.
bspBrushCSG

After loop make two loops:
// Optimize the sub-bsp's.
bspRepartition // for iFronts
bspRepartition // for iBacks

After all
// Build bounding volumes.
bspOptGeom
bspBuildBounds

What is that bspRepartition? It is just shortland for
bspBuildFPolys
bspMergeCoplanars
bspBuild
bspRefresh

Wow. It is same 3 steps from full rebuild!

Look like in simple words, "BSP REBUILD" just additional step for repartition entire BSP instead of walk on sub-bsp.
So it can be called as "optimize bsp". Also it can be called many times, without rebuilding geometry. And this work.

So we can call as "optimize bsp".

[Red_Fist]

"I have been looking at for a while myself when I did my last maps,"

But here is the thing, a lot people build maps without following any rules or order, so fixing as opposed to building a new map. You have to read between the lines and undo weird things to make it work wight.

I don't care what build buttons there are, LoL

It's makes me jealous to see a total crap map, built all wrong, and the stupid thing works

[Feralidragon]

Wow. It is same 3 steps from full rebuild!

Look like in simple words, "BSP REBUILD" just additional step for repartition entire BSP instead of walk on sub-bsp.
So it can be called as "optimize bsp". Also it can be called many times, without rebuilding geometry. And this work.

So we can call as "optimize bsp".

Again, you proved nothing against what I was saying before.
You're so focused on the trees that you're missing the entire forest.

I hope you do understand that calling the same set of functions again is not "optimizing" anything by itself, nor even really necessarily "repeating" anything by itself, especially when we talk about algorithms that work their way from a previous state to the next state, and such is the case of BSP: you take a previous state of the tree and do something more to it, whether it is to rebuild a part of it, optimize it or fix it.

If those functions are, in your opinion, "optimization" functions of any kind, then you're implying that the first BSP build is already itself an optimized build, which is obviously false, so your argument doesn't work very well.
The fact that the same functions are used to run another step, with a fairly different outcome for the BSP tree and with an entirely different feedback in the editor itself, means that inside those functions they're not necessarily doing the exact same thing that they did in the first step, or that they're working with a different state that produces the observed outcome I mentioned.

Furthermore, you forgot that at the end the second step runs 2 extra functions to finalize the build, one of them which seems, to me at least, to be fundamental for establishing zones with semi-solids, because from your own description the semi-solids are only partitioned and built, but then no visibility testing is executed to form the potentially newly created zones (if I understand correctly what TestVisibility does), which is a major difference already from both steps.

To not mention that you're referencing a very old codebase (version 200, when the latest official UT version is 436, with 469 having the Unreal 227 BSP builder which has been improved as far as I know), so those steps may not even be entirely applicable nowadays, not even for a 436 code base.

That's not to say they're not valid, maybe that's how it's still done nowadays, but if you want to make a point, you cannot use old code bases and tell that's how they work today, because that might not be necessarily true.
But, for the sake of argument, even if we assume that code to be still what is working in practice today in the newer builds, it's still an irrelevant detail to this discussion, because you failed to demonstrate that it just "optimizes" the BSP.

As a matter of fact, optimization-specific steps are labeled as such by the function names, namely bspOptGeom, which is executed in both, and maybe bspMergeCoplanars can also be considered an optimization step, arguably.

So I stand my ground on this: the second command does optimize the BSP build, that was never in question, but it also performs extra steps to build a proper BSP tree that actually works well enough with semi-solids.
Even if it takes the previous state of the BSP tree and modifies it do so using the same kind of function calls, the fact remains that it produces results consistent with my observations, namely taking something beyond broken and turn it to something either completely or almost fixed, and it does have critical differences from the first step especially in regards to zoning.

Let's not forget what "optimization" means: it means to improve on something without changing its already established properties.
In other words, optimizing means taking something that already works fine, but you then do something to it to work better ("faster" for example in case of code, "less nodes" in the case of BSP).

If something works consistently bad, and then you do an "optimization" to it and then it suddenly works fine, that's not an "optimization", that's a "fix", by definition.

With that in mind, and following RedFist's great insight here:

It's makes me jealous to see a total crap map, built all wrong, and the stupid thing works

I have put together a map which I called SemiClusterFvck, which is a map with all sorts of "wrong" things you can do as far as semi-solids go and whatnot, mapper nightmare fuel, having namely:

• all types of relevant brushes: solids, semi-solids, non-solids and subtracts, many in compromising positions;
• all types of odd shapes, from low poly to higher poly, from cubes to cylinders to cones;
• rotated in all directions;
• some small others large;
• some even completely off-grid, both in position and rotation;
• intersecting each other: solids with solids, semis with semis and solids with semis;
• a water zone composed by solid and semi-solid walls, and multiple non-solid water zone portals, also built in a very obtuse way;
• and more...

As a matter of fact, I made 3 variations of the same map, which can be downloaded and looked at here:

SemiClusterFvck.zip

(934.99 KiB) Downloaded 11 times

All 3 variations, A, B and C are exactly the same map with the same BSP, with just very tiny differences between them with different outcomes.

A: This is the original one, a real clusterfuck of a map, with tons of BSP issues, all related to the usage of semi-solids, where only "Build BSP" was used to build it:

• the map is completely underwater, because the zone with the semi-solids wasn't formed at all (off to a good start already);
• across the map you can see all sorts of BSP errors: occlusion bugs (invisible surfaces) and tons of collision issues.

B: This is exactly the same as A, with the only difference being that it was built using "Build All", nothing else differs:

• the map is no longer underwater, the water zone is correctly formed;
• all occlusion bugs were fixed, none of them remain in sight (that I have seen at least);
• the big cylindric platforms however have still a couple of collision issues in very specific spots.

C: Same as B, also using "Build All", but the change to fix the remaining issues was the classical "turn to solid", but just the problematic platforms (2 brushes only), and now all collision issues seem to have been fixed across the map, and the rest of the semi-solids can remain as is without any issues (occlusion and collision all working properly).

The only remaining problem with C is that it now has too many zones (9 instead of just 2), but this is caused by the literal clusterfuck of tons of brushes intersecting each other (the classic semi-solid with solid mess which may happen at times), off-grid, completely at random, which creates some internal issues, but it only created 7 extra zones despite the extreme mess the whole thing is, meaning that normally you wouldn't have this problem either if the map is properly built.


This is to demonstrate that from A to B around 90-95% of all BSP issues were immediately fixed by just using "Build All" instead of "Build BSP", making the remaining 5-10% incredibly easy to fix afterwards from B to C by just turning one or another shape into a solid, or just by moving things around, without compromising the rest of the map.

There's an old saying: against facts there are no arguments.
The results are on sight, and you can debate why or how they happen all you want, but the fact remains that the "BSP REBUILD" from "Build All" that was mentioned seems to be fundamental to originate a stable map regardless of the direction you look at it, and you can reproduce the same thing yourself at this point, so there's nothing more for me to say.

For those still wanting to waste their time with the "Build BSP" and go around in circles fixing BSP issues, be my guest, I myself will rest assured that any map I want to design myself, I can dedicate pretty much the full time in designing it rather than fixing it, so do with this what you will, I am done with this subject for now.

[Buggie]

OK i got your point now.
BSP is not good, ALL is good. OK. look like exists some bugs on full build because sometimes BSP work fine, ALL produce HOM or bugs.

For example portal bug: https://github.com/OldUnreal/UnrealTour ... issues/520

But from point of view regular user this look same:
Sometimes BSP build bugged and "ALL" fix it. (you say this is intended - OK)
Sometimes BSP build fine, and "ALL" screwed up it. (because of bugs, as I understand now)

So sometimes for get worked map need try usual BSP if this fine, why not? If "ALL" screwed something, and no visible difference, why not?

[Feralidragon]

So sometimes for get worked map need try usual BSP if this fine, why not? If "ALL" screwed something, and no visible difference, why not?

Unless the whole map is a cube in a room, then "Build BSP" will always produce unexpected and unstable results, especially when using semi-solids.

If you have more than a couple of semi-solids around, with "Build BSP" you will have to inspect every single one of them to make sure you don't have any occlusion nor collision bugs, if you don't you cannot really tell that the map is fine (and I have been there myself, trust me, only a few years ago myself before I realized how much better "Build All" was).

With "Build All" you can rest assured that occlusion bugs are not a thing, and you only have to potentially fix collision and HOMs caused either by solids, or solids on semi-solids, which is the case I have shown above.

You can then tell me "well, then I will just use solids, problem solved", at which point you loose the major benefits of semi-solids: less nodes, which means the ability to do bigger or more detailed maps, or just maps with a higher performance.
And you may still run into trouble by having too many solid cuts running across the map.

So even if you do not perceive an issue with "Build BSP", and then get an issue with "Build All", then it's actually preferable to solve the issue with "Build All" than stay at "Build BSP", because "Build All" will still be more stable across builds than "Build BSP", and generally issues with "Build All" are easily solvable without compromising the stability of the rest of the map.

This is especially true for a map you are still iterating through and have not finished yet: even if at one point it's stable with "Build BSP", it's very unlikely for that to remain that way using that building method alone.

[Red_Fist]

I finally fell through the damn platform.

I am working on this map and that problem will be fixed, among other stuff. (not any mechanics or gameplay.)

I hope you uee my edit, and maybe redo some of the gameplay. The bots just run the the exit, but it's great you are making some new MH stuff.

I always use full build, never used any other cuz I want to know if it works as I am working, not that I need faster rebuilds.

[EvilGrins]

Found another "hole". Clearing out monsters, there's an alley of sorts near the back where I noticed an IceSkaarj and a military Skaarj... but the military was bent at a weird angle.

When the IveSkaarj got next to him, it also got twisted.

So, when I moved to where they were... I got killed.

[Buggie]

I finally fell through the damn platform.

Where?

I hope you uee my edit, and maybe redo some of the gameplay.

Which edit? Where I can see it?

Found another "hole".

Thanks. I will try fix it.

[Red_Fist]

Not done yet.

EDIT;

That was the one I said earlier, I replaced those fence brush's with movers, problem gone.

I think I will just make an alternative fixed working version, and you can redo it or not.

I repaired several things so far, just needs a little more messing around, and fixes.

[Buggie]

Found another "hole". Clearing out monsters, there's an alley of sorts near the back where I noticed an IceSkaarj and a military Skaarj... but the military was bent at a weird angle.

When the IveSkaarj got next to him, it also got twisted.

So, when I moved to where they were... I got killed.

Because here portal with ZoneNumber = 0. So technically there void. Engine instantly kill all actors which found in void.
This void caused by surface with invisible flag.

More info: viewtopic.php?p=131564#p131564

Dead spot immediately gone after make surface not invisible but with transparent texture.

---

Automatically merged

Wow. Now I not surprised why this map so bad.
291 place for potential HOM or dead spot.

Also, if fix such, not forget recheck after build invisible surfaces. Because if on Brush set PolyFlags = 1 (or any mask with 1), all surfaces of this brush get flag invisibility, and you can not uncheck it.

---

Automatically merged

V4
- fix dead spots.
- fix few other problems.

viewtopic.php?p=131014#p131014

[Red_Fist]

I am still making another version, getting there, got too much yard work before suck ass winter. !!!