Help with lighting in L4D (env_projectedtexture)

General Development Source 1
#1

Okay, so I’m really confused about this one.

I’m… moderately experienced in mapping for Source. I’m not overly great at it, I’ve still got a lot to learn. Anyways.

I’ve been doing a bit of messing around and ended up with something similar to Half-Life’s sort of… “drainage” area just before the canal from Unforeseen Consequences.

I want to add a projected texture effect behind a fan in the level. I’m aware it’d be a bit resource intensive, with it being dynamic and all, but I’m having trouble even getting it to appear.

Now, what’s weird is that I’ve read before that env_projectedtexture isn’t supported in L4D (or rather, it can’t be used because the flashlight’s already taking one up). What confuses me though is… I tried using a projected texture earlier on in the map, and it actually worked for a while:

1920×1080 244 KB

Even with the flashlight on, and with bots in-game. Thing is, after I just expanded the level - without adding any other lights or anything - it stopped working altogether:

1920×1080 229 KB

I didn’t change the settings between these two screenshots. I know the level’s kind of barren, I’m trying to get the flow finished before adding in details.

This is how it’s set up in Hammer (haven’t textured the fan yet, though):

1405×496 555 KB

It’s set to Enabled in the Flags, and I’ve even tried compiling without any other lights in the map.

So, a few questions…

  1. Does L4D actually allow proper usage of env_projectedtexture’s?
  2. If not, does anyone know how the first attempt at setting one up worked?
  3. If so, can anyone see anything in the settings for the fan projected texture that should be set differently?

Thanks.

#2

env_projectedtexture generates some pretty crappy shadows unless you’ve modded the game code to remove the grainy shadowing. Plus it’s finicky and prone to really weird anomalies like what you’re seeing.

Instead, you might want to consider using Block Light grids combined with low lightmap scales in order to create the effect you’re looking for. I prefer this method, actually. It does have its limitations, but it’s not limited by runtime restrictions and it’s pretty consistent.

An example:

You might want to be careful though. Although it has near-zero impact on runtime performance, it will increase your VRAD compile times, and too many grid brushes can increase your VBSP compile times as well. It will also bring you considerably closer to the VBSP maximum vertex limit, which means over-abuse of this method could cause your map to fail compiling outright.

Just don’t do anything stupid. :wink:

#3

Thanks!

I’m going to try that in-game and see how it goes.

Two questions, though - First, what kind of light would I want to use for the shadow casting? I’m guessing light_spot, based on your screenshots…

Second off, do brushes with the Block Light texture work properly if they’re part of a brush entity?

#4

You can use whatever light entity you want. light_spot is just easier to control if you want it to be a directional light.

Block Light brush entities will cast shadows as long as you set “Disable Shadows” to “No”.

EDIT: Do you want the fan to rotate and cast shadows too? In that case, this method wouldn’t work since it only bakes static lightmaps during compile, and won’t be able to create dynamic shadowing for moving objects.

#5

1920×1080 212 KB

Yup, that did the trick! Thanks! :slight_smile:

As for the fan, yeah, I was thinking of a moving one. I can cope without that, was just wondering if that was possible.

#6

A moving fan WOULD require env_projectedtexture. Which is annoying. But I guess if you can live without it, that’s cool. :slight_smile:

#7

A few years ago when I sucked terribly I would use a second fan entity, only cover it in the toolsblack texture and decrease the opacity, then place that where I wanted the shadow. It wasn’t too convincing, though. It looked decent-ish a decade ago, now it’s kinda silly.

#8

Mmm, kind of figured. At some point I’ll probably go through the official L4D maps and see if I can find anything, it’s been a while since I played most of the official campaigns but I seem to remember it having effects like that.

Ah, yeah, I’ve tried doing things like that before too (using a fullwhite texture cone to make a spotlight, for instance). Half-Life does that sometimes with light as well, it creates a volumetric light sort of effect. I kind of like it, actually. :slight_smile:

#9

Yeah they probably use env_projectedtexture to make those effects. I’m really not a fan of that entity though. It’s annoying to use in any version of Source that came before Portal 2, or whatever the latest version is.

Anything earlier than the latest version, and that entity has too many oddities to be useful. I also seem to remember that it doesn’t update dynamic shadows unless explicitly commanded to, which makes it even more annoying. But I haven’t played around with it in a while so that last bit might not be true.

#10

There is supposed to be a codefix for the env_projectedtexture. I tried implementing something like that in the 2007 SDK source code but it just broke the game. Can’t run the mod exe at all.

#11

^ And that’s why you don’t play with it unless you know what it does and you know what you’re doing. I hope you saved a backup of your work?

#12

Most of my mod work has been in maps using default content anyway, so it didn’t really matter to the mapping.

#13

Yeah, I’ve heard about that. Haven’t experimented with it though - I hardly know much about level design theory, let alone programming :stuck_out_tongue:

Even then, I can’t edit L4D’s source code, so it wouldn’t make much difference for me anyways.

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.