Pitch black static props w/ dynamic lighting? (lights that turn on and off)

General Development Source 1
#1

In Office Complex in BMS, on the first level you pull the lever and lights turn off. Everything works fine. Lights on, lights off - all fine.

When I do this, even when all lights are on, all of my prop_static entities are pitch black. When I added cubemaps, I could only see cubemap reflections on pitch black models.[/size]

I tried compiling the Office Complex map myself - no issue. So, it’s not compile settings, it’s something in the map.

Anyone got any idea as to what could be causing this? Thanks a lot!

#2

Well, so far I’ve only managed to figure out that it probably has to do with naming lights. But, I tried the same on a test map (naming lights and making them turn off on a press of a button + static props), seems like there’s no issue there at all.

It’s as if it broke the VMF file, so no matter what I do it compiles wrongly. Weird.

When I come home, last thing I’ll try to do is un-name all my lights, see if that fixes it.

#3

Lights should ONLY be named if you are planning on turning them on/off via I/O. The engine treats named lights completely differently from unnamed lights and there are very strict limits about named lights (only up to 4 different named lights allowed before the engine freaks out).

If you have lights that are named that you aren’t turning on or off (which should be 90% of your lights), then you need to remove their name. If you have lights which turn on/off at the same time (for example many lights in the same room that are tied to a single switch), they should all share the same name.

Let me know if this helps. Source is VERY particular about lights.

#4

Here’s what I had:

light_spot entities that are constantly on
light entities that are constantly on

light_spot entities that ‘flicker’ using logic_timer
light entities that ‘flicker’ using logic_timer

Upon pressing a button/pulling a lever = all of them turn off.
But, right before turning off, I’d disable/kill logic_timers of flickering lights.

https://i.imgur.com/fsP9BIm.png

EDIT: There’s a chance that I named a light but forgot to make it turn it off, and fixed that, but the broken lighting stuck. That could’ve happened. Or something similar. Either way; seems like broken lighting is stuck on the level no matter what I do, and it only affects static props.

#5

Post your compile log.

Also if you have more than 4 different named lights in one area, the compiler will ignore all of the lights and the lights will not show, the compile log will mention this.

#6

If that’s happening, it’s highly likely that your map isn’t recompiling properly. Make sure the map is successfully compiling with no errors at any stage of the compile process.

#7

Ok, it might not be 4 max, it just looked like that way when I tested it.

Apparently it’s… 2?
https://developer.valvesoftware.com/wiki/Naming_Lights

“VRAD attempts to avoid this with its hard-coded limits of two switchable lights affecting a brush face and 32 pages in total.”

#8

If it’s 2 max, then that was the problem; I had 3.

HOWEVER, all the lights did compile and they all work, it’s just that static props did not receive them. The only way I could light up static props was by using flashlight.
Dynamic and physics props work fine.

But, even when I removed all of differently named lights, the issue persisted, as if something wasn’t being overwritten.

I will tinker with it a bit later and tell you all I find out and give you compile log.

It’s really weird, the only time I ever witnessed this was in CSGO after the Wildfire update, but all that had to be done there was put the “-StaticPropLighting” parameter in advanced compile settings.

#9

When in doubt, post the compile log.

#10

I’m redoing the whole thing, step by step. I want to know at which step it happens exactly. I will post more details tomorrow.

Done so far:[/size]

  • Completely removed lighting (just selected all lights in entity report)
  • Removed all flickering lights with their logic_timer entities
  • Selected and copied the whole map to a new VMF file.
  • Added some unnamed lights
    No errors so far. Next, I will add more lights, then try to name them, see if any errors pop up.

loggies.zip (4.02 KB)log (zip)[/attach] -> this is the broken map log btw

#11

I have run into this when recompiling Office Complex.

A quick fix is to make whatever props are not being lit prop_dynamic_override. If they are still not lit there is indeed something wrong with your map, however I strongly believe that there is an actual bug in here as well.

#12

Yeah, that worked when I tried it originally (since I instantly noticed it only affected static props), however dynamic objects don’t render proper shadows.

I am re-trying the thing completely, and I’ll tell you exactly at which point it bugs out IF it does. My theory so far is that I had 3 differently named light entities which caused the bug, but the bad lighting got embedded into the VMF or somewhere else, so fixing it wouldn’t actually fix it.

#13

That isn’t possible. VMFs contain no lighting data whatsoever apart from lightmap scales.

As I said, the only way that lighting would stay broken in the BSP after you’ve fixed it in the VMF (if you have fixed it in the VMF) is if the map is stealthily not actually recompiling properly, which can easily happen even with a seemingly successful compile. Make an easily visible change to your map, and see if it carries through through the recompile. Easiest way to see.

#14

Even after renaming it and re-saving it and fixing all the potential causes; the issue persisted. The only time I managed to fix it is by selecting the map and copying it to a brand new, also differently named, file. The map was recompiling properly to the point where any changes I did were there - removed a light, added a light, moved a prop, changed prop type, added some props, etc. All of those were compiled, yet static props remained black.

Now, I am doing lighting from scratch in a new file and I will first experiment with no more than 10 light entities overall, and I’ll tell you results tonight.

I mean, I wouldn’t be here all confused if something REALLY weird wasn’t going on.

#15

I would be extremely surprised if you managed to get statics to light properly; as near as I can determine the issue is universal.

#16

I feel like I’m missing something here even though I’ve reread this thread a few times. I’ve never seen this issue before, how is it universal exactly?

Another question: are you compiling the map with HDR only? Is the an env_cascade_light entity present in the map? Maps for BMS should not be compiled with LDR - this could be causing issues. If there’s an env_cascade_light entity, and you’re compiling with CSM, you need to enable skiplightmap in the env_cascade_light entity, otherwise there will be lighting artifacts (because you are using named lights/lightstyles, which don’t play well with CSM unless you enable skiplightmap).

Or if your map is not meant to have CSM (no environment light) there should not be an env_cascade_light entity. This could cause additional problems.

Alternatively, send the VMF my way. I can take a quick and dirty (giggity) look at it for you.

#17

I’ve simply always experienced this problem in every map I’ve tried to compile since migrating to the retail version, where named lights otherwise work perfectly (within known limitations).

At this point I’m wondering if we should get people posting system specs.

#18

Sorry for the delay and stuff, I was very busy. I’ve put several light entities in the map, one unnamed, others named same and they turn off. All works fine now. My map is completely indoors, so there’s no cascade lighting entity, no and, yes, it’s HDR. I will keep you guys posted, especially if this issue occurs again. I had static lighting working properly before, it’s just that for some reason this bug occurred, which is probably due to more than 2 names given to light entities, the only real issue was why the bug stuck even when it should have been fixed. Either way - all fine now. I’ll keep you posted!

And, regarding system specs: Sapphire R9 270X + AMD FX-6300 + 8GB RAM.

This was the first time to encounter this issue, maybe with my tinkering if I encounter it again we finally get to the bottom of it and see what’s actually causing it!

TL;DR 1 name for all lights that turn off, one light unnamed and doesn’t turn off - no artifact.

#19

As Lordz said above, that will be because of the limit of up to 2 named lights per face, or 4 for the entire map. It’s to do with lightmap pages. So yeah, if you want to have a bunch of lights in a room turn on/off at the same time, they all need the same name. VRAD treats them as a single light because even if they’re all different they collectively only use up a single lightmap page.

Doesn’t quite explain why that would make the static props crap themselves, but I’m sure it’s related.

#20

So I guess that if you want more than 2 blinking lights to go off at different times, you could name them the same and then use:
OnUser1
!self
turn on/off.

with different delays.

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.