Snarkpit Forum Index » Source engine editing » Requesting tutorial for cubemap
Requesting tutorial for cubemap
1
Post Reply
Quote
 Re: Requesting tutorial for cubemap
Posted by satchmo on Fri Dec 17th at 4:24am 2004

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.

[addsig]



Quote
 Re: Requesting tutorial for cubemap
Posted by Sam37 on Fri Dec 17th at 5:09pm 2004

I have the exact same problem...





Quote
 Re: Requesting tutorial for cubemap
Posted by MeatStick on Fri Dec 17th at 6:12pm 2004

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.



Quote
 Re: Requesting tutorial for cubemap
Posted by Leperous on Fri Dec 17th at 7:30pm 2004

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.





Quote
 Re: Requesting tutorial for cubemap
Posted by ReNo on Fri Dec 17th at 7:42pm 2004

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.
[addsig]



Quote
 Re: Requesting tutorial for cubemap
Posted by satchmo on Sat Dec 18th at 4:22am 2004

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.

[addsig]



Quote
 Re: Requesting tutorial for cubemap
Posted by Static88 on Mon Jan 3rd at 4:56pm 2005

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.



Quote
 Re: Requesting tutorial for cubemap
Posted by Rof on Mon Jan 3rd at 5:09pm 2005

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).




Quote
 Re: Requesting tutorial for cubemap
Posted by ReNo on Mon Jan 3rd at 5:48pm 2005

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.
[addsig]



Quote
 Re: Requesting tutorial for cubemap
Posted by Static88 on Mon Jan 3rd at 7:49pm 2005

You guys are awesome. Thanks for the good info.



Quote
 Re: Requesting tutorial for cubemap
Posted by IrishGuinea on Mon Jan 3rd at 8:54pm 2005

? quoting MeatStick
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.

Same here...I believe its from using model textures on world brushes, they seem to be the only ones that do that.





Quote
 Re: Requesting tutorial for cubemap
Posted by RabidMonkey777 on Mon Jan 3rd at 9:05pm 2005

...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.




1
Post Reply