Requesting tutorial for cubemap

After browsing through all the resources at the SnarkPit and VERC (and the SDK documentation), I am still unclear on the concept of using a cubemap. I know why it's necessary and what it does, but I am not sure how to implement it in a map.

For example, where is the best location to put the cubemap? I know it needs to be higher when reflecting player models and lower for stuff like water or floor, but where does it need to be in a map? In the exact center of the room? One for each room? Only used for contrasting lighting (i.e. indoor vs. outdoor transition)?

If anyone would be kind enough to write a tutorial on the subject (and put it in the newbie section of the tutorial), I would be forever indebted to you.

I have the exact same problem...

This is my experience so far. I'm sure some of the vets can add more or correct me if i'm wrong:

The cubemap should be thought of as, in general, an asthetic entity. If you have a room that has textures (materials) supporting it (not all do) and place a cube map inside the room all the supported materials will have a nice reflection aspect once the "buildcubemaps" command is generated on the map. The cube map effects have distance. If you leave it at default then the materials in-range (based on internal material values or something else not otherwise editable from Hammer) will utilize the cubemap. If you specify a range then any supported material within that range will use it. So, yes, for any room you want effects generated, and based on range to each material and the materials default range values, it'll happen if theres a cubemap in it. You must have a valid skybox in the map for cubemaps to work. The skybox does NOT have to encompass the entire map at all. You can have a 64x64x64 box somewhere that, if created as a proper skybox, will be used for "all cubemaps" in the level. No clue what happens if you have multiple valid skyboxes, including multiple with different sky materials. I figure it'll probably just use which ever one it iterates first but that's a guess.

Expesnive Water (not sure about cheap) simply needs (requires) its own cubemap, with the water surface selected as the "picked" face for that cubemap. A LOD is NOT required for water unless you want to manually specify the ranges at which expensive water transitions to cheap (performance).

One thing to note. I have encountered certain textures that act badly regarding lighting. Looking at them at certain angles makes them suddenly appear brighter/darker, etc. For that junk I simply chose other textures that don't produce that behavior.

From what I've seen there is no need to "pick faces" for cubemaps that are not tied (there for) water effects. Not sure what effect, if any, picking a texture face in a room for a cubemap does. I only know the cubemaps work great without having to do anything except put one in there, nothing "picked".

EDIT: CORRECTION
I did an experiment because I was curious if I was correct about the distance. I was wrong. The distance of a cubemap from a material that supports it doesn't matter at all, at least up to about 1000 units or so, probably to infinity unless it's affected by max leaf-size cuts. If there's a cubemap and a material that supports it, it can be WAY the hell away and the material will reflect. Furthermore, and taking the facts listed by Leperous and Reno, leads me to think the distance values are actually related to the max distance from which the given cubemap will sample the architecture for reflective effects on nearby material.

I personally just bung them inside rooms with metallic/reflecting textures. They exist to generate reflections of the surrounding architecture on a surface, and these are calculated from where the env_cubemap entities are placed- putting them in the middle of a room or by the floor doesn't seem to make much difference.

As stated above, you don't really need to pick a face or do anything fancy with them. Put one in each shiny room, and run buildcubemaps in the console every time you re-compile.

You were also right on the ball about placing them around contrasting
lights. In Echo I have orange lighting behind some grille's and the
floor underneath this reflects light, and if I don't place cubemaps
inside these little areas then the reflection is entirely the wrong
colour and looks horrible.

I think this thread negates the need for a tutorial. I have a fairly good idea how to utilize the cubemap entity now. Thanks guys.

One of the reasons I brought up the topic was that I noticed messages when I load up a map with tile texture but wasn't equipped with a cubemap. These messages say something like "rebuilding map without cubemap...ignoring texture tile/floor etc..." I just felt that I was short-changing the map's aesthetics by not providing it with a cubemap.

I have a quick question regarding cubemaps. When a map is compiled and the command "buildcubemaps" is given, is the effect then permanently embedded into the map or does the command have to be given every time the map is run? I'm a little confused on this issue. Why doesn't it just compile with the map in Hammer? Or does it? Thanks.

Yes, when you do "Buildcubemaps" the game re-writes the .bsp file to
embed the cubemap textures into it. As long as you've done this before
you distribute the .bsp, nobody else will have to do buildcubemaps on
loading the map.

The .bsp files actually have an embedded pak file in them (same format
as a zip file), where the cubemap textures are stored (if you look at
them, they are the bitmaps that flash on the screen when you do a
buildcubemaps). It seems HL2 will preferentially load any files
referenced by the map (textures, models, sounds, etc.) from this pak
before looking in other places.

I'm currently writing a program which lets you add and remove files
from a .bsp's pak, so you can embed textures into the .bsp, like we
could for HL1. (Why valve didn't build this ability into the compile
tools I don't know).

Buildcubemaps uses the in game engine to capture images of the
surrounding scenery and uses these for effects like reflections. It
needs to run in game because it is essentially taking screen captures.
Once you run the command it updates the BSP, so you only need to do it
once and then distribute that BSP, nobody else will need to do it. If
you recompile your map though, you will need to re-run buildcubemaps in
order to remake them and update the BSP.

You guys are awesome. Thanks for the good info.

<DIV class=quote>
<DIV class=quotetitle>? quoting MeatStick</DIV>
<DIV class=quotetext>One thing to note. I have encountered certain textures that act badly regarding lighting. Looking at them at certain angles makes them suddenly appear brighter/darker, etc. For that junk I simply chose other textures that don't produce that behavior.
</DIV></DIV>
Same here...I believe its from using model textures on world brushes, they seem to be the only ones that do that.

...because they're defined as VertexLitGeneric in the VMT which isn't a functional world brush lighting method as opposed to LightmappedGeneric as most of the normal world textures are.