env_cubemaps

Ok so here's the deal. I finally started to try to map for Source (sign of the apocalypse anyone?) and I have had a heck of a time at it so far .

My main problem is I can't figure out how to operate a/the cubemap(s). To my understanding they are meant to control the reflectivity and lighting of objects, what I don't seem to understand is where/when to place them. (I really think I'm not getting the concept of cubemaps in the first place). I have searched the VDC up and down and so far any info about cubemaps has confused my GoldSrc-saturated brain to its limits.

So what I need is someone to explain env_cubemaps in a way that a GoldSrcer can understand. And what I mean is I need to know proper placement/usage of a env_cubemap (<--how many times have I typed that in the last few hours?) and possibly any tricks that go along with it.

I posses a small amount of video game coding knowledge(A boatload of DooM 2 scripting but some C++ also) so feel free to use "Big Words" and computer-oriented terminalogy.

Thanks ahead of time.

---

Now remember kids. Asking questions is a good way to get censored by the government.

http://developer.valvesoftware.com/wiki/Cubemaps

Cubemaps are very easy. You can begin with using only 1 cubemap.

Just place it in a certain room or space.

Compile and start the map, then type "buildcubemaps" in the console. After that, restart the game and load your map again. The cubemaps should now work.

All credits goes to Riven XD He taught me this.

You can later on experiment a bit and add more cubemaps.

Good luck!

---

Youtube Channel: https://www.youtube.com/c/Nibgames

Sheesh , talk about making a mountain out of a mole hill. I thought it was much more complex than that, although I would like to know a bit more on how they work in the first place so as to better utilize them, but that can be a task for another day.

Anyway, thanks a bunch Nib.

---

Now remember kids. Asking questions is a good way to get censored by the government.

Yea, they're really fairly simple. The env_cubemap takes six pictures from its point in space. The pictures are taken at perpendicular angles to one another, much like the faces of a cube, hence the name. Any reflective materials nearby will look to the opposite face of the nearest env_cubemap to render a simulated "reflection" of whatever the cubemap took a picture of. The farther away the cubemap is from the objects you want reflected, the more stuff you can fit into the "pictures" of the env_cubemap. I think 16 units from a surface is minimum, but in my experience, 64 works and looks better as a minimum. -It's whatever you desire, really.

You may increase their resolution, and hence make a sharper reflection for the surfaces that use that cubemap, but this does increase map file size very quickly, and makes it heftier to render, because essentially every cubemap includes 6 new separate textures to your map that all have to be rendered like every other texture. If you select one too many env_cubemaps to have a larger image collection of over 128x128 px you may run into slow-downs for older systems. I think the resolutions go up to 1024x1024; <that res would be more apt for a mirror and should be used sparingly.

All you have to do is place them, and run the command once in-game after you've loaded your map and your good to go.

One word of warning too, if you ever rename your map after you've built your cubemaps, you'll need to re-run the command, because the cubemaps are essentially "packed" into the map and use a file-like structure to be accessed. If you change the name, you break the structure. Of course, doing this means you have another set of images embedded into your map, and thus the file size of your map is larger than it needs to be because of it. If you want to change a map name, do it before you build 'em. Otherwise, I would re-compile, or open up the pack and remove the old ones.

Just my 2 cents.

---

Blog: www.playingarchitecture.net
LinkedIn: Eric Lancon
Twitter:@Riven202

^ Basically that's the advanced version of my post

I didn't know everything you mentioned there

---

Youtube Channel: https://www.youtube.com/c/Nibgames

Riven said:
Yea, they're really fairly simple. The env_cubemap takes six pictures from its point in space. The pictures are taken at perpendicular angles to one another, much like the faces of a cube, hence the name. Any reflective materials nearby will look to the opposite face of the nearest env_cubemap to render a simulated "reflection" of whatever the cubemap took a picture of. The farther away the cubemap is from the objects you want reflected, the more stuff you can fit into the "pictures" of the env_cubemap. I think 16 units from a surface is minimum, but in my experience, 64 works and looks better as a minimum. -It's whatever you desire, really.

You may increase their resolution, and hence make a sharper reflection for the surfaces that use that cubemap, but this does increase map file size very quickly, and makes it heftier to render, because essentially every cubemap includes 6 new separate textures to your map that all have to be rendered like every other texture. If you select one too many env_cubemaps to have a larger image collection of over 128x128 px you may run into slow-downs for older systems. I think the resolutions go up to 1024x1024; <that res would be more apt for a mirror and should be used sparingly.

All you have to do is place them, and run the command once in-game after you've loaded your map and your good to go.

One word of warning too, if you ever rename your map after you've built your cubemaps, you'll need to re-run the command, because the cubemaps are essentially "packed" into the map and use a file-like structure to be accessed. If you change the name, you break the structure. Of course, doing this means you have another set of images embedded into your map, and thus the file size of your map is larger than it needs to be because of it. If you want to change a map name, do it before you build 'em. Otherwise, I would re-compile, or open up the pack and remove the old ones.

Just my 2 cents.

Wow... That is exactly what I wanted to know. Thanks loads both of you, this has restored my desire to map for Source.

---

Now remember kids. Asking questions is a good way to get censored by the government.

Feel free to ask anything else if you have another question

---

Youtube Channel: https://www.youtube.com/c/Nibgames

Ok one last thing, what does the face selection thing do for a env_cubemap? Does it control which faces are used in the cube map, or the faces that this specific cube map apply to? Or do I have it confused again?

---

Now remember kids. Asking questions is a good way to get censored by the government.

I THINK it controls which faces are used in the cubemap, but I am not sure.

---

Youtube Channel: https://www.youtube.com/c/Nibgames

As I understand it, and as I've intended to used it before in this way, it's a way to control which reflective surfaces use that cubemap. The env_cubemap still functions in the normal way (taking pictures from its point in space), but you as the mapper may limit which surfaces adopt or "use" that cubemap's picture set for their reflections. For instance, if you list a number of brush faces in the env_cubemap's Brush Faces keyvalue, you limit that cubemap to being applied only to those faces. So, in theory, you could have brush faces from one part of a map use an env_cubemap from a remote other section of the map.

Doing this though, I believe disallows any models (including your reflective viewmodel weapons) to use that env_cubemap when they come close enough to it, it will ignore all other brush and model surfaces that would otherwise use it, if or when they would become close enough.

You can use the cheat in any of the HL2 games in console: "impulse 81" (without quotes) to activate a weapon in your smg slot that is six floating reflective balls. They each have a special shader applied to them so you can see how the reflections look on them. I don't know if this is enabled the same way for other Source games.

Also, in case you haven't figured out already, I must correct myself, the max cubemap size is 256x256. Which is still pretty sharp, for a distant reflection.

I hope that explains it a little.

---

Blog: www.playingarchitecture.net
LinkedIn: Eric Lancon
Twitter:@Riven202

Wow, this gives me all sorts of inspiration for abstract maps. Thanks again fellas.

---

Now remember kids. Asking questions is a good way to get censored by the government.

Ok so I have a new problem, but since this thread's topic has been answered should I make a new one, or post again in this one seeing as the problem still concerns env_cubemaps?

---

Now remember kids. Asking questions is a good way to get censored by the government.

If it's still about env_cubemaps, I say go ahead.

---

Blog: www.playingarchitecture.net
LinkedIn: Eric Lancon
Twitter:@Riven202

Ok so here's the deal.

I have a cubemap in my map positioned at player veiw height. The only reflective surfaces in my room are a big combine machine. The first time I compiled my map with a cubemap I built the cubemap and everything looked great, but the next compile when I included a few prop_statics and repositioned the env_cubemap, my combine metal encased machine had a purple checkered reflection. I had read before that this meant I needed to rebuild my cubemaps, so I put in the command, it took the cubemap pictures, and when it was done... My machine was still reflecting a purple checkerboard.

That was 6 tries ago.

I have checked for all sorts of errors and have troubleshooted the thing to death, and I still can't get it to work. My compile console doesn't give me any errors, "check map for errors" is the same and my in game console gives me the usual Source-related start up errors, so theres nothing new there. Really and truely this has completely stumped me.

Thanks in advance.

EDIT: Nevermind, it must be a huge bug with developer's mode, because I booted up HL2DM to cry at my purple checkered reflecting machine, and it was reflecting correctly... So the only thing I can see that was different is the lack of developer's mode and not launching out of VHE. If I ever find out the specific problem I'll try to post it but for now I'm content with launching HL2DM off my desktop. (the only disadvantage is no dev mode now)

EDIT2: Ok, so I think the problem is when you play your map twice in a row. For some reason it drops that maps cubemap and forgets to reload it. It may be more complex than that, but if it is I don't know how I'd find out.

Solution: Load a different map then load yours, it should load the cubemaps then.

---

Now remember kids. Asking questions is a good way to get censored by the government.

It has nothing to do with dev mode. It's a bug AFAIK, and the only fix is simply restarting the game, and it doesn't matter which mode you have enabled. It's ok to keep your game running between compiles and loading multiple versions of the same map which each new updated compile, but once you begin adding env_cubemaps to your levels, the map makes a packed directory for them. If you compile a new version of the map, and go in-game to load it up and restart it, the game cache is still looking in an old pack that doesn't exist any more, even when a map of the same name is loaded. The cubemaps are supposed to be renewed, but the game cache is still looking for a non-existent packed folder of cubemap images. Sometimes it works, and other times it doesn't. It's a crap-shoot. But best reassurance is, before you plan to buildcubemaps for any map, make an effort to close the last session of the game and load it up again, just to clear the cache if that map had been run already in that gaming session.

You don't have to build cubemaps all the time in-fact, I leave them for last as part of my "detail pass" for maps. It's an aesthetic thing for the most part.

But that's all there is to it, no biggie. Don't be surprised when you try to buildcubemaps of an already checkered map, you'll get more checkers!

---

Blog: www.playingarchitecture.net
LinkedIn: Eric Lancon
Twitter:@Riven202

Thanks for clearing up that confusion, I was getting really agravated with my self and the Source engine in general.

---

Now remember kids. Asking questions is a good way to get censored by the government.

This is valve's way of doing "cheap" reflections on materials (or weapons), rather than real-time reflections.

Just another side note:

I forget the reason (I havent mapped in years!) but don't rename the bsp file before you build the cubemaps. If you want to rename a level (as in the file name) then you will have to recompile the level. It has to do with when you run the buildcubemaps command it creates different materials based off the name. Aka: testmap_alpha wil create testmap_alpha_texture1, testmap_alpha_texture2 etc. And if you rename your levelt to testmap_alpha2 then the engine will look for testmap_alpha2_texture1, etc.