Hazard Course Remake (AVAILABLE NOW!)

General Development Source 1
#581

You are entirely correct. However, I’m already aware of that. :slight_smile:

I have large numbers of named lights, but 4 unique names shared between them. I need this because the lights turn on in sequence, to make the room feel more dynamic than it actually is.

So I get errors when they illuminate the same faces, that’s all. In my case though, the errors don’t seem to be problematic… so that’s okay. And where they do end up being problematic, some creative use of Block Light brushes seems to do the trick. :stuck_out_tongue:

I’m running my newest version which I haven’t uploaded yet. I dramatically lowered the lightmap scale in some areas, which VRAD doesn’t seem to take too kindly of… it likes to crash when it starts using around 1.5 GB of memory. So I enabled LAA on VRAD.exe, and now it seems to work fine, with a total compile time of 4 minutes, 9 seconds… of which VRAD took 3 minutes and 37 seconds. :slight_smile:

This brings up an issue though… for such a small map with a relatively short compile time, I’m using up way too many resources compiling. Seems like I’ll have to optimize the lightmaps a bit more… the BSP is about 50 KB at the moment, with large area cordon enabled. That’s actually insane for a small area.

Go to Map > Load Pointfile, and follow the red line. It will show you where the leak is.

And Box, you really should spend most of your time on developer.valvesoftware.com… it’s the best Source documentation you can find anywhere, and its Level Design section is the most comprehensive I’ve seen. I started mapping with that site… I’m surprised that you haven’t.

#582

@Text & Dky I did that, and sealed some things.The only problem I’m still stuck with is the red line also leads to places that are already sealed off.

#583

Map > Unload Pointfile

:wink:

Then run BSP again, and if it keeps showing leak errors, Load Pointfile again, fix the leak(s), Unload Pointfile, Run BSP, and repeat until there are no more leaks. Then do a full compile if you want.

#584

Going to try that.
Only used run BSP so far though, and loading the point file again.
Fuck I need to look better :fffuuu:

#585

Yay full compile… it works. :slight_smile:

I’ll upload the latest version.

#586

No more leaks (since the red line does not appear anymore).
VVIS BRING IT ON

#587

Well, it only takes one leak at a time so you may have to run several compilations.

#588

If there are truly no leaks, then when you attempt to load the Pointfile, Hammer will tell you that it can’t find a pointfile.

Also, BSP won’t start complaining into the Compile Log.

#589

It just started bitching.:meh:

@Lars I use VBCT to compile, which gives me the coordinates to the leaks.
Not all leaks ofcourse :U.
@

#590

It’s easier just to use the pointfile.

#591

I just noticed a some walls and func_doors got removed.
And no it was not me.And no hammer did not go nuts by removing all the entity brushes, because things like the tram are still in here.
Did someone outside the team got the document information?Because last week I saw someone named “unnamed” in the chat.

EDIT:Oh great, the pointfiles leads to light entities and prop static that are inside the map :U.
EDIT 2:Now there are less portal leaks, but the coordinates still lead to damn void.
EDIT 3: Seriously like what the fuck?func_doors are suddenly gone.This whole map is falling apart, and it didnt even had invalid solids.

#592

The red line always starts at an entity, goes through the leak, and enters the void.

That’s how it finds leaks. A “leak” is defined as ANY situation where VBSP doesn’t understand what spaces define the world.

Normally it defines the “world” as any enclosed space that has an entity inside it, which is why the pointfile line starts at an entity. If an entity is outside of an enclosed space, or if the space is not entirely enclosed, VBSP can’t understand what is meant to be the world, and what is meant to be the void. So at that point it throws the “***** LEAKED ******” error into the compile log and refuses to split the map into visleaves.

My suggestion is to ignore the coordinates and follow the red line only.

#593

@DKY

I don’t mean to sound patronizing, so apologies if it does, but did you just bump up the lightmap scale everywhere? That would make VRAD take way longer to compile than it should, and would also make your file sizes MUCH larger for very little reason, and additionally, no benefit in a lot of areas.

