Problems compiling

[Katastic Voyage]

I made a "huge" map. But I've never made a map in Hammer before so I've run into numerous newbie errors.

For the fun of it, I remade the Space Station 13 BoxStation map:

https://tgstation13.org/wiki//images/d/d1/Boxstation.png

Here's an old progress photo (it's basically done now)

https://imgur.com/a/gxXByFN

Another photo showing size:

https://i.imgur.com/NQVuivL.png

I've got a couple problems. First, do these bounding boxes indicate some sort of skybox failure / leak?

https://i.imgur.com/mJlOs8f.png

I'm not sure if Hammer is showing that because VBSP only got "that far" before failing, or if it's specifically that area.

When I could get it to compile, and run Gmod with mat_leafvis on, the entire game runs at like 1 FPS because of how many there are. I'm not sure if that's normal or not.

Currently, VSBP does compile. (I have had plenty of issues with T-junction errors before, currently not though.)

WriteBSP...
done (2)
writing c:\users\katastic\desktop\dev\hl2 mapping\test6 - try newer vbsp\boxstation.prt...Building visibility clusters...
done (0)
Creating default LDR cubemaps for env_cubemap using skybox materials:
skybox/sky_day01_01*.vmt
! Run buildcubemaps in the engine to get the correct cube maps.
Creating default HDR cubemaps for env_cubemap using skybox materials:
skybox/sky_day01_01*.vmt
! Run buildcubemaps in the engine to get the correct cube maps.
Finding displacement neighbors...
Finding lightmap sample positions...
Displacement Alpha : 0...1...2...3...4...5...6...7...8...9...10
Building Physics collision data...
done (4) (1663177 bytes)
Placing detail props : 0...1...2...3...4...5...6...7...8...9...10
Compacting texture/material tables...
Reduced 2871 texinfos to 2082
Reduced 79 texdatas to 78 (1132 bytes to 1124)
Writing c:\users\katastic\desktop\dev\hl2 mapping\test6 - try newer vbsp\boxstation.bsp
Wrote ZIP buffer, estimated size 105885, actual size 105671
10 seconds elapsed

However, VVIS just sits there. (Thing is, it used to compile fast. At some point it exploded in complexity)

vvis fast verbose outputs:
---------------------------------------------------------------------
8212 portalclusters
17650 numportals
BasePortalVis: 0...1...2...3...4...5...6...7...8...9...10 (23)
cluster 0 : 4636 visible
cluster 1 : 4636 visible
cluster 2 : 5113 visible
cluster 3 : 5113 visible

[...] (~8,000 lines)

cluster 8208 : 5678 visible
cluster 8209 : 5224 visible
cluster 8210 : 4983 visible
cluster 8211 : 4529 visible
Optimized: 2506685 visible clusters (7.63%)
Total clusters visible: 32868803
Average clusters visible: 4002
Building PAS...
Average clusters audible: 7983
visdatasize:13999268 compressed from 16949568
writing c:\users\katastic\desktop\dev\hl2 mapping\test6 - try newer vbsp\boxstation.bsp
33 seconds elapsed


I'm wondering if I just leave vvis running for hours, it'll finish. I didn't realize my world was "so huge" compared to others as my actual GEOMETRY consists of very simple runs of cubes. (It was each tile = 1 cube = 1 brush. But I "optimized" that into spans of walls, and rectangular floors to reduce the complexity.)

What I'm not sure is, if I'm doing something explicitly "wrong" that's making the complexity explode, or if my map is simply huge and I've hit the Source engine's hardcoded limits.

 

[Da Spud Lord]

I've got a couple problems. First, do these bounding boxes indicate some sort of skybox failure / leak?

I've never been sure what those red lines are for. They can be toggled with the "i" key. They are not an indication of any errors, AFAIK. I'm not seeing any errors in the provided compile log.

When running in Gmod, can you give us more info about when you got such low framerates? Did you only get low framerates when using mat_leafvis? Did you only get low framerates when you didn't run VVIS? (VVIS is a very important step in map optimization.)

VVIS compiles get exponentially longer on larger and more complex maps. VVIS has to perform a line-of-sight check between all visleafs in the map; every visleaf is tested against every other visleaf. This process can be shortened by properly applying certain visibility optimization techniques, such as making proper use of func_detail (which can reduce the number of visleaves when using complex geometry). I've found that adding func_visclusters can make a massive difference in VVIS compile times.

 

[Katastic Voyage]

Okay so I found a couple things.

FIRST, $translucent doesn't occlude VVIS. That's obvious if you RTFM but it's certainly not obvious for a newcomer! So literally every single cube that was a "window" became a completely empty space as far as VVIS was concerned and became thousands upon thousands of subdivisions where tiles would end at empty space (the windows!).

So, as a stop gap, I converted all windows to $alphatest. Which isn't proper, but it compiles. In retrospect, a 2-D game like SS13 with transparent windows is actually SATAN when it comes to a Quake 1-era "BSP" style map drawing system. (From what I'm told Unreal 4 and Source 2.0 engine don't use BSP's at all and doesn't require compiling the map like that. U4 supposedly uses "Hierarchical Clustering" but there's no data on it.)

Setting to $alphatest makes it compile WITHIN SECONDS. That's the key! (~30 seconds for the whole map, down from ~3-4 hours before.)

However, every change I've made since then (thank god for backups) has only made it worse!

My next problem is, I'm leaking like crazy and brushes are too big / automatic areaportals aren't finding candidate brushes! So my question is:

Given that top down map I showed you:

- Walls are cubes (64x64x64 hammer units).

- Floors are squares (64x64x[minimum] hammer units). Is that okay? Should you ever have brushes that have no width? Do they leak?

