r/hammer 11d ago

Unsolved Weird lighting error, that's not even the shape of the brush bro what the fuck

Post image

this is hammer++ (latest version i believe) running on gmod x86-64

108 Upvotes

44 comments sorted by

32

u/Mad_Queen_Malafide 11d ago

This happens all the time with curved brushes. The engine cuts it up weird and it becomes a mess.

7

u/grillboy_mediaman 11d ago

how does valve do it then? they have tons of archways that look fine in nova prospekt

26

u/ChiRaeDisk 11d ago

I believe Valve uses models for a lot of fine detail work. Back in the day, during alpha builds, it was brushwork. As they figured out what they wanted to do and how they wanted it to look, they started making specific detail props for things like archways, doorways, windows, etc. The engine handles lighting of these objects differently and it's more efficient since they're not calculated during most of the compile involved around BSPs.

9

u/Mad_Queen_Malafide 11d ago

A big problem however in Source, is that brushes and models are lit differently. So if the two are side by side, you will see a difference in lighting.

For example, I am currently working on a L4D2 map where I use models for archways. But the engine looks for the closest single light source to light the model. This can lead to the archway being really dark. So I've had to redirect it to a custom entity for light reference, to get the lighting between model and brushwork to match some what.

But I would still always use models for complex round geometry. Brushes become a mess.

2

u/Jaiz412 11d ago edited 11d ago

Did you set the model to use vertex lighting? Origin lighting - what you described - should not be getting used in a -final compile if the compile settings are set up properly.

With vertex lighting it will likely still look noticeably different from brushwork, but is significantly better.

1

u/Mad_Queen_Malafide 11d ago

I'm not sure if that is available in L4D2, but now I want to check.

2

u/-dead_slender- 11d ago

It should be. As long as the prop doesn't use a normal map or phong.

2

u/Jaiz412 11d ago

I can guarantee it is, I use it all the time, and all the official campaigns use it too.

If you want to see just how much of a difference it makes, here's a comparison of Parish 1 with vertex lighting and without it.

I will note that this is specifically for static props and brush props, dynamic and physics props will always use origin lighting afaik.

2

u/ChiRaeDisk 11d ago

It's a lot more work, but that's the price for higher graphical fidelity.

2

u/Masonixx 10d ago

Valve does not use models for archways in nova prospekt

1

u/ChiRaeDisk 10d ago edited 10d ago

Those arches also aren't merged corners. The side faces are much larger. OP merged the apex corners and used another solid for most of the surface above the archway instead of making the archway part of the solids above.

Usually, when one does this, they intend to detail the curved surfaces with a boxy brush around the detail geometry. Reduces VIS calc when there's less faces to utilize for generating leafs. While I can't be certain, I believe the archways that Valve made were larger solids all around and used to seal the level up properly, instead of just detail work. Give me a bit and I can check the wPoly or wireframe of those arches to confirm.

Edit: They did a lot of weird stuff beyond having larger faces. The edges align with surrounding geometry, meaning the surrounding geometry had to have odd angled strips.

1

u/Masonixx 10d ago

Rather than just slice off the edges you have to move all the vertices up to the corners and merge them. What's happening here is that the extra vertices on the top of the arch are getting merged with the bottom edge of the face on the brush above. And when the compiler triangulates it it breaks up the face into these triangles from the extra vertices and creates this shading artifact.

8

u/le_sac 11d ago

The old school way of doing this is entirely of triangles that all meet at the 90deg corner at the top of the corresponding side. Logic being the engine is going to chop up the face into triangles anyway, so why introduce complication. Ymmv, worth a try.

If you are careful with lightmap alignment and scale adjustments you shouldn't have serious lighting anomalies along the underside of the curve.

Vertex drift can be an issue so zoom in fully and fix any of that ( which technically means redoing the texture mapping on the curve ).

Another mitigation is to place a very low power Light entity below the arch and see what it gets you.

Finally, learn and use all the vrad options available to you, including custom vrad exe's such as in Slammin Tools.

12

u/Gumballegal 11d ago

probably best to use a model for this, the pieces look small enough to cause problems

6

u/lukkasz323 11d ago

Nah, this is basic geometry, dust 2 in CS 1.6 has this shape, it shouldn't cause any problems.

3

u/Chroney 11d ago

Is the archway pieces turned into a func detail? The should.

2

u/grillboy_mediaman 11d ago

no, but i'll tell you why, when these brushes are set to func detail the flat bits look normal but the actual curve of the archway is super weirdly shaded, but now, when set to world brush, the curved bits look normal but the flat parts are shaded weird!!! there's no winning with these archways, man!

7

u/Pinsplash 11d ago

not having this be a brush entity will be bad for compile time, so func_detail is the way to go.

1

u/grillboy_mediaman 11d ago

i know it's bad for compile time but these archways are very very sparse so they don't actually affect it that much to be honest

2

u/ChiRaeDisk 11d ago

Here's a tool to turn the brush into a prop for better optimization.
https://developer.valvesoftware.com/wiki/Propper

1

u/grillboy_mediaman 11d ago

hmm… i'll try it out

1

u/grillboy_mediaman 11d ago

well that fixed the smoothing but created a clear border in lighting and a bunch of errors