In this context I’ll say “high” lightmap scale to refer to the detailed scales such as 8 or 4, and “low” being 32 or 64.

The lightmap scale only needs to be high across high contrast faces. That is to say, along the edges of shadows/edges of light. So, any face next to a light, any face along the edge of shadows. Higher scales makes the edges less blurry as they’re not as compressed. Using a high lightmap scale on a face which is uniformly lit will create a really detailed lightmap with all the data being one colour/brightness value. That’s a waste of space.

Any faces which are uniformly lit should have a very low (think 64!) lightmap scale. Generally speaking, there should be FAR MORE faces on your maps using scales of 32 and 64 than there should be of high scales such as 16 / 8. Look at the Black Mesa maps for an example of good lightmap optimization.

Sorry if you already know all this, or I misunderstood, just trying to help. Just turning up the lightmap scale thinking it makes all the lighting better was a mistake I made for bloody years, it makes map run worse and doesn’t help much anyway.

EDIT: As lightmap are textures, it’s helpful to think of them as such. They’re pretty much just “lighting textures”. It certainly helped me conceptualize lightmapping. Imagine a lightmap scale of 64 represents a 32 X 32 pixel texture, while a lightmap scale of 8 represents a 2048 X 2048 texture. Now imagine a block that’s uniformly lit. Using a lightmap scale of 8 on this block is the equivalent of having a 2048 X 2048 texture, and painting the WHOLE THING grey. When you apply the texture to the cube, it’ll be entirely gray, but will use up all the space/performance that a 2048 X 2048 texture requires. Do the same with the 32 X 32 texture. The block now looks identical to the 2048 X 2048 texture, but will be much easier to render.

#594

I know what I’m doing, thank you very much. I’m careful with my lightmaps, and I always bump up (as in higher number, eg scale 32 or 64) the lightmap scale in areas of extremely low shadow contrast. The thing is, I’m playing around a lot with crisp shadowing and highly directional light sources with high contrast on specific surfaces, so I do need exceedingly low lightmap scales on specific faces. Take a look:

In this example, I spent a good while perfecting the lightmap shadowing on the ground under the grates. It would have been impossible to get that kind of shadow detail without bumping down the lightmap scale to 1, thereby increasing the number of luxels per face. Likewise, the circular edges of the spotlights on the walls would have been ugly and blocky if I had kept them at the standard lightmap scale of 16, yet I also know that a lightmap scale of 1 is not needed since they’re just spotlights with no heavy amount of shadow detailing. So a scale of 4 or 8 suffices in that scenario.

On the other hand, I understand that it’s starting to bloat my filesize and VRAD memory usage, which is why I mentioned that I would start bumping up my lightmap scales (up as in larger number) in areas where it’s not needed. If I left everything at under a scale of 16, VRAD would probably run out of RAM every time and make compiling impossible.

I’m starting to chop up faces into multiple brushes in order to assign different lightmap scales to different parts of the same face. I’m also considering Raminator’s lightmapping technique in certain areas, although I’ll probably never get quite as good at it compared to the way he does his.

#595

Alright, no need to get defensive. I was just trying to help. That scene looks good, the lighting has been done very well. I’m sorry I doubted you. I get the impression I’m offending by saying things like my last post, so I’ll stay out. Sorry. You certainly do know your stuff.

#596

Haha no need to apologize. Any help or criticism is appreciated, really. Feel free to stay in and discuss, since you obviously know your stuff as well. :slight_smile:

#597

That’s right, you two behave, now.

Okay, so apparently Hammer doesn’t like compiling things located in my Sourcesdk_content folder, while VBCT doesn’t like compiling things located anywhere but there. What the holy hell is wrong with my computer.

#598

I just compile in a totally separate folder, D:\misc\Maps\BMS\Hazard Course

Dunno about what you’ve been trying to do. :stuck_out_tongue:

#599

C:\maps\BMS\hcourse, mostly. What I’ve been doing since I started. I might switch over to a dedicated drive for Source stuff, though.

#600

Odd. VBCT doesn’t seem to like my LAA-enabled VRAD.exe.

Sucks.

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.