compile never ends

EmNudge

L4: Comfortable Member
Sep 23, 2015
184
60
compiling gets up to
Portal Flow 0...1...2...3...4...5...6...7

and never ends. well, never as in I waited 4 hours, never ended, I cancelled tried to change stuff, I waited over night, still up to that. Usually the compile takes around 40 seconds.

can't show any compile logs since there is no compile to show. it also majorly slows down my pc as if it is doing some hardcore compiling.

no problems detected by alt+p

I don't see how a leak would cause this.
 

Bunbun

aa
May 18, 2014
401
782
If you're too lazy to optimize anything then just create a massive func_viscluster (trigger textured) in all the open areas, this decreases the portal flow time, there are some drawbacks to this however, but i forgot.

Edit: I should have pointed out that it is best to optimize your map instead of doing ^ that, unless you just want to take a brief look around it.
 
Last edited:

killohurtz

Distinction in Applied Carving
aa
Feb 22, 2014
1,016
1,277
If you're too lazy to optimize anything then just create a massive func_viscluster (trigger textured) in all the open areas, this decreases the portal flow time, there are some drawbacks to this however, but i forgot.

Please don't do this, there is no "easy fix" for optimization issues and you should get into the habit of optimizing correctly. Func_viscluster is a VERY situational tool - it tells all visleafs it touches that they will be able to "see" each other in-game, reducing the number of calculations VVIS needs to perform, but at the same time causes the client to render every visleaf in that group when they can only see one. You do NOT want to use these for the sole purpose of bypassing long compile times because you will only end up hurting the in-game performance.

Edit: If you just want a quick look at your map without waiting for VVIS, you can disable the process or set it to Fast in the Run Map dialog. Just remember to run full VVIS before release.
 
Last edited:

ics

http://ics-base.net
aa
Jun 17, 2010
841
541
Edit: If you just want a quick look at your map without waiting for VVIS, you can disable the process or set it to Fast in the Run Map dialog. Just remember to run full VVIS before release.

I agree and if your vvis takes longer than 30 mins, there's propably something really wrong with the map in terms of processing it.
 

tyler

aa
Sep 11, 2013
5,102
4,621
There's something wrong if your vvis takes more than 5 or 10 minutes imo. Also killo is right about visclusters, please don't use them.
 

MoonFox

L10: Glamorous Member
Mar 17, 2015
739
74
There's something wrong if your vvis takes more than 5 or 10 minutes imo. Also killo is right about visclusters, please don't use them.
it could be dependant on his computer, older computers could have issues running a map after a while, regardless of optimizations. My old PC couldn't handle some of my maps, and now that my new PC is here and set up; they are running smoothly back to production.
 

EmNudge

L4: Comfortable Member
Sep 23, 2015
184
60
it could be dependant on his computer, older computers could have issues running a map after a while, regardless of optimizations. My old PC couldn't handle some of my maps, and now that my new PC is here and set up; they are running smoothly back to production.
relatively new pc, usually takes 2 minutes to compile. fixed the problem, my respawn room walls were a bit messy and I had completely forgotten about them
 
Mar 23, 2013
1,013
347
There's something wrong if your vvis takes more than 5 or 10 minutes imo. Also killo is right about visclusters, please don't use them.

there is nothing wrong with using func_visclusters in open areas. As long they don't go through any world or hint brush, there is no disadventage to them
 

tyler

aa
Sep 11, 2013
5,102
4,621
there is nothing wrong with using func_visclusters in open areas. As long they don't go through any world or hint brush, there is no disadventage to them
Yes there is. There's not a lot of maps in TF2 that benefit from them. Using them incorrectly can and will tank your map's performance because you'll then render leaves you shouldn't.

It's an entity for really advanced optimization and shouldn't be recommended in a thread like this to a new mapper.
 
Mar 23, 2013
1,013
347
Yes there is. There's not a lot of maps in TF2 that benefit from them. Using them incorrectly can and will tank your map's performance because you'll then render leaves you shouldn't.

It's an entity for really advanced optimization and shouldn't be recommended in a thread like this to a new mapper.

Like I said, if a func_viscluster dosnt go through word or hint brushes there is no way that it affects performance. Of course you are using them incorrectly when they go through them, and affect performance in a bad way.
 

tyler

