L4D: General mapping questions

Technology and Gaming Help and Support
#1

I am working on a full L4D campaign, with the general layout for the first map completed in hammer.

I intend to use this thread multiple times, as I run into any problems…

My first questions is this: What is the recommended height of a ventilation duct in Left 4 Dead?

Oh, and could somebody refresh my memory on rope… it doesn’t seem to want to work…

EDIT: Solved the rope problem, hit a new one. Is it possible to connect a prop_physics to a rope? If so, how? If not, how do I do something to that effect.

Update on the rope-light fail: I can either have the rope show up with no light-prop, and MAYBE the actual light itself projected a couple feet away from its real location; no rope, light-prop on ground, and maybe a light; and finally nothing but possibly a bit of light in the wrong place. It seems that setting the keyframe_rope’s object causes the rope to never appear.

#2

UPDATE: Scrapped the rope, went to do full compilation and am in the midst of a massive wait. Seeing as a large portion of the map is a flat-ish outdoor area, could I just blanket the walkable areas with a few hint brushes a bit higher than the players view could ever be? Would that bring down the compile time and, ultimately, make the whole thing more efficient?

Edit: If not, than is there a way, with or without the use of hint brushes, to indicate to the compiling process that the characters will never be able to see from above a certain point?

#3

For large outdoor areas you can use a func_viscluster to tell the game that all the visleaves inside it can all see eachother, so it doesn’t need to calculate them all individually.

You can connect a prop_physics to a rope by parenting the prop_physics to a func_physbox which is inside it and then you parent the move_rope to the physbox too. You’ll also need this, but I’m not familiar with it.

#4

Ventilation ducts should probably be between 64-96 units depending on whether you want players to crouch in them and if you need infected to move through there (in which case you might want to make it taller, 128 units or so if you can make it look okay).

As for visibility…you could make a horizontal hint brush that divides the upper portion of the skybox from the walkable ground space…but unless you need the skybox to be very tall I would just bring it in as low as possible. As mentioned, func_visclusters are also useful for open areas where players can see multiple visleaves at once but you should place them carefully so extraneous areas aren’t being rendered which could drag down performance, possibly significantly.

Even for wide open outdoor areas your compile times shouldn’t be excruciating - if you notice long VIS calculations, run a BSP-only compile and use the ‘load portal file’ function in Hammer to identify excessive leaf splitting which you can then correct by tying world geometry to func_detail, adding hint brushes to control how the leaves are split, etc.

As for the rope issue, do what Mangled* said and use an invisible func_physbox to control the physical properties of the object. You can then parent ropes and a dynamic prop to the physbox and give it a simulated constraint with the phys_lengthconstraint entity (be sure to set the length of the rope with the lengthconstraint properties and not slack on the rope entities as this is merely visual, and tick the ‘Auto resize’ flags on the ropes). I would also stay away from using any dynamic lights on physics-simulated light props - if the light appears at all it will not look as good as a lighting baked into the map, and it will also be very expensive performance-wise.

#5

Unfortunately, it seems that func_viscluster has been removed from l4d… Unless I’m not looking in the right place. I created a brush then tied it to an entity, but there was no func_viscluster to choose.

Thanks for the help with the rope, and I’m gonna go try the load portal file in hammer.

I found out that corners of tunnels with arched cielings are leaf-happy. I’m putting diagonal hint brushes at each of the (6) corners in the tunnel system.

Solved Question: I don’t want an object (a small object, the roof of a well) to create leafs. Is there a way I can make it NOT slice it up horribly? Like… drawing a hint brush around it maybe?
Answered this one: Turned it into a func_brush. DOing the same with the overly complex doorframes in the underground section. Each one had like… 500 visleafs.
Update: Kinda embarassing, because it involved admitting that I had bad etiquet, but I got rid of twelve… THOUSAND numportals by turning them into details… I recompiled, it’s been only ten minutes, and its already at 5 and two dots. I think if I really went through and worked with hints… it’d work.

QUESTION: I have some traversable area under a displacement, but still inside the outer confines. If I draw a hint brush between it and the bottommost area of the displacement, will that prevent leaves from splitting up into the leaves above the displacement?

