FAST or NORMAL compile modus?

I used google and other forums to find this answer....but its never explained anywhere.

Here's situation: I usually FAST compile if I want to test out my map and check for errrors. But once my map is 100% finished, I always run it in NORMAL mode. Takes longer though.

Now, my map is as good as finished so I went for the NORMAL compile today but Hammer froze somewhere....I just found out when I got home and checked its status. I'm thinking of compiling it in FAST modus and upload it to fpsbanana.com anyway.

Question
I am not really sure what the big difference is between FAST and NORMAL compile modus. So what is the big difference?

Short answer is no, do not just run fast vis, that is good for checking lighting only.

Fast Vis= basic vis calculating loaded from .prt file, will result in finished lighting but a very poorly optimized map. If your compile is choking, it's likely that it's stuck on the PortalFlow process of Normal vis, which means you have some work to do. Normally this means that you have too many little brushes set to world and not func_detail.

It all boils down to reading and understanding this:

http://www.student.ru.nl/rvanhoorn/optimization.php

To be honest mate, I don't really care if I use fast vis or normal vis, I optimize my maps well (make it so that the game engine can't see too much at any one time) and I use area portals so I get very minimal difference between fast and normal vis. Using normal vis is alot more important in multiplayer maps and not so much singleplayer because you can't use areaportals in multiplayer.

To put it simply, the difference between fast and normal is that fast does a rough job and normal does a proper job. The only reason that feature is there is because sometimes normal can take a very long time and this can slow the development of maps having to wait all day for a compile to finish.

If normal keeps crashing just use fast vis (but always use normal rad because it dosen't take very long) and make sure that your map runs well.

---

Aaron's Stuff

Thanks guys!
Well, I have used A LOT of func_detail and some optimisation. I have to say its bit of an complicated map. But it aint extreme.

FPS is allround at most places now. And yea, it usually takes quite some time for my maps to compile on NORMAL. But that is probably due to bad optimisation as in areaportals, visleafs dividing , etc....since I really dont get how to apply them (yes I have seen several tutorials on them but they drive me nuts). So I left those out.
But I always do use NODRAW texture, func_detail, hint brushes tho.

(oh and if you were interesting on looking at my map: http://www.fpsbanana.com/maps/83293 )

Ah, the old fpsbanana. To be honest, I don't think you should listen to what they say too seriously, pretty much every time I go there to check out some maps, I see awful maps getting rated 10/10 and I see really nice maps being rated anything below 6/10, what really gets me though is when some guy comes along and rates a crap map poorly and totally doesn't justify their reasons or gives poor excuses like the time where some guy rated this decent looking map 1/10 for design, gameplay and fun because it "looked boring from the screenshots", but than you have a look at the guy-who-gave-a-good-map-a-bad-sore's maps and there just empty kill box rooms, that really frustrates me.

I checked out your map. It looks decent (comparing this to the best level design I have seen). I like the idea of it but overall I feel that the architecture is very primitive (its very blocky and "distinct") and the map lacks detail overall (it looks pretty bare). You should probably have disabled the shadows on those bamboo tree models, your now left with a shadow that looks nothing like the bamboo tree model and I could easily understand if somebody not in the game development realm thought that the shadow was a glitch.

Anyway, its pretty decent, please don't feel down or upset by my comments, I'm giving you my oppinion on the map which is more valuable than getting a whole bunch of these:

Pros: Great map
Cons: None
Improvements: None
Notes: Another great map by Gargantua
Approved - 10 [+]

... this level certainly reflects experience and some amount of skill in level design. Ofcourse I can't rate it or give you any further comments because I haven't playin and I can't because I don't have that Counter-Strike mod.

Nice work Roger, please let us know when you make another map or create a thread in the maps section so we can give you advice during its development .

---

Aaron's Stuff

Topic Moved to HL2 Editing from HL Editing

---

Blog: www.playingarchitecture.net
LinkedIn: Eric Lancon
Twitter:@Riven202

Heh, this helped me too! I need to totally optimaize my map, I added areaportals, but that is not enough, THANKS FOR THE TIPS!

aaron_da_killa said:
To be honest mate, I don't really care if I use fast vis or normal vis, I optimize my maps well (make it so that the game engine can't see too much at any one time) and I use area portals so I get very minimal difference between fast and normal vis. Using normal vis is alot more important in multiplayer maps and not so much singleplayer because you can't use areaportals in multiplayer.

To put it simply, the difference between fast and normal is that fast does a rough job and normal does a proper job. The only reason that feature is there is because sometimes normal can take a very long time and this can slow the development of maps having to wait all day for a compile to finish.

1) You CAN use area portals in multiplayer maps, I've used them sucessfully in my map dm_castigate (look at the rebel and combine "bases"), and mazemaster used them on dm_island17 (in every house)

2) I feel as though I should clear something up here arron about fast and normal vis. What you say here is VERY wrong.

Fast:
Creates each vis leaf for your level, a vis leaf per say is the volume that defines which polygons are drawn by the engine (polygons that can be either world, or models, or sprites). Beyond that its done.

Now when you enter the map in game, the engine is now dynamically calculating which vis leafs are visible from the current leaf the player is standing in. This leads to a lot of processor overhead thats not needed.

Proof: Turn on mat_showvisleafs 1 (I think thats the right command). You will see that despite the correct blockers, the engine is drawing the entire level (minus the max distance that the player will see stuff at).

