I suck at controlling VVIS

Snowbat

L4: Comfortable Member
Apr 23, 2013
165
74
So I know I'm bad at optimizing and I'm bad at fixing vvis. However, my map that normally took about 1 hour to compile with full VRAD settings, today took over 4 hours. I mean, what the fuck right?
I changed one small thing (added an extra hole in a wall for the robots to have a flanking path) and my compile time skyrocketed. No idea why. I func_detailed the broken wall brushes...
I put the log in attachment.
https://www.dropbox.com/s/pgq4dcbc9jeo4s0/mvm_yucatan_halloween_b1.log?dl=1
 

worMatty

Repacking Evangelist
aa
Jul 22, 2014
1,257
999
VVIS calculates which portals every portal can see. So if you knock a hole in to a wall that connects two areas, the portals in those two areas will then see each other and so more calculations need to be done.

If your VVIS time is taking up the largest portion of your compile it is a bit concerning. Would you like to post your VMF for us to take a look at?
 

Snowbat

L4: Comfortable Member
Apr 23, 2013
165
74
VVIS calculates which portals every portal can see. So if you knock a hole in to a wall that connects two areas, the portals in those two areas will then see each other and so more calculations need to be done.

If your VVIS time is taking up the largest portion of your compile it is a bit concerning. Would you like to post your VMF for us to take a look at?
It was already a hole before. It was an open window and I turned into a bigger hole so robots can run through.
I'll have to post the VMF if the next compile takes so long again.
 

Hyperion

L16: Grid Member
aa
Jun 8, 2015
840
659
I dont know how much these affect

NG: Map using power 4 displacements, terrain physics cannot be compressed, map will need additional memory and CPU.
done (1) (3715733 bytes)
Static prop models/props_foliage/shrub_01a.mdl outside the map (-1467.00, -1864.00, -82.00)

But you should fix those. Also I'm interested about your hardware
 

tyler

aa
Sep 11, 2013
5,102
4,621
Well one of those is a leak, which will mess things up pretty bad. You need to seal your map to prevent those, which will help a bit.

You should also not use P4 displacements. Power 2 or sometimes 3 should be all you're using in 99.9% of situations. To put it in perspective, out of all the years I've been working in Source, I've never used them. That won't affect compile time though.
 

Snowbat

L4: Comfortable Member
Apr 23, 2013
165
74
Yeah I know about the displacements now. I already vowed not to do P4's any more and to do mainly P2's. I converted a lot of my P3's to P2's in the meantime.
I found that model outside the map. No idea how that fucking thing got there. I'll try another compile tomorrow and see.

Thanks gentlemen.
 

grazr

Old Man Mutant Ninja Turtle
aa
Mar 4, 2008
5,441
3,814
I dont know how much these affect

NG: Map using power 4 displacements, terrain physics cannot be compressed, map will need additional memory and CPU.
done (1) (3715733 bytes)
Static prop models/props_foliage/shrub_01a.mdl outside the map (-1467.00, -1864.00, -82.00)

But you should fix those. Also I'm interested about your hardware

You should also not use P4 displacements. Power 2 or sometimes 3 should be all you're using in 99.9% of situations. To put it in perspective, out of all the years I've been working in Source, I've never used them. That won't affect compile time though.

As i understand it, the main problem with power 4 displacements is that because people tend to use common size faces when converting a face into a displacement it vicariously leads to a closer proximity of the vertices as a general rule when using the higher power. For example, a power 4 displacement on a large brush that one might use in a detail area that covers a large amount of ground will not be such a big deal, although it would be ideal to use multiple smaller brushes of a lower power for practicality sense. The problem the compiler has with P4 displacements is that high proximity of the vertices can, in the worst case scenario crash the compile tools altogether.

Armed with this knowledge you should also understand that the same principle holds true even for P2 and 3 displacements. Having tiny displacements even of the lower powers will yield the same problem, thus it is not inherent of P4 displacements to be bad, you're just less likely to happen upon this problem with P2 and 3 displacements because you're less likely to create faces of the size where this will be a problem.

The only inherent issue with P4 displacements is buggy physics in game.

I realise the end result is the same, that they should be avoided, i just wanted to clarify so that people understand what is happening.
 

Tumby

aa
May 12, 2013
1,084
1,192
Code:
material "boo_textures/boo_mayan_floor2" not found.
Material not found!: BOO_TEXTURES/BOO_MAYAN_FLOOR2

1 degenerate faces

physics               [variable]     3715733/4194304  (88.6%) VERY FULL!
These are the only concerning things I found that haven't been mentioned yet, except for maybe the last one.
 

ics

