Still having problems with VRAD and skybox lighting

General Development Source 1
#1

I made a thread about this before, but it’s pretty old, and just reviving an old thread that looks solved won’t help me much.

Basically, whenever I try to use a light_environment to create skybox lighting in my maps, the ambient light turns into choppy, blobby squares, and I have no idea why.

To give an example, this is Black Mesa’s c2a4g map, where you get the Tau Cannon.

1602×900

And this is the same room, in the same map, when I recompiled it from the mapsrc folder.

1600×900

There are only two ways I’ve been able to get it to stop. To either set the light_environment’s ambient to all black, which makes the lighting look really flat and bad, or to use -final, which makes compiling take a crapton of time.

Is there any way to make the lighting look anything close to normal without using -final? I just want my skybox light to look alright before the map is finished so I have an idea of what it’s supposed to look like.

I’ve tried running both Hammer and VRAD in compatibility mode for multiple versions of Windows (I’m on Windows 10 Pro), and I’ve also tried redownloading VRAD, but nothing changes.
This happens on all engine branches, no matter what game the map is in.
Fingers crossed this isn’t normal or else mapping is gonna be a hell of a lot more painful.

#2

what cmd line options do you use with VRAD ?

#3

On most compiles I use -low -both -game $gamedir $path$file.

#4

Have you tried -StaticPropPolys?

#5

Don’t compile with -both. Use -HDR. This will half your VRAD compile times, and none of the BMS maps are compiled with LDR lighting information anyway. So there’s no point. I would also suggest using an external compiler, like VBCT, Compilepal, or even your own batch scripts. Hammer’s compiler sucks big time.

You should pretty much always use -final, along with -staticproppolys, -textureshadows and -staticproplighting. You’re not really testing and tweaking the lighting properly without these switches. Yes it lengthens the compile times significantly but that’s the price you have to pay on this engine to get things perfect. For making broad tweaks to the lighting, a compile with just -HDR should be sufficient.

A potential cause of the issue with your version of that map might be that you’re compiling without the -cascadeshadows switch. I think that map has CSM (but I might be wrong). Compiling a CSM map without the CSM switch can cause some weird issues.

#6

Damn, that’s a lot of info to sink in. Thanks though!

What exactly are the benefits to third party compile tools? I’ve been recommended them a lot, but I’m really not certain it’s worth it for me, since I really only map in hammer for fun and never really make anything original (And also the one time I tried to get a third party compiler, my antivirus went absolute insane).

I can see why all those commands would be necessary for perfecting the lighting itself, but really, I mostly just want the lighting to be smooth while I’m working on geometry and other stuff. That way it’s not so distracting when I’m getting other things just right.
I don’t think it’s a model problem, because like I said in my old thread, it happens on even the simplest map with sky lighting, even when there aren’t even any entities, save for the light_environment and info_player_start.

I did, however, find out that I can make it a lot better if I set -extrasky to 8. It takes a lot longer to compile though.

#7

For one thing, Hammer stops being a potato when you compile using an external tool. External tools also tend to have more features that Hammer’s built-in tools either don’t have, or just have a terrible interface for doing. The specifics depend on which compile tool you use.

If your antivirus keeps acting up, you can add it to your whitelist. Unless you’re ultra-paranoid, in which case you probably have bigger problems to worry about. Probably.

As for not caring about lighting while you’re working on other things, that’s generally what Fullbright compiles are for.

#8

Fullbright is a lot more distracting than even bad lighting, I absolutely can’t stand that.

But thank you, I’ll keep everything else in mind.

#9

Fullbright compiles are a ridiculous time saver, it’s not about whether you can “stand” them or not, or if they’re “distracting”. If you’re not using fullbright compiles for most things, you’re literally doing nothing except costing yourself A LOT of time.

Of course nobody can stand fullbright compiles, they look like utter garbage. But if I’m tweaking an AI sequence or a scripted event, or even just the general design/aesthetic of an area, I don’t need lighting to test that out in game. It accomplishes nothing except adding 20 minutes to my compile time, which also has the negative side effect of making small tweaks prohibitive. If I had to compile the STU maps with lighting every single time I was trying to perfect the timings on the scripting, it would have literally added months to development. Or removed a significant amount of quality from the end product. The vent drop sequence, for example? I probably compiled that…100 times minimum. I would never have had the patience for that in a million years, if I weren’t using fullbright.

The only time you ever need to include lighting, is for when you actually…need the lighting. Such as when you’re tweaking the lighting or when you’re getting a build ready to test or ship. And, as I said before, when you do need the lighting? Do it properly! Use all the relevant settings and final parameters otherwise you’re not properly testing the lighting. The only time you should ever do “quick” lighting compiles (by which I mean using only the -HDR switch and nothing else, please never use -fast VRAD, it’s never worth it), is when you’re getting the broad strokes of lighting tweaked for an area.

You shouldn’t really need lighting for 80% of your compiles. If that’s a personal preference of yours, that’s fine and cool, but it is a personal preference which accomplishes nothing but costing you time. Time which could be better invested elsewhere, or spent actually improving the maps themselves!

And as DKY said, please just try and use an external compiler. Compilepal took me about 5 minutes to set up for BMS and it makes the compiling experience ridiculously smoother.

#10

If I know that my map already has visibility and lighting information embedded in the BSP, a trick I like to use is to run “entities only” compiles when working on entities and any non-aesthetic, non-brushwork tasks. Takes no more than three seconds, and preserves lighting information without having to go through a fullbright compile. Or when I know that I’m only tweaking light entity settings and nothing else (and I know that visibility information is already embedded in the BSP), I will sometimes use “entities only” combined with skipping VIS, which shaves off (admittedly not much) compile time. Works great when using an external compile tool like HTCT, which lets you switch between these configurations on the fly.

Of course, it goes without saying that if you’re not well-versed in the Source map compile process, or if you’re not completely aware of the state of your BSP at all times, you shouldn’t attempt any of that.

Another (much simpler) thing that you can (and really should) do is to heavily use the cordon tool whenever your work only encompasses a specific area. This heavily cuts down on your compile times while letting you work on what’s important. Plus, it clears your 2D views in Hammer so you don’t have to tear your hair out when your map starts to really sprawl.

#11

For what it’s worth, I offset the excess compiling time by doing unrelated stuff on my other monitor.
But that all does make sense. My bad if I’m a bit stubborn with stuff like that.

I mention it pretty much every time I talk about Hammer, but I really just map for fun. Most of what I do is recreating areas from other games, or changing an area from a Source game to look like I want. Never anything to release. I’m no good at actual original level design, hell I can’t even design a Portal puzzle.
That’s why I find it difficult to bother with a lot of the more complicated stuff. A lot of it assumes you’re making a large-scale project with the intent to release, and all that.

Once again, thanks for all the help! Working in a decade-old engine definitely has its downsides. Can’t wait until we get an actual useful release of Source 2.

#12

Also, make sure you open up Black Mesa and then Hammer.

That way you can compile (check the “don’t run game”), load up the map in bms, see if shit is good or not, disconnect in console,
tweaks things in hammer and then load up the map.

Instead of starting bms everytime you want to check something out.
Found out a friend did a compile and started the game everytime he compiled… Cheez julis.

#13

Or don’t even use “disconnect”. Use “restart”, which resets/reloads the entire map and respawns you at the player start.

I actually have a key bound to the “restart” command. Very convenient.

#14

I’ve always used the -hijack command, but it doesn’t always seem to work.

#15

Okay, I haven’t been trying them for long yet, but let me just say, I’m absolutely in love with fullbright compiles and the cordon tool now! I highly underestimated how helpful they are.
I haven’t gotten to trying another compiler yet though, I’ll make sure to get one before I start working again.

Can’t thank you enough!

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.