Full:
It does the fast vis step, but then it takes it to the next step: It now calculates which which other vis leafs are visible for every vis leaf in the map. So if your into studying about orders of magnitude arron with algorithms thats (worst case) O(n^n). So say you have 1000 vis leafs, that means there are 1000^1000 calculations to be done. Thats a lot of calculations to be done.

Its better to get these pre-calculations to be done before you load it into the game. This way the engine doesn't have that extra overhead as it did in fast. Leaving more resources to dedicate to sound/game play mechanics/physics calculations/etc.

Proof: run the command again now, you will see that the engine is only drawing what is necessary for it to draw, and not the entire level.

So despite you (arron) not seeing a difference between them on YOUR computer (You probably have a kick ass processor), people with slower processors WILL see a difference because you didn't run it on Full vis. And your not being a good developer if your map only runs well on a select few computers. You will NEVER see any professional map maker ever leave the final version of a map in fast vis.

Take this lesson home:
FULL VIS IS AN ABSOLUTE MUST FOR THE FINAL VERSION OF YOUR MAP. You don't need it for subversions to check out lighting, but you do need to run it to check where to optimize.

Now how to fix this problem:
Your computer is crashing because its page file, and RAM run out of space. While valve did make a great compiler for their engine, they did not do any boundary checks (and how could they? a map can be n big, and if it stops at n-1 then how can it be completed?). A potential fix is increasing your page file size (or rather your virtual memory in your computer settings). I can tell you how to do that if you post back later, you'll also need a lot of hard drive space as well. However the more applicable solution is as follows:

If building portals takes more than 3 seconds to complete... its gonna take a long time to do the second calculations. If we refer back to the O(n^n), thats vastly exponential growth:

http://en.wikipedia.org/wiki/Exponential_growth

In other words say you have 100 visleafs. That means its going to take 100^100 checks to be done. This isnt bad, however say you add one more so its 101 vis leafs. That is 101 extra calculations to be done, not 1 more calculation. It grows FAST!

How do you get around this? Reduce the number of vis leafs you have overall using the tutorial posted. Thats going to be the ultimate way. Here is what I do:

On the right I unckeck all the models, func_details, everything, so that its just world brushes left. The rooms you should see should be relatively square and simple. If theres complex brush work (like stairs, or anything at an angle), turn it into func_detail or learn to model.

I knew everything you said Omegaslayer except I didn't really think that it would make much difference between fast/full performance wise if it ran fine on one machine and didn't think about the implications on other peoples machines (I guess I'm too used to constantly being at the lower end of the spectrum in terms of pc performance).

Also with the areaportals in multiplayer maps, did you use the dynamic (func_areaportal_window or something) or static areaportals? Because for memory and I could be wrong, I remember reading something about the static areaportals not working in multiplayer (are the static areaportals controlled on the server or client side?).

---

Aaron's Stuff

Static areaportals (func_areaportal) work based on whether they receive an 'open' or 'close' input from another entity. Thus, they are client side, just as visleafs are. Areaportal windows are as well. I HAD to use areaportal windows in the compilation map in order to get it running minimally on my test PC. The only difference between 'regular' areaportals and areaportal windows is areaportal windows calculate proximity of the player. So, say if one player is outside a window but close enough to see through, and the other player inside the window but far away enough not to see through, then the outside player gets an advantage and can see the inside player when the inside player has no idea he's being targeted. -It's completely client-side. Areaportal windows simply fade until completely opaque allowing the engine to cut-off what ever is being rendered behind them and masking it with a texture or color. or even an entire brush-shape. They achieve the same effect, but so-called 'static' areaportals must be told when they are to be closed and other than actually placing a brush or model (or any textured polygon) in front of them to 'hide' them. They are the same thing with a different effect and are both client-side.

Hypothetical scenario: Say there is a button in a mp map that among other things, universally closes a group of func_areaportals. The button activation is done server side (that is, when player_A activates button, that output is sent server wide) But it's effects (dependent on which entities it talks to) will more likely be client-side. One effect tells areaportals 1, 2, & 3 to close. Because regular areportals must close when told to, their calculation is done client side, but their input from the button done server-side. Thus each and every player will get a HOM effect when looking at a door with a closed areaportal blocking it off even though they were not the one who pushed the button. So, their computer is still doing the calculation of the rendering of visleafs, but so is everyone elses' computers therefore seeming server-side.

---

Blog: www.playingarchitecture.net
LinkedIn: Eric Lancon
Twitter:@Riven202

always-open areaportals are the last-ditch way to save a chunk of map optimizing in a MP map. They work well in testing, I used them extensively in Shipshape. If there were ways of hinting areas off i would have chosen that route though.

"aaron_da_killa" said:
I knew everything you said Omegaslayer except I didn't really think that it would make much difference between fast/full performance wise if it ran fine on one machine and didn't think about the implications on other peoples machines (I guess I'm too used to constantly being at the lower end of the spectrum in terms of pc performance).

It might be the maps you've designed then. It might be that your maps, full or fast, draw the entire level (Or some variation where full merely excludes small proportions of your map over fast). Try this experiment on indoor maps. Here are probably some maps that don't benefit too much from full over fast:
dm_torque
dm_overwatch
And some that would benefit from full over fast:
dm_lockdown
dm_departure
dm_steamlab

catch my drift?

"aaron_da_killa" said:
Also with the areaportals in multiplayer maps, did you use the dynamic (func_areaportal_window or something) or static areaportals? Because for memory and I could be wrong, I remember reading something about the static areaportals not working in multiplayer (are the static areaportals controlled on the server or client side?).

Yeah func_areaportal_windows. I forgot about static area portals. So my bad ;P.