Hey! I port bhop and surf maps from other source games, but also fix some of the ones tf2 have. I have noticed that in the counter-strike: source maps that do not have env_cubemap entities, sometimes the only cubemap type of textures in materials/maps/mapname is cubemapdefault.vtf. But sometimes a c0_0_0.vtf blank cubemap file is present in that folder. I make this post to ask how this c0_0_0.vtf is being made. I have noticed that after a map repacking, maps that don't have built cubemaps (or don't have cubemaps at all) show the fallback reflection from editor/cubemap (present in hl2/hl2_texture_dir.vpk archives of any source game) on relfective models (like weapons viewmodel) or water shader based brushes that use reflections. (tf2 displays the faces of editor/cubemap in the wrong oder/rotation, jump_elephant_a2, map by Oatmeal. You can see the reflections on the scope of the sniper rifle and the one on the water, even though this map doesn't have an env_cubemap entity) In some of the counter-strike:source maps I have ported, these glitchy reflections didn't exist for some reason. I later noticed that in the files packed with the map, there was a blank cubemap called c0_0_0.vtf, as well as the reflective materials being fixed up to use this specific cubemap. If the paths/materials were fixed up like this by vbsp, that implies that vbsp knows that there is an env_cubemap entity there that will be used later in order to do the buildcubemaps step, and so gets all the paths ready to use the blank cubemaps until they get replaced with actual shots taken from the game (or at least thats how I explain that to myself). The paradox here though is that there is no env_cubemap in the map file. If there is no cubemap spot defined in the map, the compiler shouldn't consider that there is one, right? That doesn't make sense to me at least. This means that at random, this c0_0_0.vtf gets added to your level, meaning that sometimes your map's reflections that you presumably don't want in your level will be full mat and nice, in sometimes they wil show shiny skybox textures on walls, which rarely makes sense in the contexts they are being seen, unless thats the effect you research. But me, as a map porter, I don't desire that glitchy effect in the tf2 ports of counter-strike maps, so i tried to understand how that file was being created in order to use it to remove that reflection, and came to no answer until today when porting bhop_0, made by Badges. When packing the map, I noticed that these famous c0_0_0.vtf files were in the map file. I definetly had no env_cubemap entity in the level, and was pretty excited not to have to work around that issue like I usually do. Long story short, tf2 doesn't act the same as css, and will show the glitchy skybox editor/cubemap reflection anyway, regardless of the name of the cubemaps you have if they are not built (in css, if your file isn't c0_0_0.vtf but you have an other not built and present cubemap, it will still show glitchy reflections). Even if you type buildcubemaps, it won't change anything anyway because there is no cubemap to build. I even tried to run css compiled maps that don't show reflections when played in counter-strike: source, and still in tf2 it shows the reflections. I am sad, but still am interested to know how these c0_0_0.vtf file get generated. After some intense research in the map file (bhop_0 I am porting), and lots of checking after compile, I found a func_detail brush in my level that is, by itself, capable of generating that cubemap file. The reason of this post is because I don't see what is so special about this brush, but I also don't understand what kind of magic is with this mysterious file. So I copied the brush into a blank map with one entity and cordon around it to be sure it could only be that causing it, and it is. You can see for yourself how it happens if you don't believe me, because I myself don't believe me right now. http://pastebin.com/Pv9fTRW8 Just save the content of this text file as any .vmf file name you want. The func_detail brush has 6 faces, and I managed to find out that if you nodraw 5 of them, but let the last one with a texture using an "$envmap" "env_cubemap" parameter, it will create the c0_0_0.vtf and c0_0_0.vtf.hdr files, as well as the fix up for the other texture. Oh, and fun fact, if you make this brush not func_detail (for example, a regular world brush geometry), it will not create the files. I apologize in advance if this post looks as confused as I am right now about this thing, but I heard there were very experienced mappers here who coulld help me find the answer to these type of technical question. I hope I can get some answers about what is actually going on, or if there is just an intended way to get these to be generated and I just got by accident a brush that matches the requirements. Thank you for your attention and I hope you have a great day! Ps: also the workaround I use in order to avoid having the glitchy reflections in the tf2 maps I work on when no cubemap reflections are required is that I delete all the env_cubemaps in the map file if there are any, then I create a low resolution env_cubemap and put it in a 16*16*16 box with "tools/toolsblack" applied on the inside. I also put an arbitrary entity, for example env_target so vbsp counts this additional room as the inside of the level and doesn't wipe it away (if your black room is gone, you will just take pictures of your entire level). Then when in-game, I just build the cubemaps in LDR (for some reason, HDR mode doesn't have any of the issues I described above with blank cubemaps in tf2) and then the problem is solved since vbsp fixes all the materials to use your low-resolution black cubemap. Note that if you put it exactly at the origin of the grid (0, 0, 0), the room around it might vanish still. If you mappers know a better way around that, please let me know too.