Hi everyone! So I'm getting into Portal map editing lately. I'm good with the mechanics and textures so far, but lighting is annoying for me. Before you criticize these screenshots, note that I'm not releasing this map. It's a newby test map. Two issues:

In this pic, how do I get a good fluorescent lighting effect? Ignore the lack of details. I want to use many types of fluorescent lights in my real maps.

In this pic, these are func_brushes parented to a func_door. Initially, they were part of the big wall. But, they can't be dynamically lit, which makes them look bad. What's the solution to this?

Thanks for reading my awesome post!

Not sure about your lighting here. If you are sticking with the generic portal style, you would have little holes in the wall with the back textured as the white001 texture. And for more accurate lighting I would recommend having that door's state be as open in the beginning, then close it when you start the map. E.G., put the setup in the "open" position, then tell it that the move direction is outwards away from the wall and that it should start closed. I think that's how you would get it to be lit correctly and start closed.

Awesome idea with the doors, that should work. Yeah, I guess I could make ceiling holes, but for some reason the holes annoy me a bit. That's why I wanted to use fluorescent lights. Thanks!

EDIT: Just so I know for sure, there's no way for brushes to be lit dynamically, eh?

Gamergull wrote:
Awesome idea with the doors, that should work. Yeah, I guess I could make ceiling holes, but for some reason the holes annoy me a bit. That's why I wanted to use fluorescent lights. Thanks!

EDIT: Just so I know for sure, there's no way for brushes to be lit dynamically, eh?

Models are the only things in source that are dynamicly lit. So unless you made it a model, no.

I ran into the same problem with a bridge I wanted to make close when triggered. It's because the brush gets it's light from the outside world instead of inside the room. (outside world = pitch black)

Yeah so just make it compile the brush on the inside and then use a logic_auto to shove it into the wall at the start.

Actually, there IS a trick that I personally found to light a brush dynamically.

It all depends on the material. All the materials that hammer lets you apply to brushes are lightmapped (static) or unlit. I was able to successfully make a new material file for the concrete wall (for example) that is set to "vertexlitgeneric" and put it in the materials folder. I applied it in hammer and made a physbox with it, and it worked.

All you need to put dynamic lighting on a brush entity is to make a new material file with the vertex lighting shader and the same base vtf as the wall, put it in the materials folder, and apply it.

I don't think anyone's ever done it before. I found this out myself.

King Of Sandvich wrote:
Actually, there IS a trick that I personally found to light a brush dynamically.

It all depends on the material. All the materials that hammer lets you apply to brushes are lightmapped (static) or unlit. I was able to successfully make a new material file for the concrete wall (for example) that is set to "vertexlitgeneric" and put it in the materials folder. I applied it in hammer and made a physbox with it, and it worked.

All you need to put dynamic lighting on a brush entity is to make a new material file with the vertex lighting shader and the same base vtf as the wall, put it in the materials folder, and apply it.

I don't think anyone's ever done it before. I found this out myself.

Actually, many, many people have done this. The problem?

Vertexlitgeneric does NOT work well on brushes. it is heavily not supported, or you get issues:

Badly lit brushes
textures not appearing
screwed up lighting through/near the brush with the vertexlit face

IDK what your doing though, maybe if a brush can move dynamiclly (physbox) then the problem is avoided? Did you see if you could add phong to it? (probably not...)

Oh. I've never heard of it being used before. I know it's far from perfect, but I've got it to work to some degree. I would only ever use it on something that would look awkward if its lighting DIDN'T change, like a physbox, tracktrain or door.

• I think it depends somewhat on the face count. A sphere looks much better lit than a cube, probably because it has more verticies for the vertex shader to work with.

• Splitting a larger brush-entity object into smaller brushes works here. I was trying to make a giant floating cube in my testmap, and didn't like its static lighting. When I made it vertex, the whole thing was a func_brush, and walking around it made its lighting make weird jumps. Splitting it into 16 separate func_brushes made the lighting more smooth.

• Adding Phong DOES help. I took your advice and now it looks so shiny! I don't recommend major use of cubemaps here. It looks too static that way.

Check this out. Everything except the blue stripes on this cube is vertex lit. It DOES move, so there is reason to make it lit this way. I'd tell you my plans for this thing, but then I'd have to kill you with a rocket turret. I took this shot today, after I added Phong.

Here's a vmt for one of the materials on this giant func_brush Storage Cube:

"vertexlitgeneric"
{
"$baseTexture" "plastic/plasticwall001a"
"$envmap" "env_cubemap"
"$envmaptint" "[ .03 .03 .03 ]"
"$bumpmap" "plastic/plasticwall001a_normal"
// "$basealphaenvmapmask" "1"
"$surfaceprop" "Metal_Box"
"$selfillum" "1"
"$phong" "1"
"$phongexponent" "50.0"
"$phongboost" "1"
"$phongfresnelranges" "[5 1 2]"
// "$halflambert" "1"

}

King Of Sandvich wrote:

}

wow, that looks like a model. Except its kinda low poly.

Well consider me wrong, I thought it simply couldn't work. (Then again, now that I think of it I have never used it for non-static brushes)

Good job on experimenting, you just made brushes have phong. As far as I know your the first person to do so, and quite well if I may say so. (Also, with lighting, try giving the whole cube one hammer smoothing group, I would reccomend lightmaps but it wouldn't effect it...this should, as it suggests,"smooth" the lighting between faces. IDK if it will work perfectly on vertexlit but if it functions similar to smoothing groups in modelling programs you should be good.)

Ghetto Cube FTW!

EDIT: But now I am curious. Would this work if you parent the func_brush to something, move it, move it back then unparent it, and kill the thing that moved it?

Thanks for the suggestion, but the smoothing groups don't work that way (or at all)...

It's already parented to a tracktrain, so to test what you said I moved it then unparented it and deleted the tracktrain. Nothing went wrong. I even tried it with a func_detail and everything looks fine. It all relies on the vmt and the shader. Everything shader-wise is done at runtime, so as long as the vmt specifies it properly, anything can receive dynamic lighting. It's just only practical on something that moves. Any troubles I had earlier were the result of the vmt, (ex. I removed some keys associated with cubemaps because they make every vertex material in the map buggy). It took me several rewrites and copy/pastes from working materials to make a vmt that worked. It should now work with anything.

There's a reason I made it like it is. The cube itself was in development before I realized I could light it this way. It's big because it holds something. There's already a lot more to this cube than the screenshot shows you, and I'm lucky it turned out even this well.

EDIT: Fun fact of the day: While testing this, I learned that Portal Turrets will shoot at func_physboxes if they are moving. I have no clue why.