Lack of a Bumpmap Causes Props To Light Weirdly

General Development Source 1
#1

Something that has been bothering me for a good long time is the existence of ‘glowing’ props that seem to be much brighter than their surroundings for no adequately-explainable reason (these are not props like light bulbs that have a reason to glow and use $selfIllum to do it; they’re weird things like desks and bulletin boards). By comparing the material files for glowing and non-glowing props, I’ve determined that (at least for many of them) the effect is caused by the lack of a $bumpmap material in the .vmt file- adding even a blank 128 128 255 one will make the prop light much more normally.

I’m posting this not because I demand the devs put Xen aside for the ext year to go back through and fix every last one of these props (I’m more than capable of doing that myself, actually) but as a reference in case anyone else was experiencing this problem.

Once I get a good portion of these props fixed, I think I’ll put them all together into one big workshop addon along with a bunch of other assets and random useful things I’ve created over the course of BMPD- that way people who want to use them in other mods can do so without having to download every restored Black Mesa map and hunt through its VPK.

#2

Shouldn’t you just change the material .vmt and reupload those?
That way the fix would be applied to all props and not just the restored maps.

Or am I missing something?

#3

Originally I wanted this to not ‘interfere’ with the canonical maps in any way, but thinking about it as a fix and not a pre-disaster thing specifically it does make sense to just change the canonical models. I’ll have to do some experimenting to see if this is an issue introduced at compilation, or when the map is run- if it’s introduced at compilation my fix would not affect the canon maps at all without recompiling them.

#4

Just a quick screenshot to show what I’m talking about:

1920×1080

Both of these copy machine models use the same base texture; both have a single brightness-30, pure-white constant light 64 units directly behind them. The one on the left, however, has a $bumpmap parameter leading to a blank 128 128 255 normal map.

#5

That’s… really odd. I’m going to check the vmts myself to see if there’s any other explanation, because I’m 100% the vertexlitgeneric shader isn’t supposed to act like that.

"VertexlitGeneric" { "$basetexture" "models/props_office/copy_machine" // "$bumpmap" "models/props_office/copy_machine_normal" }
Hmm… Yeah, no, that’s really weird. I’m pretty sure the other source games don’t behave this way, but I also can’t think of any reason that Crowbar Collective would have had to modify the material shaders for. I don’t think that the CSM system would have required all shaders to be modified, but then again I know from the Lost Coast commentary that Valve had to redo all their shaders when they introduced HDR, so I could be wrong.

Kind of interesting to see that the copy machine used to have a normal map as well. I wonder if that was a leftover from when they were using CS:S content and the custom version didn’t need a normal map, or if there was one for the BM copymachine and it got cut for one reason or another.

#6

Just experimentally determined (through running the same map with those two copy machines while making changes to the fixed one’s vmt but not recompiling) that the glowiness is determined by the state of the vmt at runtime and not baked into the lightmap at compile. This is good news for a workshop fix as it would not require recompiling the canonical maps, but… well, it’s slowly dawning on me that this issue affects quite a lot of props. So, while I’m not advocating whether they should or shouldn’t look at it, I’d kind of like some confirmation from the developers as to whether they are or aren’t going to be fixing this issue- it’ll probably take me until well after December to tweak all of those VMFs myself, and I’d hate to do so only to have them all be fixed (or the problem removed entirely) along with Xen anyway.

Regardless, however, next step will be determining whether world brushes are also affected by the presence or absence of a bumpmap, or just props.
UPDATE: They are not.

#7

Don’t bother fixing this. I asked our graphics programmer, Chetan, and he said that this happens because non-bumpmapped props are vertex lit instead of pixel lit. This was some kind of CSM hack, from what I can tell.

He said that in the Xen build, all props are pixel lit. So this issue should go away with the Xen update, hopefully.

Nice catch, though! Good bug hunting!

#8

Which is strange, as I remember noticing the problem (with bulletin boards) way before the CSM update came out.

#9

Well, in previous versions of source pretty well all props were lit per-vertex, IIRC.

Really glad to hear that they’re being done per-pixel now, that’ll give us much smoother lighting from here on out! :smiley:

#10

Another (related?) issue is that props with an info_lighting entity attached to them get dimmer as the info_lighting moves farther away, regardless of what is actually going on with the entity’s illumination. Is this also a known issue?

#11

Now all props are lighting weirdly.

1920×1080

This room has two constant lights, one in front of each printer over the middle line of the texture. Each is brightness 20.

#12

Update- this seems to be taken care of by setting the prop in question to use lightmaps.

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.