QUESTION: What is better: the SKIP texture or the NODRAW texture.

#6

I just checked and it’s there…just tie your brush to an entity and start typing ‘viscluster’ in the dropdown box and it should pull it up.

func_brush or any other brush-based entity won’t cause leaf splitting, but they also use up entdata as they have special functions (they can be toggled on and off, etc) and they also contribute to brush-based rendering costs significantly more - the preferable option is to tie them to a func_detail - this ‘entity’ won’t split the visleaves but it doesn’t take up entdata either as the entity data for details is discarded during the compile process - for all intents and purposes they’re standard world geometry with the exception that they don’t wreck your visleaves. Good portions of your map will probably end up being func_details.

Skip and nodraw serve different purposes - nodraw will seal the map from the void, will split leaves, block visibility etc; it basically acts as a normal world brush except it doesn’t get drawn. Skip doesn’t do anything at all and the faces are discarded immediately during BSP - it’s used on the sides of hint brushes where you don’t want to split leaves, for example.

#7

Meant to say Func_detail. Also, it just popped up to 6 and no dots. It seems to be taking exponentially longer. What is the general number of portalclusters and numportals? Like, but general, I mean a max possibly.

I’m at 2837 portalclusters and 8597 numportals.

Oh, I also encountered something, on my computer, if I try to do ANYTHING other than move the mouse, the compiler will stop responding, but keep working, NEVER ending. I’m using my netbook to write this post now.

#8

https://www.nodraw.net/2009/12/optimization-in-source-a-practical-demonstration/

Practical uses of your hint/optimisation stuff.

The compiler stops responding in Vista/7. Try using VBCT (Although I don’t know if that supports L4D)

#9

Thanks for the link, that’s a really nice and understandable explanation.

By the way… 9 and two dots. ONLY 1 DOT TO GO!

9 and 3 dots… I have a horrible feeling that this last dot is never going to finish…

#10

How many CPU cores @ what speed?
And yeah, as it progresses it takes longer and longer to do each calculation.

#11

Quad-core, and I think 3.33 gHz. I’m not at it and can’t think too well at 2 in the morning, so if I’m far off, meh, I’m far off. Maybe it was 3.66gHz… maybe it wasn’t any of them.

Also, VVIS just eats up the whole damned thing. 100% usage all the time.

And it’s still “Not responding”. Started not responding bout a half-hour ago. I just turned off the monitor, set the volume up high, and am going to bed, hoping to be woken up by a really loud reloading sound some time in the next few hours…

#12

If you have a 3.6ghz quad, and your map is taking that long to compile… You need some serious optimisation. I can compile most of the TF2 stock maps in 15-20 mins.

If you could easily take on board the link in my other post, maybe take a look at https://optimization.interlopers.net/ for a more detailed explanation on optimising. It also explains stuff like func_detail in more uhh… detail (no pun intended :wink: )

#13

Yeah, well it decided to crash at 9 and three dots, so I’mma go through and do some serious hint-work. Make sure I didn’t leave any massive-polygon behemoth’s laying around… I func_detailed the well, it’s base, and several gate-structures in the level, and that made it get to 5 in about five minutes, and from there it just took exponentially longer. I have a feeling there is ONE LARGE thing that I’m missing. Gonna take a closer look at the portal file today.

I feel like if I get this map to compile right, I won’t have trouble in the future.

New Question: How are func_details treated differently, if at all, by lighting?
Will I lose lighting quality on them or will making a tunnel a square and making the “arches” func_details keep all the light-y-goodness and cut down on leaf-splitting badness?

#14

Care to post a screenshot from in hammer with func details on and off?

#15

Found another unhappy area in my map. There was a… specific hallway designed in a way to give off a certain feel in which the doors were made in a way other than regular L4D doors, they actually had a frame rather than a decal on the wall around them. I simply turned the frames to func_details, and now the rooms are separated by visleaves, but no longer ripped to shreds by the visleaves flying out of the frames.

