Welcome to PlagueFest.com! Log in or Sign up to interact with the Plague Fest community.
  1. Welcome Guest! to interact with the community and gain access to all the site's features.

Help with compiling.

Discussion in Mapping Discussion started by chickenfoot, Dec 14, 2013

  1. Oct 8, 2013
    I'm semi-new to map making, and am making a map for Zombie Mod.
    After putting in a few semi-complex objects, the map takes about 5 minutes to compile and run.

    I don't know how to fix this, I remember seeing a tutorial that showed that if I don't do something like group objects (that wasn't it i dont think) that my map would take forever to compile. Could I get anyone's help?

    If you want you could get on teamviewer and I could show you, maybe you could give me some pointers. Thanks.
  2. Feb 27, 2012
    What kind of compile are you doing? Fast, or some other option? Also, screenshot a what your map looks like in hammer, that way i can see how complex it is, and maybe if you did something wrong. If it's leaking, it can make it take forever to compile too.
  3. Mar 8, 2013
    compile time is a poor measure of how well put-together your map is. a perfectly optimized map could take an hour to compile, and the other way around.
  4. Jan 11, 2011
    Not really @Satin Storm. RAD takes a limited amount of time because Light Map Grid is limited, and using 100% of it is still quite fast. I don't know about a "perfectly optimized map", but Mako Reactor takes 2 minutes to compile on Full/Full.
    The "secret" is using Func_Details on EVERYTHING that is not sealing the map from the void or blocking one area from the next one. Basically, your map needs to end being as simple (cube-rooms) as possible when only "World Brushes" are enabled on the Automatic Groups, which are the only ones that cut the world into VISleafs.
    Even some big walls have to be Func_Detail if they aren't effectively blocking line of sight with the rooms/areas behind them (because they are full of holes, placed in an area with nothing behind, etc...).

    I have given this link more than a dozen times, but its really well presented and explained: http://rvanhoorn.ruhosting.nl/optimization.php?chapter=func_detail
    • Agree Agree x 1
    • Apr 9, 2012
      Kaemon explained it with the func_details.

      There is a method however that completely finalises a map and makes it look much better depending on how you approach your lightgrids and prop_statics. This is called expert settings with final options. Those final options are the following:

      -ldr/-hdr/-both -final -staticproplighting -staticproppolys -textureshadows -lights lights.rad (or whathever you named your custom .rad file)

      The bolded ones are in my opinion a must on final compile settings and I think about 95% of all ZE maps have missed these factors (for a reason). What they do is actually lighting prop_statics and dynamics in a way that they can receive shadows on specific parts of their mesh appropriatly the way shadow falls down on it, called Vertex Lighting. In other words it's lit the way brushes are lit in Hammer (though unfortunatly not as accurate/sharp). By default these are not VertexLit but uniformly lit. So let's say a prop has 50% more shadows than light, by default it would uniformly take a shadowed lighting which makes it look very odd because half of that model should have been lit and the other part not. As a result you often have plain dark props standing often in the middle of a lit area and vice versa. This is fixed by using -staticproplighting.

      So yea, it's as easy as adding -staticproplighting to the $light.exe line on expert settings. This takes 5 seconds to do but makes all of your props hundred times better and does not add too much to the file size.

      The -final parameter increases the quality of the lightmaps, and this is often the option that increases the BSP filesize, exponentially depending on your lightgrid size. If you're using for instance lightgrids of 16 or lower (which you should't usually) then it may turn out for the worse on BSP size if combining this with -final. If you are using 24 or higher you could easily use the parameter to increase the quality. It also increases the quality of the light that bounces off surfaces to light their surrounding to the appropriate color, and can often provide very nice results and effect for minimal effort.

      I personally think that each and every map should have these 2 options by default (also when testing your map for graphical aspects (not for gameplay aspects)). The other 3 options are optionally and do not increase the filesize that much, but with heavy usage of props and textures with alphamaps those options can really crash your compile beyond comprehension, so are often not used and were more intended for DE_ scaled maps or variants of those. -staticproppolys creates shadows off the form of the mesh from the prop instead of just using the collisionmodel. This often makes shadows looks worse (such as trees for instance, when not using the option they will cast shadows from the collisionmodel, if used they will cast shadows off the entire form of the tree resulting in a big blob below the tree itself).

      For such situations you can use -textureshadows and lights.rad which both are necessary to prevent shadows from creating such a big 'black blob' below props with translucent materials. You can put the texture path of a translucent material in the .rad file and tell VRAD to threath it as translucent when calculating shadows. This way -textureshadows will make the shadows project all of the leaves on the tree on the ground instead of one big black circle. You need however, at least a gridsize of 16 or lower before you can even see the effect working. That's why it's hard to use in ZE. This is too complicated to explain myself and that's why if you are interested you should read this instead.

      I know that some people are gonna tell me that I do say this a lot lately, each time a thread of compiling shows up. It's because I believe these options make a map look so much better, and are essential to the way props are lit. I have always found it a pity that so many maps have missed out on these options. It's probably also because no one ever told them to, since I only knew of this ever since Motanum told me about it when we worked both on our projects for the CEVO contest on GameBanana. It made the difference between my map (cs_ardennes) being submitteable as a finished product with visuals that were natural, or a project that looked horrible with ugly lighting due to the prop being lit out of the blue to dark or light, just horrible.

      Anyways, I hope this was interesting enough to consider it once you are ever finishing a map yourself. Though for testing purposes, normal/normal is just fine
      JorisCeoen, Dec 15, 2013 Last edited by JorisCeoen, Dec 15, 2013
    • Oct 8, 2013
      There's a screenshot. Idk lol... There's no leaks, I always put a hollow skybox around the entire map before I even do anything.
    • Mar 8, 2013

      for new mappers, yes, I agree that lack of func_details is the primary cause of long compile times. however, your main concern should not be how long VVIS takes to do its job. instead, focus on how your map performs on runtime.

      there are many cases where you would actually want to cut more visleaves (using hint/skip) than VVIS would on its own accord. this can add hours of compile time. for example, on my zm_colossus map (which is huge and open, so optimization is especially important here), the visleaves by default extend across almost the entire map. this is bad, because it would render parts that aren't actually visible to the eye. to mitigate this, I did horizontal/vertical/diagonal slices where appropriate using hint brushes, thus improving FPS. the downside is waiting for the final compile to finish, but that's a small price to pay.

      those boxes all need to be func_details. sewage tube as well. and possibly that concrete wall in the back. each step of the stairs is cutting its own visleaf too, so func_detail those. as Kaemon said, with func_details disabled in visgroups, your map should look as "box-y" as possible. straight, smooth walls with no protrusions.
    • Apr 9, 2012

      First of all this is an internal point entity, so it's not gonna count to the edict count.

      Secondly, what I just linked there, is an entity that will group visleafs together of which you know they will all see each other as soon as they are in view of one or more visleafs that can see all those visleafs.
      In other words, if you have a gicantic area that has unfortunatly no single brush blocking visiblity, once you can see that area and one of it's visleafs, they will all be rendered. However, if not using that entity, visleaf will calculate each and every cranny little single visleaf one by one during compile to calculate which of these can see each other.

      Now, because we know that they will all see each other, we use that entity instead to tell VVIS they can all see each other and skip calculating the visual connection process on them. So in other words, if you happen to have this extremely large area (or more of those) instead of waiting so long, use that entity to group them, and VVIS will compile that area in 2 seconds instead of half an hour.

      ALSO, this improves FPS because in-game the engine does not has to calculate in run-time which visleafs to hide or not. So yea, calculating so many visleafs at a time can impact performance, because each visleaf will be on its own without that viscluster. With it, it will be as if all visleafs are all one visleaf instead and as such the engine has a very easy time deciding what to render or not.

      Also, you can use this func_viscluster to skip the VVIS project but still have full VRAD functionality when testing for graphical/visual elements, as disabling VVIS will not create any visleafs at all and make the lighting go wrong. Though this is really only for testing visuals quickly only.
    • Mar 8, 2013
      are you sure this is the case? I knew about func_viscluster but I never bothered using it because I assumed it only affected compile time, not in-engine rendering. the wording on the wiki page always seemed ambiguous to me: "This entity does not change the location of or number of leaves in a map."
    • Apr 9, 2012
      Yes, because I said it's as if all visleafs are one visleaf. I know the description says it does not actually change the number of visleafes. It just makes them function faster by the engine because then engine does not has to go via each and every leaf to check which ones have to be activated for rendering stuff. On my map de_himeji I at first had 130FPS in general in SP, only adding 4 of these at places where all visleafs are rendered anyways brought it up to 170 and higher, and combined with areaportals and hint-skip at this current time gives me 220fps and higher in indoors and 180 or higher at outdoors.

      It is mentioned at the visibility optimization page for a reason as well. Of course, this entity only really works on such extremely large areas. Aside from that, it has not much purpose especially not to improve FPS.

      And in my opinion, for testing purposes it really is worth the usage of that entity.
      To add onto the list: If you start placing them everywhere to reduce compile time or if you place them badly (across walls or areas with much visibility calculation at tight spaces (=indoor or something)) they will give you the reverse effect of what you want to achieve. So yes it's a dangerous item but this is the same for areaportals or hint/skip. When badly placed they tend to worsen FPS than anything else.