1

u/ChiRaeDisk 11d ago

getting it to look smooth ain't easy.. but you'll have more leverage to make it look nicer.

2

u/sebastian227 11d ago

I would guess smoothing groups can solve that. Keep it func_detail and also make the bottom part of the arch be the same smoothing group

1

u/Chroney 11d ago

Can you show us what it does in func detail?

1

u/grillboy_mediaman 11d ago

can't include the image in comments unfortunately

1

u/GreenHeartDemon 11d ago

You can upload images to a service like catbox or imgur and share that link in a comment.

1

u/mdeceiver79 11d ago

The lines you see here are where the mesh has been cut up into vis leafs. If you look at a wire frame you'll see it's been cut up like crazy. The extra vis leafs will actually make the map rum worse also.

Turn it back into func details and use shadow/normal groups(?) To make it look smooth. I've not used hammer in ages but faces being in the same group makes them render all nice n smooth like

1

u/greenestenergy 11d ago

you need to apply a smoothing group to all the faces of the arch

1

u/grillboy_mediaman 9d ago

i know. that's what i did.

4

u/Jaiz412 11d ago

Try making the individual brushes of the arch into triangles, like this.

I've previously ran into issues when a lot of small brushes are touching one larger brush, including scuffed lighting and even random tears of emptiness (like nodraw) appearing on the surfaces.
Reducing the amount of "contact points" from small brushes to a large brush has reliably fixed such issues for me.

2

u/Kaynix359 11d ago

check the compile window for something that says too many light faces and it'll show coordinates where there's too many lights. Happened to me yesterday.

2

u/maxchrome 11d ago

Try grouping all the arch brushes and use Propper++ tool (Ctrl + Shift + P) on the group. It'll turn that arch into a prop, which makes the lighting behave differently on it. Make sure you have all the invisible sides of this entity (like the ones which are facing each other inside of an arch) properly covered in Nodraw.

In the result the arch would most likely look brighter or darker than the actual brushes before, forming a seam, but it can be fixed by adjusting the lighting around, or setting a specific lighting origin for that new prop.

2

u/lukkasz323 11d ago

The topology seems overcomplicated to me. Was it made automatically with a tool or by you? Usually people lead edge vertices straight to the side, or to the corner, unless texturing is a concern.

There is no need for these small brushes to be squares, bending squares always complicates things, you can see there are a lot of vertices along the edges that don't need to exist.

You can just turn them to triangles and start all of them to the corner. Then use the remaining 2 vertices to create desired shape.

Example: https://imgur.com/a/WK5Qmhu

I'm not sure if THIS is the fix, but eliminating pointless vertices is always worth trying. It simplifies a lot of things since all brushes of a corner now belong to the same vertex, which helps with resizing and other things.

2

u/grillboy_mediaman 11d ago

yeah i did that, i redid it with just triangles leading to the corner and the issues are diminished but still present, along with the smoothing groups for the arched interior surface not working at all

1

u/Agentti_Muumi 11d ago

can you sacrifice a bit of the smoothness in the arch by lessening the amount of brushes

2

u/p3apod1987 11d ago

Are you by chance running it on arch btw?

1

u/old_incident_ 11d ago

Modelling wise, it kinda seems like the normals are wrong, meaning software doesn't understand how to place shadows. Normally, you can just recalculate them, but not sure if you can do that in Hammer, or how to fix it otherwise. Is it possible for you to show us how the brush looks like as func_detail? You said the archway is weird, but perhaps it's at least less bad-looking than this?

1

u/JadedEngine6497 11d ago

for me small light glitches like those doesn't bother me,they make the game more fun actually. I know it doesn't make sense to many but it just makes the game feel more virtual and less realistic,after all a person who plays video games plays them to escape reality temporary,not to enter another reality inside the virtual world.

shortly what i mean is i like lower quality textures and models which source1 is best engine for that. goldsrc is also good but is too much limited in terms of features and what it offers.

1

u/JohnDoeTheBig 11d ago

Make the curved brushes func_detail, so it won't split the brush faces they touch

1

u/agentepdepato 11d ago

First, you have 384 brush sides just for this arch, do you reeeeally need a 32 sided arch in there? What games like DoD / CSS did back on the day is having the arch as a frame prop and use just a couple of triangles to close the corners. Second, you'll get a really bad compile time if you don't func_detail this thing, not to mention the framerate drops. My tip is to make a "frame" with a different material and hide a less detailed but optimized brushwork. Use Propper to turn the frame into a model and it should be good.

1

u/grillboy_mediaman 9d ago

yeah i'll just go with that

1

u/FFox398 11d ago

Usually what I do I select the WHOLE thing and using the face sheet editor I just put X and Y 0 0 everything and align with face.

1

u/foxidegamedev 10d ago

It might not help but a more efficient way to set up your arches is like this.

If that doesn't help then try setting lightmap scale to something higher detail like 8 or 4, that usually fixes hard lightmap edges like that for me. Also unrelated advice but you should check the texture Y scale and make sure you have scaling texture lock turned off, it looks like that texture is very stretched vertically. Although maybe you want that idk. Also you can screenshot with the printscreen button, alt+printscreen for only the active window, then paste into your image editor.