EDIT: My latest attempt to compile (cut short by an accidental iced-tea-bottle/power-button incident) was running a few minutes ago, and it was only taking 64-80% of my CPU… I think the fact that it’s no longer raping my computer means I’m doing something right.

UPDATE: visclustered the aboveground area, started compiling five minutes ago. It was at 6 and one dot when I left the room a few moments ago.

UPDATE: I just went back to my room. It’s only been like 10 minutes, and its already at 9 and two dots. That’s 10 minutes from starting. I’m gonna viscluster the rest of the aboveground area AROUND the lone house, and that’ll make it even quicker, hopefully. Right now it’s only on one side of the house. By the way, 9 and three dots.

So, up to now I have reduced the portalclusters count from 5000 something to 2072, and the numportals count from 25,000 something down to 6356. I think with a little more hint brushing, I could do even better.

Final update on this post unless it completes successfully: Five minutes since my last post, and its still on 9 and three dots… Is there possibly a known condition where it hangs on to the last tick before completing? That would make me feel better…

I lied. It didn’t work. Got to 9 and three dots, sat there for like… 12 hours, then I ended it. It moved onto VRAD, and finished. In-game, lighting was fine, but I toggled mat_wireframe 1, and all objects were being rendered all the time.

#16

They aren’t affected any differently by lighting. (although if you have huge wall sections tied to func_detail some light may seep through on the edges). For all intents and purposes they are standard world geometry with the exception that they don’t block visibility. Anything like door frames, window trimming, small barriers or railings etc should be tied to func_detail if they don’t block visibility significantly. Anything cylindrical or angular should also be tied to a func_detail unless it is gigantic and necessary for it to be part of the world (the curved silo walls in c2a2b is world geometry, for example.)

VIS should really be taking under a minute or two on a quad-core, and your portal files (if properly optimized) should be free of areas with lots of really tiny portal ‘clusters’ and look rather neat (this is what you’re trying to avoid). As mentioned it should take longer and longer with each dot it adds to the compile log but if it’s taking over 5 minutes and not finished then there are some optimization problems that should be fixed. (The compiler will often say ‘not responding’ during the compile process, but this is normal if you are compiling through Hammer). The reason it finished RAD and was playable in-game but everything is visible is that the VIS process didn’t get a chance to complete, so it’s just rendering everything because it the map has no visibility tables to use.

If it’s taking ages to compile, it probably needs more func_details! Good portions of maps are often constructed of them. Here are two examples, one by Valve;

C17 Trainstation

L4D map with and without func_detail and models

#17

Oh wow. The whole friggen thing was details, lol. I’mma work on that. I’m gonna make all my tunnels square and func_detail out the arched portions, I think that’ll do something for it.

#18

Just remember, func_detail does not seal the world (nor do any other entitys)

#19

That I know. That is one of the few things I know. That’s why I’m making the tunnels square BEFORE making the arch-parts details.

#20

Hey, just got back to my computer after X-mas break, and I booted up the L4D2 Dev Kit, continued with hint-brushing and func_detailing, and got it to the point where the compiler (which must have been optimized to work with W7, because it no longer crashes or freezes when I move my mouse, and I can even to THIS now without it crashing!) goes through the PortalFlow faze in about 5 minutes…

HOWEVER: PortalFlow gets caught at “9…”… I’ve just about done all I can do as far as optimizing goes without compromising my map. Has anybody else ever had this problem?
It’s still running, and has been for approximately five minutes since it hit “9…”, and I plan on letting it run for another fifteen minutes, but figured I’d post this, because I doubt it’s gonna move on.

EDIT: Still running… In the time I’ve spent trying to get this damned MAP to compile, I’ve started work on a more successful, if not rather mundane HL2 mod… I think its only a matter of time before I drop this entirely, heh… I think my big problem with this map is really smaller than I’m making it out to be… I just have to make a drop a bit longer and make a tunnel section no longer inside of the world, but outside… If that makes any sense. That will be tomorrow’s project!

Founded in 2004, Leakfree.org became one of the first online communities dedicated to Valve’s Source engine development. It is more famously known for the formation of Black Mesa: Source under the 'Leakfree Modification Team' handle in September 2004.