SDK documentation questions

[o_thedingo]

I've been reading through the SDK documentation on mapping, and came up with a couple of questions:

1. Regarding displacement surfaces, I understand that they seem to be most often used for terrain (ground). However, in the top section of the doc, it says that they do not block visibility. This is confusing - how could the ground not block visibility?

2. I read the section on cube maps and it went right over my head. I got the general idea that they have something to do with lighting, making it look more natural in transitions between different areas. But the rest was greek to me. Can anybody give a more "plain english" explanation of the cube maps?

[o_docwolfe]

you need to enclose all displacement brushes with a solid brush with a noclip texture, otherwise you will get vis errors in your map when you compile, and vis wont run.

not too sure about cubemaps myself... anyone else?

[o_frenchtoast]

About cubemaps, no idea.

In regards to your first question. The displacements don't block VIS. This means if someone is behind a displacement hill, your machine still renders them. You can;t see them though. It's just the way that the game was made. You needto, as docwolfe said, enclose your map completely. Whether you use nodraw brushes or not is irrelivent.

[o_eat]

Cubemaps are for any surface that requires a reflection. They kind of take a spherical snap shot of what they can see during the compiling process. Then this gets used in the reflective surfaces. The most common example of cubemap use is water.

[Defrag]

I don't know how experienced you are, so if any of this seems patronising, my apologies:

Originally Posted by TheDingo

1. Regarding displacement surfaces, I understand that they seem to be most often used for terrain (ground). However, in the top section of the doc, it says that they do not block visibility. This is confusing - how could the ground not block visibility?

They do not block visibility. Vis is a process that is run during the compilation of maps from the .vmf to .bsp format. Vis calculates which parts of the map can see the other parts, thereby cutting down the amount of stuff the game engine has to draw. Only world brushes can contribute to the vis system. Displacements, func_* brushes, props and any other form of map objects / types do not stop vis. Vis simply discards EVERYTHING during the compile process, except the world brushes.

In its most simplistic terms, you can think of it like this. You have room A connected to room B by a corridor with a 90 degree turn in it. Vis determines that, when standing in room A, you can see the corridor, but not room B (and vice-versa). 'Vis-blocking' is the act of splitting your map up into sections that are somewhat 'blocked off' from the rest of the map. Failure to adequately seperate your map into different sections results in the game engine drawing tonnes of stuff that bogs down your performance. If room A was connected to room B via a straight corridor, the engine would draw room A, the corridor AND room B. If both rooms were sizeable or had a lot of action taking place, then it would cause framerates to dip.

A quick and classic example of vis-blocking in action is the well RR. The FD is separated from the RR with a sort of doughnut corridor. The FR is also separated from the RR with a doughnut corridor. When in the RR, you can't see the FR or the yard, because of the corridor walls' placement.

However, don't think that the engine won't see something just because you can't. Put simply, just because you can't see something doesn't mean it isn't being rendered. Load up a map and type mat_wireframe 2 or 3, then check out the stuff the engine is rendering. It's a lot more than just what you can see on your screen itself. The engine renders back to front, so the closer something is to you, the later it is drawn. Therefore you won't see any of the 'useless' stuff that is being rendered unless you enable wireframe. You might think you have blocked off your lines of sight well enough to stop vis seeing from one area to the next, but you have to be fairly careful. I'd draw some diagrams and stuff, but there's a wealth of information out there. Anything written about the .bsp format and vis from quake onwards generally applies to HL2.

Anyway: Displacements aren't considered world brushes. Only world brushes can seal the hull, block visibility and so forth. This is one of the main reasons why displacements are so fast to render, but it also means you have to provide the vis blocking / world sealing brushes yourself. Look at some of the valve example maps if you need to see what I mean. Generally, all this means is that you have to put some flat world brushes under the displacement maps (or inside, whatever) covered in the nodraw texture. I find it helps if I turn the displacements group off (uncheck the 'displacements' tab on the right hand panel) and then create some 'floors' and 'walls' using flat world brushes. Once I'm done, I turn the displacement group back on to see if it's working ok and my brushes are positioned correctly.

I'm pretty tired, so a lot of what I wrote is probably poorly written.

2. I read the section on cube maps and it went right over my head. I got the general idea that they have something to do with lighting, making it look more natural in transitions between different areas. But the rest was greek to me. Can anybody give a more "plain english" explanation of the cube maps?

They're fairly easy to understand. A cubemap is simply a 360 'snapshot' of the area, sampled from the point at which the cubemap is placed in the world. The texture and lighting data is stored, and used to give entities / characters / guns / whatever their reflective / specular (shiny tint colour) properties. Failure to place cubemaps in areas of lighting contrast means that, when running through that area, objects won't have the correct luminance, specular properties and so forth.

A quick example: If you have a pitch dark corridor next to a really bright light, but only a cubemap positioned at the bright point, as you run through the dark area, your gun (amongst other things) will be lit up and reflecting light as if it were nice and bright.

In addition to lighting, cubemaps are also required to correctly form low-resolution environment reflections and stuff when used in conjunction with glass / really shiny surfaces and other things.

I don't fully understand all of their uses or how best to place them myself in all honesty, but I have enough understanding to get by. If you see a surface or a prop that looks weird / out of place, the chances are it needs a cubemap to make it look more natural.

[o_thedingo]

Thanks a bunch, great answers all around! I was into HL1 mapping quite a while ago and used to play TFC like a fiend. It's been a few years, but finding this project on the net has inspired me to give HL2 mapping a try. I'm off to run through the tutorials and refresh my (modest) skills at mapping. Good times =)