http://ics-base.net
aa
Jun 17, 2010
841
541
1 degenerate faces - this error is insignificant and propably happens to everyone who has more than some displacement work within a map.
 

Snowbat

L4: Comfortable Member
Apr 23, 2013
165
74
The full physics is because of the numerous displacements. Has been like this for at least 10 versions so that's not what causes it. Removing that stray model that caused a leak also didn't help the compile time... the fuck is happening.
I guess I'll have to upload the VMF.
 

Pocket

Half a Lambert is better than one.
aa
Nov 14, 2009
4,694
2,579
Well, shoot, now I've got VVIS stuck in a seemingly endless loop as well, after making a minor change that didn't create any leaks or produce any errors. I'd love to know what we figure out.
 

Pocket

Half a Lambert is better than one.
aa
Nov 14, 2009
4,694
2,579
I'm curious if you've tried compiling it through VBCT and watched where it hangs up. I tried it, and it seems to get bogged down during the PortalFlow step.
 

tyler

aa
Sep 11, 2013
5,102
4,621
The main thing is there's no hinting being done and very little func_detail. You've got the obvious func_detail stuff done, but not enough.

Qk7DxiK.jpg


Look at all these portals! This is why it's taking forever. That smaller ziggurat and these walls right at the bottom should be func_detail, and the ground needs to be rethought somehow. A big hint would be the quick fix, but I don't know if it's the right one. There's a lot of complex geometry in the map and as far as I can see almost none of it is hinted at all?

Which means even in simpler areas, you're calculating way too much stuff:

GDNjPar.jpg


Would you like my help with optimizing this, or would you like to try it yourself? I don't mind. The map is simple enough (benefit of MVM!).
 

tyler

aa
Sep 11, 2013
5,102
4,621
OK, here's a VMF for you that's a little optimized. The main thing I did was add hints and func_detail things. Sometimes you just missed something that should have been func_detail or you had clearly just forgotten about it. I also removed some brushes stuck in other brushes.

I believe I have a better computer than you based on what you said your compile time was. But I don't think it will be nearly as long anymore.

Sometimes you didn't func_detail correctly though. Here's an example:

CyQAhgV.jpg


You had the selected brush set as func_detail before, when in fact it's better to square this corner off. (I also hinted across the entire face of this.) Here's all the hidden func_detail there:

zok2LyC.jpg


Previously, you had much of that geometry cutting VVIS. There's no real reason to. You could extend the bottom brushes to the floor, I guess, but just making the whole thing func_detail is barely different in an area like this one.

Here's another area I really cleaned up:


flOsuHI.jpg mfgHlro.jpg

This is the only staircase in the map I didn't completely func_detail btw, and the reason is because this is the only one where it's significant enough that it could stay. But I still made everything flush. Note also the change in wall decorations. I did that sort of trimming in many areas around the map.

Also, you frequently func_detail things that don't really need to be func_detail. For instance, in another part of the map, you have the detail of the god thing recessed into a wall:

OJbu2tN.jpg


There's no reason to func_detail that. In fact, the only brushes that need to be func_detailed are the outer bluish trim brushes. Since those are func_detail, if players render the visleafs up here, they're going to render the empty area of nodraw on the inside of this. It's not a big deal for performance probably, since it's just a small hole, but it's the principle I guess.

I also put some areaportals in near the start. You could put a func_areaportalwindow in the secret passage thing too if you wanted. Also, there's a lot of space under displacements near the hatch (above/beside spawn) that could be filled in with nodraw. It will help performance.

I did my best to clean your visleafs up. I suggest that you save your current copy as b2_old and rename mine to b2 and go back and forth, looking at the portal files, where/how I've hinted, and what things I have made func_detail. A quick way to generate a portal file (to see where the messy areas you need to clean are) is to compile with BSP only and don't run the game.

Some of your visleafs are still really complex and it's not really fixable, and they're both because of things you did when creating this map. The first is that you clearly used the 1u grid a lot. The second is that you didn't really align anything to any major grid lines. These are kind of related and lead to similar problems and frustrations.

The first thing to know is that VVIS always cuts every 1024 units, along the major grid lines: the orange and blue ones. That means that even in the following situation, where I've neatly hinted to VVIS what I want, it does some weird thing instead.

Here you can see the brush I hinted around:

qR3pIPk.jpg

Here I have it selected. 120x63x184. You have to be on the 1u scale to edit this in any dimension.

HyjLDAg.png

Here it is on the 8u grid.

77oSONZ.png

Since you build all your stuff in weird sizes on the 1u grid, eyeball measurements, and don't have any internal consistency, stuff like this happens. VVIS cuts in weird places where you don't want it to or can't really affect it much with hinting. It's much worse in other areas of the map; I chose this spot because the effect is really easy to see.

Here's an area that suffers from the same problem, but a lot worse:

ycKm5Ff.jpg


So you can see how this is a headache for VVIS and kills your compile time when you do it a lot.

The other problem with working at small grid sizes is how hard it is to do anything, how long it takes. As I was hinting this, I was constantly zooming in and out on the grid, lining things up on every side just right, zooming out to do it again or stretch a skip brush and then zoom back in to align it. It just takes forever. If you use a higher grid size during alphas, like 32 or even 64, when it comes time to detail, it's a lot easier to break into similar sized chunks. If you look at Valve maps or community maps that have gone official, the majority of the geometry is sized in multiples of 64 or just powers of 2. It's not always the case of course, but when you use those kinds of measurements everything fits cleanly on the major grid lines and is a lot easier to adjust, because you don't have to spend so much time making sure it all lines up. The second benefit of this is less leaks. You're just less likely to have 1u holes in weird corners that take forever to hunt down. The third is that you're less likely to accidentally create 1u lips that VVIS then cuts along.

This is the most I wanted to do on the main ziggurat but you can do more.

JHhZxfm.jpg


So, two things here. If your ziggurat's base and subsequent layers were powers of 2, you'd be able to cut your visleafs a lot neater in general and get by with just this big cube I threw in. But since it's a weird size randomly placed on the grid, there's a lot of unnecessary and unpreventable cuts. The second thing is that if your ziggurat's slope was consistent, you'd be able to very easily make a trapezoidal prism hint brush, but as it stands you'll have to make a different diagonal hint for each step. It'll help a lot, but the measurements make it so annoying that I don't want to do it after doing the rest. Sorry.

To be clear, I don't suggest going through and remaking everything so it fits neatly onto the grid in standard measurements. Just do it for your next map.

Anyway, be sure to check out the full scope of what I did, and if you don't understand why I did something feel free to ask me. Also let me know if something I just said is unclear or whatever.
 
Last edited:

Snowbat

L4: Comfortable Member
Apr 23, 2013
165
74
Holy sh** f*** that's a lot of info. I'll have to check this out when I get back home. Big thank you to you.
I always hated HINT brushes. I know they're powerful, but I just can't get my head around them, even after reading countless tutorials. It seems that part of my brain just says "nope". I knew func_detailing was important, but I didn't realize you had to func_detail that much. No wonder my compiles always take forever...
Alias also told me about on grid mapping. But it was already too late for this map. I'll keep it in mind for the next one.

MIND BLOWN.
 
Last edited:

tyler

aa
Sep 11, 2013
5,102
4,621
Well, hopefully seeing where and how I hinted helps you with that for the future. It's kind of important. I think just seeing the difference between what I func_detail and what you func_detail will also help a lot.
 

Snowbat

L4: Comfortable Member
Apr 23, 2013
165
74
Okay, I'll try to understand the hinting later. I know what they do and when you give me simple examples, I understand them. But I never find a proper way to implement them on the maps I make. I must either be dumb, or it's just one of those things I can't get my head around.

I'm looking at your func_detailing now. I noticed one thing: when there are several brushes close to each other, you made each into a separate func_detail. Why didn't you group them all into the same func_detail?
 

tyler

aa
Sep 11, 2013
5,102
4,621
It doesn't really matter how you func_detail things. On your map I was just selecting brushes that should be func_detail, hiding them after tying them to f_d, then seeing what was left. I did that a lot. If you want to rearrange how things are func_detail to make them easier to work with, go ahead. I also frequently func_detail things separately to make them easier to work with (don't have to go into Objects or Solids mode to select an individual brush).

You might see it a lot with bridges in your map. That's because you're using too many brushes for many things, but I didn't want to take the time to fix it. Walls are another area where you could probably condense and consolidate brushes. With the bridges, I'd func_detail what I saw, and then hide it, and find something else I didn't notice or that was inside somehow.

As far as the compiler is concerned it makes no difference. I'm pretty sure VBSP merges all func_details into one at compile time. That's why when you decompile they are all grouped together.
 
Last edited:

Pocket

Half a Lambert is better than one.
aa
Nov 14, 2009
4,694
2,579
In my case, I was able to dramatically improve VVIS time by adding a bunch of blockbullets brushes to func_detail; I had forgotten that those block vis for some stupid reason, although I don't know why that wasn't an issue before. Still takes a few whole minutes to run when it ought to be over in seconds, though. *shrug* I have to wonder if Valve changed it so that it does more calculations than it used to.