aa
Sep 11, 2013
5,102
4,621
Wrong. You can use them in open areas and completely ruin your visibility structure. (I've done it myself. I've seen it done when helping others. I've solved issues related to them dozens of times over the years.)

Visclusters don't just speed up compile time, they tell the engine that all leaves within the volume can see each other. Meaning that the way visibility is calculated changes, because the engine now needs to only check the boundaries of this viscluster volume. Meaning that when visleaf structure is computed, you can end up rendering things around (sometimes multiple) corners even with visclusters completely unobstructed by brushwork or hints.

Again: please don't recommend them to new people because they are not easy to use correctly. Other users also see this being recommended to new people and think it's a basic concept they can also use easily. It is not.

Yes, they can be very helpful in some situations for some maps in some cases. But they aren't simple, useful, or safe enough to recommend for a thread like this when the answer lies in lack of func_detail or other basic optimization techniques.

It is irresponsible to bring up visclusters solely because they exist in a situation like this. Think about the ramifications of your actions when helping people--including those who didn't ask the question, and will read your words in the future.
 
Mar 23, 2013
1,013
347
Then func_viscluster must be bugged, as you describe them.

Their purpose is not to optimize the game (I didnt even say that!) like func_detail, they exist to speed up compile time by helping computing visibility. If they dont touch world or hint brushes, then it is impossible that you tell a visleaf that it can see a visleaf which it actually can't, because it only tells which visleaf can see eachother WITHIN its volume where nothing can block visibility.

So I conclude vis_cluster as they exist right now are bugged, right? Is it that what you are saying? Otherwise I can't understand why two people thanked your post
 

tyler

aa
Sep 11, 2013
5,102
4,621
Essentially, it doesn't merge the visleafs, but VVIS acts as though the leafs have been merged. That's literally the function of it as I've experienced it.

I would guess it is behaving as expected since it's operated that way since it was put into Source (to my knowledge). The main use case for it in TF2 would be simplifying 3D skybox stuff if your 3d skybox is weirdly complex. I'm not sure about other games.
 
Last edited:

worMatty

Repacking Evangelist
aa
Jul 22, 2014
1,257
999
func_viscluster is indeed very useful. But if VVIS calculation is taking several hours, then it's more likely the map's architecture needs to be reconstructed. tyler's concern is that it is a very advanced entity that requires a lot of experience with BSP to use correctly and while it could certainly help reduce VVIS calculation in some parts of the OP's map, it is very likely that in this case it would be much more efficient to reconstruct the map.
 
Mar 23, 2013
1,013
347
It doesn't merge the visleafs, but VVIS acts as though the leafs have been merged.

What do you mean with that? vvis dosnt really act like that the vis are merged, viscluster just tells vvis that those leafs can see eachother. There is a bug in hammer that when you load a portal file that the visleafs inside the volume merged to a giant big one, but this is not true if you look at the leafs in-game.
So in the end, func_viscluster are indeed only usefull if you have big open areas. Like... really big open areas. I use them sometimes when I didnt made my 3d skybox yet but have the giant space around my map already set up.... or you might also use them when you compile things like the coast level from HL2 which would take hours to compile without visclusters.

Well I shouldn't have recommended it to a beginner tho, its not very likely that he has giant open space.
 

wiseguy149

Emperor of Entities and Amateur of Aesthetics
May 12, 2009
103
220
If your map has reached the point where func_visclusters are needed to manage compile times, it's probably also at the point where in-game performance is suffering. The correct course of action is to fix the underlying performance issues in map geometry, not slap a band-aid over the problem so that you can finish compiling a map with poor performance.

It's generally a rare scenario where a viscluster is actually the correct thing to use.
 

henke37

aa
Sep 23, 2011
2,075
515
What func_viscluster does is merging clusters of visleaves. This is the underlying explanation for all of the results.
 
Mar 23, 2013
1,013
347
What func_viscluster does is merging clusters of visleaves. This is the underlying explanation for all of the results.

wrong. it does NOT merge them. this is a bug in hammer when you try to display the portal file after a compile with func_viscluster. the leafs arem't merged if you look at them in-game
All func_viscluster does it tells all visleafs that are in its volume that they can see eachother.
Again, this is why a func_viscluster can't fuck up vvis or decrease performance if it isnt going through wrold, hint or water brushes.
 
Last edited:

Freyja

aa
Jul 31, 2009
2,994
5,813
Actually, what func_viscluster effectively does is it tells the vis engine that if you can see any leaf in the viscluster volume, then you can see all of them and thus skips the calculations for them (because while it doesn't merge them, it treats them as one). The player only has to be able to see any visleaf touching the func_viscluster for them to render all of them, regardless of if they can even see the volume or any of the other leafs.

This is quite useful when you want to render other sides of say, skybox dividing brushes where you otherwise would not be able to. I believe Egan actually used them for this purpose in watergate.

However this also means that if you can see a tiny part of this open area that you have a large viscluster in, then you will render all of it, where often the visleaf cuts (if not the automatic 1024 unit ones) would prevent the entire area from being rendered, say from a window or around a corner.

Here is a super cruddy drawing to demonstrate
wA7SynR.jpg


In this imagee, you can see how some of the visleaves around the corner are not rendered from the leaf the player is in.

ZaepLWe.jpg


In this image, I've visclustered the "open area" and it causes all of the leafs, some which would not normally be rendered, to be rendered (indicated by R because I got sick of writing rendered). It's an open area, and it improves compile time, but decreases performance in this case, and this is why you should be careful with how you use them, and not just "in open areas"
 
Last edited: