VIS troubles

After recent map compilation I ran into weird issue. Seems like certain surfaces in my .bsp are not properly assigned to visblocks they should belong to. Or it may be severe case of wrongly connected visblocks, I don't know. As result, many surfaces in one particular area disappear under certain viewing angles (or disappear at all), leaving a visual window into either void or other parts of the map. Physically they're there, though, everything is properly clipped, both hitscan and projectile weapons are blocked by those invisible walls. I've already tried chamfering and enclosing any potentially problematic areas (those which were added most recently) with simple solid brushes, but to no avail. Tried various hint brushes layout to help the compiler (although solid brush layout is already simple, pretty much everything but main separating and outer walls is detailbrushed). No fortune so far.

Screenshots follow. Those big white glowing areas are the very vanished surfaces. On the last shot, quite a big area of map can be seen through multiple missing planes.











Here's the source file for map and the compiled bsp:
http://ompldr.org/vYWMwZA/LC_Upright.pk3

I'm totally lost. Any help, even the weirdest ideas about what's wrong there are greatly appreciated.

Normally, this is caused by having off-grid surfaces on the map (e.g. made using rotate tool) that are not marked as detail.

Can you check if you have such? Can you try changing blocksize of the map?

Make the brushes which dissappear Detail-brushes if they don´t touch the void. This should help.

divVerent, I'll try and look now for those.

Maddin, the problem is, most (if not all) of those non-detail brushes are the outer walls (yes, they touch the void) or walls which divide map into general sections - like on the last screenshot, surface of solid brush which should separate the hallway from the main shaft (that hall with tower) is invisible.

---

While looking for erroneous brushes I also increased blocksize to 8192. The result is peculiar - almost everything to the northern side of the problematic spot, except for some surfaces in the pit (seemingly those with negative world Z value) and models, disappeared. There are just 8 portals total now when I load them into radiant. It's like compiler just ignores the existence of BSP geometry and swoops couple of huge visblocks on the map without tying anything to them.
Colored planes are visportals with r_drawportals 1.



wtf.

Situation seems to improve with lower block sizes. With 256x256x256, there's only one gap left. But I don't think it's the right solution, as much more than needed visblocks are generated in this way.

you can also try higher blocksize, just to "tickle" q3map2.

Or, move the whole map by some grid blocks (better at large grid)

It may sound harsh but problems like you have them are caused by a messy layout and a bad brushwork. As far as I can see in the map-file you worked on the grid which is very good. But you didn´t worked very well with caulk: EVERY surface which you don´t see ingame should be caulked! Also try to avoid skewed Structural-brushes, make them Detail-brushes and build a box around it to evite leaks.

As for the blocksize: I always use a value of 0 0 0 for this and then control the portals with hint/skip brushes.

Voila, the magic culprit.
http://clip2net.com/clip/m58111/13159399...-320kb.jpg
Found it (thanks to divverent's advice on lowering blocksize) in the same visblock the gap was in. Yes, it's a single damn brush with zero width. How is that even possible? Moreover, I wonder how and when I managed to create it…

As for caulking everything, I remember being spanked by some more profound Half-Life mappers for not painting everything but the used surfaces with NULL (essentially the caulk analogue in HL). I really tried doing so several times simply by painting every new brush with null and applying actual textures to faces later when needed. Not only it's plain eyerape, it also confused me pretty much when observing basic structure of the map in the 3D window.
Of course, I use caulk/null on the late stages of making the map to remove the surfaces player won't see anyway, e.g. back sides of all kinds of walls/floors/ceilings player can't get around and so on. But is there any profit from, let's say, caulking adjactent sides of two structural brushes? Those won't be compiled anyway, will they? I'd like to know a bit more about this.

Maddin, don't worry about sounding harsh. It's always better than newbie-caring style of talking. It's great to hear rude things about one's work, pampering and learning never go along well.
Or maybe I'm just a masochist, nvm.
I'll take note of blocksize 0, too. Sounds nice, didn't know that automatic block creation can be turned off here.

Of course, I use caulk/null on the late stages of making the map to remove the surfaces player won't see anyway, e.g. back sides of all kinds of walls/floors/ceilings player can't get around and so on. But is there any profit from, let's say, caulking adjactent sides of two structural brushes? Those won't be compiled anyway, will they? I'd like to know a bit more about this.

You should do it the other way around: First build your map out of caulk brushes and then texture it. It´s way easier! And by the way, you can set in the preferences that every new brush which you create has the caulk texture on it, this is very helpful.
So why caulking things? It improves the performance and reduces the compile-time extremely! Don´t underestimate this! Why? Caulked faces are "ignored" by the compiler and won´t be calculated whether they are shown in the game or not.

However, do not make the common mistake of thinking brushes are not visible when they are, e.g. when a player laserclimbs up a wall.

When in doubt, do NOT caulk a brush.

Also, hint brushes can help you out a lot. It can't do magic, but I've had numerous cases when hinting game me significant (from 24 avg. to 50!) FPS gains.

Yes, you´re right C.Brutail, hint is very important. That´s why I always got 50-60 FPS (the maximum) on all my maps.

Well of course, speedy games like Xonotic is should have less possibilities for optimizing by removing faces than some slow-paced games I worked with (like Counter-Strike or even HLDM).
I think in this map I can only caulk safely some out-of-sight insides of decorative rooms player can get in, as well as few other places - like the bottom side of white stairs near that spot where gaps appeared.

I'd also like to note that after I set blocksize to 0 and caulked just some of outer map walls, the .bsp size decreased for 5 MB, or around 17%. Thanks again!

blocksize 0 means "use default", what you want is something like 128, 256, or 512 (default is 1024). note hat the smaller this value, the longer the vis compile will take. (also its _blocksize assuming you use the worldspawn key, and its a vector, so its in the form of "x y z")

Yep, that's the way I set it: _blocksize 0 0 0.

blocksize 0 means "use default"

That's a bit confusing. So, does 0 0 0 value turn off automatic block creation at all, or just tells the compiler to use the default 1024 1024 1024 value?

_blocksize 0 0 0 turns the block creation completely off.