compile never ends

Discussion in 'Mapping Questions & Discussion' started by 【EmNudge】, Oct 13, 2015.

  1. 【EmNudge】

    【EmNudge】 L4: Comfortable Member

    Messages:
    183
    Positive Ratings:
    37
    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.
     
  2. Freyja

    aa Freyja ¯\_(ツ)_/¯

    Messages:
    2,879
    Positive Ratings:
    4,971
    This is caused by having far too many visleaves, because you haven't func_detailed enough or the right geometry. I recommend you take a read through this page (the rest of the guide is great too), applying these techniques to your map will drastically reduce your portalflow time. http://www.optimization.interlopers.net/index.php?chapter=func_detail
     
  3. Bunbun

    aa Bunbun Gay sex slave

    Messages:
    403
    Positive Ratings:
    570
    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: Oct 13, 2015
  4. killohurtz

    aa killohurtz Distinction in Applied Carving

    Messages:
    1,006
    Positive Ratings:
    1,160
    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.
     
    • Thanks Thanks x 2
    Last edited: Oct 13, 2015
  5. ics

    aa ics http://ics-base.net

    Messages:
    720
    Positive Ratings:
    435
    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.
     
  6. tyler

    aa tyler snail prince, master of a ruined tower

    Messages:
    5,035
    Positive Ratings:
    3,992
    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.
     
  7. MoonFox

    MoonFox L10: Glamorous Member

    Messages:
    737
    Positive Ratings:
    72
    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.
     
  8. 【EmNudge】

    【EmNudge】 L4: Comfortable Member

    Messages:
    183
    Positive Ratings:
    37
    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
     
  9. Lampenpam

    aa Lampenpam

    Messages:
    1,019
    Positive Ratings:
    337
    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
     
  10. tyler

    aa tyler snail prince, master of a ruined tower

    Messages:
    5,035
    Positive Ratings:
    3,992
    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.
     
    • Thanks Thanks x 1
  11. Lampenpam

    aa Lampenpam

    Messages:
    1,019
    Positive Ratings:
    337
    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.
     
  12. tyler

    aa tyler snail prince, master of a ruined tower

    Messages:
    5,035
    Positive Ratings:
    3,992
    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.
     
    • Thanks Thanks x 3
  13. Lampenpam

    aa Lampenpam

    Messages:
    1,019
    Positive Ratings:
    337
    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
     
  14. tyler

    aa tyler snail prince, master of a ruined tower

    Messages:
    5,035
    Positive Ratings:
    3,992
    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: Oct 16, 2015
  15. worMatty

    aa worMatty Repacking Evangelist

    Messages:
    1,072
    Positive Ratings:
    836
    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.
     
  16. Lampenpam

    aa Lampenpam

    Messages:
    1,019
    Positive Ratings:
    337
    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.
     
  17. wiseguy149

    wiseguy149 Emperor of Entities and Amateur of Aesthetics

    Messages:
    103
    Positive Ratings:
    160
    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.
     
    • Thanks Thanks x 1
  18. henke37

    aa henke37

    Messages:
    1,927
    Positive Ratings:
    454
    What func_viscluster does is merging clusters of visleaves. This is the underlying explanation for all of the results.
     
  19. Lampenpam

    aa Lampenpam

    Messages:
    1,019
    Positive Ratings:
    337
    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: Oct 17, 2015
  20. Freyja

    aa Freyja ¯\_(ツ)_/¯

    Messages:
    2,879
    Positive Ratings:
    4,971
    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
    [​IMG]

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

    [​IMG]

    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"
     
    • Thanks Thanks x 2
    Last edited: Oct 17, 2015