- Spans of walls (say, 5 cubes horizontal, were converted to a single cuboid/stretched cube to lower brush/face counts.) Likewise with floors where possible.

Questions

- Is it okay that floors have SIDES even if they're shrunk to nothing? Or should you manually add the SKIP tool texture (literally hundreds/thousands I'd have to change!) any faces that aren't needed?

- I thought maybe you can't have any real textures facing the outside world, so I manually (40+ minutes) went underneath my world and set most of them to SKIP... and they leaked like crazy!

- So, I built a test world with a couple cubes (instead converting this huge map each time). I tried ultra-thin walls and they didn't seem to leak. However, when I set them to SKIP, they leaked! Even though they had an inside face, the outside faces--when converted to skip--leaked! I thought you only needed one face to block a ray, not a whole volume? Is that normal?

- What IS the proper way to 1) seal a world and 2) use skyboxes? I've seen videos but they don't really have a world like mine. Is it okay for BRUSHES to touch? Can I have a thin ceiling, then touch a skybox on the same snap grid above it?

- How much is too big of a skybox (or other) brush? Because it seems like I'm getting "too big" brush errors because it's trying to splice walls into the ceiling/skybox and it's too far away from any actual ceiling edges to find them and connect.

- Is there anywhere you see on my kind of map where hinting, visclusters, etc would be an obvious candidate?

- I've seen my pointfile go STRAIGHT THROUGH THE CEILING. I tried making the ceiling 1 cube tall, 4 cubes tall. Huge. And it'll fly right trough it. Whether it's skybox or normal texture. My only guess is, these "large" ceilings are too large and get removed, and then the BSP/VVIS just flies right through it like it's not there (because it got deleted) and Hammer isn't telling me so it simply LOOKS like it's travelling through a real brush.

ANY INSIGHT POSSIBLE would be really appreciated. Thank you. I put so much time into making this, and now I've spent even more than that JUST trying to diagnose compile errors.

 

[Da Spud Lord]

Setting to $alphatest makes it compile WITHIN SECONDS. That's the key! (~30 seconds for the

Sounds nice, but are you sure the shorter compile time isn't because your map is leaking? Leaking maps won't be optimized by VVIS.

- Floors are squares (64x64x[minimum] hammer units). Is that okay? Should you ever have brushes that have no width? Do they leak?

All solids in the Source engine must have a volume of at least 1HU cubed. If a solid has a width of 0, it has no volume. So no, you shouldn't have brushes with no width. Even if it's only 1HU, your solids should always have a width.

- I thought maybe you can't have any real textures facing the outside world, so I manually (40+ minutes) went underneath my world and set most of them to SKIP... and they leaked like crazy!

Having textures facing the void is totally acceptable. In fact, in a non-leaking map, VBSP will automatically remove brush faces that are exposed to the void (but not the entire brush). What's not acceptable is having the skip texture on the same brush as a normal texture. The skip texture should only be used in conjunction with the hint texture, otherwise it can create problems with brushes extending past their bounds. What you're looking for is the nodraw texture, a texture that does exactly what it sounds like: it tells the Source engine to not draw that face. Note that brushes with the nodraw texture can still seal the map and block visibility.

- What IS the proper way to 1) seal a world and 2) use skyboxes? I've seen videos but they don't really have a world like mine. Is it okay for BRUSHES to touch? Can I have a thin ceiling, then touch a skybox on the same snap grid above it?

Yes, brushes can touch each other and even overlap. Brush faces that are positioned against each other are removed by VBSP.

- How much is too big of a skybox (or other) brush? Because it seems like I'm getting "too big" brush errors because it's trying to splice walls into the ceiling/skybox and it's too far away from any actual ceiling edges to find them and connect.

I'm afraid I'm not sure what you mean. Can you provide screenshots? A copy of your compile log would also be great. There is a brush size limit, but it's pretty high. Your map looks like it could be big enough that a single brush stretching over the entire thing could hit that limit. I'm pretty sure simply splitting the brush into multiple adjacent smaller brushes will work.

- Is there anywhere you see on my kind of map where hinting, visclusters, etc would be an obvious candidate?

Hinting is useful when you're worried that visleaves might not split in the most optimal way, as shown here. You can also split corners like this:

This won't really help a great deal unless we're dealing with well-detailed hallways or hallways that see lots of action take place in them.

Visclusters can be used in any large, open areas with lots of visleaves that can all see each other at any given moment. This won't make anyone's game run faster, but it will reduce your VVIS compile time significantly if used right.

You can learn about other optimization techniques in the link I keep referencing, or in the optimization bible. It's a big read, but worth it if you want to become a good mapper.

- I've seen my pointfile go STRAIGHT THROUGH THE CEILING. I tried making the ceiling 1 cube tall, 4 cubes tall. Huge. And it'll fly right trough it. Whether it's skybox or normal texture. My only guess is, these "large" ceilings are too large and get removed, and then the BSP/VVIS just flies right through it like it's not there (because it got deleted) and Hammer isn't telling me so it simply LOOKS like it's travelling through a real brush.

Compile log is usually a great gauge of what VBSP is doing. (VBSP does leak testing and generates pointfiles.) However, if VBSP is failing fatally (which is what I think VBSP does when it encounters a large brush), then it might not even be generating a pointfile and you might be seeing an old pointfile.

This is a really useful tool for analyzing compile logs, but it's not perfect. There are some errors that it won't identify. Posting it here or just reading it yourself can sometimes reveal errors just as well or better.

 

[FloofCollie]

It sounds like it may be worth checking out documentation of the BSP compiling process.

 

[henke37]

If you have issues with transparency then perhaps you should use simpler holes for vis purposes. Turn tiny separation geometry intro detail geometry so that it's ignored for vis purposes.