I've been searching around, and I can't seem to find anything that really tells me much about cubemaps.

I tried placing them, but all the observation-room windows show funky now, blinking with lines through them occasionally.

A little help please?

ALSO: Some areas look OVER-reflected, turning grainy and spotty, looking like somebody puked on them.

madcat1030 wrote:
ALSO: Some areas look OVER-reflected, turning grainy and spotty, looking like somebody puked on them.

I haven't really worked with cubemaps that much, so I don't have much say on it, but maybe you have the reflectivity set too high? Or maybe the texture already has reflectivity in it, and doesn't need the cubemap?

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

I keep finding my way to that wiki, but I keep ending up with the friggy-window problem. I'm just going to remove them for now. I'll figure them out later.

Are you sure your observation windows (that is, the brushes with the glass texture on them) are all func_brushes? Anything else will result in graphical glitches.

Hey, I had the glitchy window problems too. It occurs when you place the windows in a 90? angle next to each other. The solution is - find an original material file for the window (glassrefract_something.vmt) and edit it - remove the line saying "env_cubemap", save and use that material instead of the original one in places where the glitch occurs. Don't forget to bspzip the material file into your map before releasing. Your windows will look fine after building cubemaps, as mine do

sili question :why this is called "cube map" its sonds like a companion cubemap

'cause the engine calculates 6 images around the place you wanted to create the Cubemap. Those 6 images form a cube, hence the name 'Cubemap'. It can then be used to simulate reflections, by parenting them to the player and paying attention to which surfaces should reflect what cubemap and how much.

This may seem like a stupid question but...

Do I have to tie the window brushes TO a func_brush? For some reason, I thought that brushes were that automatically, but now that I think back, I see... Why would there have been a "func_brush" entity if that were the case. I'm gonna go see if that helps things with the windows. But the other problems are still stupid.

I try to follow the rules set in the VDC wiki, but it still looks crazy bad.

Do as I said, it's working.
If you tie the window brush tu a func_brush, it becomes a member of entity (not a world brush anymore) which means it doesn't split visleafs which means better optimisation which means faster compilation