What magic is behind the cubemap file c0_0_0.vtf?

Discussion in 'Mapping Questions & Discussion' started by Shadow Sheep, Nov 23, 2016.

  1. Shadow Sheep

    Shadow Sheep L1: Registered

    Messages:
    5
    Positive Ratings:
    0
    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.
    [​IMG]
    (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.
     
    Last edited: Nov 24, 2016
  2. Frosty Scales

    aa Frosty Scales

    Messages:
    83
    Positive Ratings:
    34
    first off: env_cubemap is internal and their location is placed into the vmf by the decompiler. if your only cubemap is this file, obviously the decompiler would not be able to know where to place the env_cubemap entities.
    second: does your tf2 have the envmaps from the cs:s vpk's loaded? (if there are any, i'm not really sure to be honest)
    and last: have you taken into consideration the skybox texture that your map is using? if the skybox textures are packed into any vpk file, vbsp won't automatically generate cubemaps for your map. what i have noticed in the past is that on rare occasions, depending on the map, vbsp will start to inconsistently generate a c0_0_0.vtf.hdr, etc. instead of the automatically generated cubemaps, and i will have matte cubemaps.

    edit: as of making this post i'm extremely tired and probably missed some things, so sorry in advance for that
     
  3. Shadow Sheep

    Shadow Sheep L1: Registered

    Messages:
    5
    Positive Ratings:
    0
    Yes, env_cubemaps that do exist are recognized by the decompiler and placed in the level if the option for it is checked. What I was talking about though is the compiler (not the decompiler, vbsp.exe) placing a c0_0_0.vtf cubemap in the materials even though there clearly isn't any env_cubemap entity in the map (and certainly not at 0 0 0). In fact, when you run the command buildcubemaps in-game, it dosen't seem to go at 0 0 0 to build it, and it doesn't show in console the "building cubemap 1/1" thingy, meaning that the compiler did not physically add the entity to the map file.

    Honestly, I am convinced that env_cubemaps entity are from the default hl2 vpks, meaning that in css or in tf2 (and even cs:go from what I can tell) use the same entity. The compiling execution files may be different, but the difference I mentionned wasn't about the way the map compiles, but in the way their engine will display it in-game. If css has the c0_0_0.vtf, the LDR reflections will look matte, if tf2 has them, it will still look broken.

    If you meant the "$envmap" parameter of a texture that would be only present in css's vpks, because you assumed I port the map from css and the texture on the brush in question should be from css, the file I sent above uses tile/tilefloor021a. It is a reflective texture present in default hl2 packs, so all the source games, and the c0_0_0.vtf file is still being made. This can't be the source of the issue.

    I don't think the skybox matters. bhop_0 uses a custom skybox material not present in the .vpks, and the vmf file I sent uses the default one (sky_day01_01), yet the result is the same. But, on that specific func_detail brush I put, if you nodraw the last drawn face or change it to a non-reflective material, c0_0_0.vtf doesn't appear. Same if you move it to world brush. Like I said, this problem doesn't seem to exist when in HDR mode, so having a c0_0_0.vtf.hdr file isn't needed to make the reflections look matte (but I'll assume you meant c0_0_0.vtf on that one and that you were as tired as me when you typed that).

    But yeah, it would be cool if you could tell me what makes this cubemap file happen out of no where, especialy if in css the mapper has to rely on its presence for him not to have glitchy relfections in his map.
     
    Last edited: Nov 25, 2016
  4. henke37

    aa henke37

    Messages:
    1,909
    Positive Ratings:
    446
    I will say what everyone is thinking then:

    Just add proper cubemaps to the map. Not just one in a black box, actual ones that reflect the environment.
     
  5. Shadow Sheep

    Shadow Sheep L1: Registered

    Messages:
    5
    Positive Ratings:
    0
    You are not answering my question, henke37.

    The fact that a mapper desires propper reflections in their mapping project is entirely up to them, their preference and their intention. Adding cubemaps in map projects that were not meant to have reflecting surfaces means that you do not understand what the mapper intended to do or do not have any sort of respect regarding the integrity of the work he did. I can give you a lot of examples if you are not convinced of that.

    What conditions are required to consistently make the c0_0_0.vtf and c0_0_0.vtf.hdr cubemaps get added to the map upon compilation?
     
  6. UKCS-Alias

    aa UKCS-Alias Mann vs Machine... or... Mapper vs Meta?

    Messages:
    1,264
    Positive Ratings:
    748
    Depending on the situation the compiler sometimes decides to place a cubemap at 0,0,0 with the skybox texture (if it can find the files for them). This prevents purple checkers from showing. Its very normal behaviour when a map does not have a cubemap. The reason some mappers dont put in cubemaps is simply because they might not be aware of the problem. So henke is fully right stating 'if you want proper reflections: put in cubemaps'.
    The reason the decompiler can recognise the lack of cubemaps is because it only finds 1 at 0,0,0 which in 99% of the cases simply means: there were never any cubemaps in the map. So on that can just ignore that single cubemap.
     
  7. Shadow Sheep

    Shadow Sheep L1: Registered

    Messages:
    5
    Positive Ratings:
    0
    Yes, I noticed that it sometimes puts it (not with the skybox textures though, I only saw cases of that on very old maps I was porting, like bhop_awake or bhop_monster_jam). Thats the reason I am making this post. I want to know how to always make it appear, or what conditions are necessary to make it appear. In counter-strike: source, having this cubemap in a map removes the presence of the fallback editor/cubemap reflection on models and water. Having to rely on "luck" because you don't know how to make it create is a problem considering how damaging it can make the map look. I am not looking for solutions about reflections. I am not looking for ways to make the reflections look matte, because I already know how to do that (look at my first post). I just want to know what makes this cubemap generate.

    Having a c0_0_0.vtf does not prevent purple and black checkers in maps because there is always the defaultcubemaps.vtf that gets added to the map regardless of its cubemapping content. When the game loads a repacked map, it glitches to dispaly it in team fortress 2 and shows the fallback cubemap, and so never pink and black checkers (unless you delete it of course).

    I don't think its a normal behavior to have it added to the map considering it is very inconsistent and the fact that if you remove that single func_detail brush in the file I sent in the first post (which to my eyes has nothing special in its geometry), then the c0_0_0.vtf file does not get created. I am looking for someone to prove me that this behavior is consistent and requires some conditions in order to occur and which ones.

    The non-awarness of some mappers could be a reason why they do not put optional reflections to their maps, but like I said, there are a lot of example where not having cubemapped reflections on reflective surfaces looks better and more coherent relatively to the mapping project you are going for.

    Henke did not say "if you want propper relfections: put in cubemaps", he said "Just add proper cubemaps to the map. Not just one in a black box, actual ones that reflect the environment.", which to me is entirely different. Like I keep repeating, I am talking about cases where cubemap reflections are not wanted.

    I can't agree with you about the decompiler relying on the c0_0_0.vtf file to tell if the level has any cubemap, since the location of the env_cubemap entities are written in the index 42 of the lumps of the map called LUMPS_CUBEMAPS (source: https://developer.valvesoftware.com/wiki/Source_BSP_File_Format) and the fact that there are no cubemaps called 0 0 0 being written there or else it would allow you to build that one when typing the buildcubemaps command on levels which have the c0_0_0.vtf files added to them.

    I do not want to ignore that cubemap, especialy if it can be desired in some cases.
     
    Last edited: Nov 27, 2016
  8. henke37

    aa henke37

    Messages:
    1,909
    Positive Ratings:
    446
    If you don't like how shiny things are, fix the materials. But you can't just skip the cubemaps, the reflections will be wrong for things out of your control, such as the weapons.
     
  9. Shadow Sheep

    Shadow Sheep L1: Registered

    Messages:
    5
    Positive Ratings:
    0
    henke37, I apreciate the effort, but you are speaking about an entirely different topic I am afraid. I don't need to know how to make a better map, because I think I know most of the tricks that can be used thoughout my experience with hammer (I even posted a way to get around the glitchy reflections at the end of my first post). I want to know how the Valve Binary Space Partition executable (frequently abreviated to VBSP.exe) manages to create c0_0_0.vtf cubemap materials from this map:

    [​IMG]

    Can you please explain what creates that cubemap? Or at least tell me who I can contact at Valve to get any answer?