I remember reading somewhere that the new update came with vertex lighting for models. What exactly does that mean? How are models currently lit? I've assumed that a model is lit based on the light at the model origin. Is that correct? So what does vertex lighting do?

I'm guessing it will be a new option available when placing models in the SDK. I'm also assuming that you wouldnt do this for all models as I'm sure it'll be more expensive (performance-wise) to calculate light this way. That a safe assumption?

So will this help the problem I'm having where a long pipe model is lit funny because it runs through a tunnel that's only lit on one side?

Thanks for any, ahem, *light* you can shed on the matter. Get it? light? Thank you, thank you, I'll be here all week...

I am curious too about this topic, which leads me to a related question. Not too hijack the thread, but it has been a recurring problem of mine.

My map is fairly dimly lit throughout and I am very happy with the way world geometry is looking in it, but the models are all way too susceptible to darkness. I know the purpose of the info_lighting entity, but using it on every model would be a bit overboard and is just asking for confusion. Any other way to affect static prop lightness?

None that I know of. Besides I wonder how confusing it really can get. If you name your lighting entities right, it shouldn't become too much of a hassle

Originally posted by Dustin Diamond
So will this help the problem I'm having where a long pipe model is lit funny because it runs through a tunnel that's only lit on one side?

That was the point behind it, and vertex lighting was supposed to be available along with the dod:s update, but isn't (just like the updates that make the SDK usable at all). I don't think using it would increase bsp size or compile times though, since models don't use lightmaps like brushes. Maybe the .vmts need to be edited to use this type of lighting, but if it is an option in Hammer, it'd need an SDK update which there hasn't been since January.

Originally posted by Dustin Diamond


So will this help the problem I'm having where a long pipe model is lit funny because it runs through a tunnel that's only lit on one side?

Thanks for any, ahem, *light* you can shed on the matter. Get it? light? Thank you, thank you, I'll be here all week...

Just FYI..

Theres an entity in the source engine that will light whatever model you want from its origin instead of from the models origin. I dont remember the name of it but I remember seeing it in hammer awhile back. I think it might even make mention of it in the prop_static options.

Originally posted by MeleeMe!
Just FYI..

Theres an entity in the source engine that will light whatever model you want from its origin instead of from the models origin. I dont remember the name of it but I remember seeing it in hammer awhile back. I think it might even make mention of it in the prop_static options.

It's the info_lighting entity already mentioned in this thread.

Yeah i've been using the info_lighting entity on models that are lit horrendously bad, but it's just a real pain to do it for each one.

And still, using info_lighting doesn't really help the long pipe issue, since I still have to pick a single place from where the model will be lit.

Lighting has to be the single most annoying thing to add and perfect in map. THere's no way to know what subtle changes will do without running a full RAD compile. Pain in the rear, i tell ya.

Say, do you think it's a spawnflag for the models? Do either of the new maps use it, ya think? We could use entspy to look at any suspicious models and see if their flags were changed... Just a thought.

Can anyone verify if this actually works? Vertex lighting, that is.

I removed all the info_lighting entities and recompiled my map after the SDK update. The lighting problems are almost EXACTLY the SAME as before the update. Bummer. It's as if the vertex lighting business is not actually on.

For the record, i did use the Batch Compiler to compile this, as it frees up many more resources. I'll try it again with Hammer's compiler, but I'm quite confident it'll be the same.

Any one else notice any evidence that it does or does not work? I'll post pictures tomorrow when i have time.

There's 2 new options for vertex lighting for prop_statics since the update, I don't know what they do, but they're both enabled by default.

Ok, I have my proof that it doesn't work.

I made a tiny test map. Just flat ground. Then I made a little room and lit it with some small light. Next I placed 4 identical props (crates) in the room. I sunk 3 of them into the ground until their origins were below the ground, insuring they would be lit incorrectly using origin lighting. Next I toggled the settings for each one.

For the Hammer view below, the following flags are set for each crate:

Crate 1: Disable Vertex Lighting - NO
Disable self shadowing with v.l. - YES

Crate 2: Disable Vertex Lighting - NO
Disable self shadowing with v.l. - NO

Crate 3: Disable Vertex Lighting - YES
Disable self shadowing with v.l. - NO

Crate 4: Disable Vertex Lighting - NO
Disable self shadowing with v.l. - NO

http://www.unc.edu/~alricha5/dodpics/hammerview2.jpg
http://www.unc.edu/~alricha5/dodpics/testmap2.jpg

As you can see, none of the vertex lighting options did anything. The only instance where the crate was lit was the one whose origin was above the ground. Bummer.

Anyone have any ideas?

I was working on stuff today, and I had a feeling the <3<3<3<3 wasnt working.

Thanks for making it totally clear.

hmm...

It works with Displacements though, not solid brushes.

Does anyone know how we could find out if this feature (vertex lighting) was intentionally left out of the SDK? Will it be added later?

It's not exactly a bug or support issue. Just curious if anyone had closer ties with someone on the dev team they could ask.

...regarding the crate lighting

Maybe they are not properly lit because they are outside of the map?(it appears) Did you not get a leak error when compiling?

like Ultranew_b said..............



Have you tried making the floor a cubed brush (nodraw the invisible ones) and make the floor a displacement surface without messing with the actual geometry? Might allow the lighting to do what you want.