Quote from spongylover123 on January 29, 2012, 5:31 pm

I think buildmodelforworld is like buildcubemaps, the dlc broke it.

Quote from Robdon on January 29, 2012, 5:38 pm

Buildcubemap works though, you just have to have your map in the portal2_dlc1maps dir

Buildmodelforworld is the same, it only updates maps in portal2_dlc1maps since the dlc.

Maybe they broke it more... but I cant find ANY map, even that was built before the dlc that has this simpleworldmodel in them, apart from Valves.

Rob.

Quote from Vordwann on January 30, 2012, 9:49 pm

What i've always wondered is why Valve's refract textures (glass, water, etc.) arent' programmed better. Right now they draw refractions not only from objects behind them, but objects on top of them such as cubes, the viewmodel, etc.

EDIT: Woah i'm a community contributor... didn't notice that

Quote from spongylover123 on January 30, 2012, 10:53 pm

Robdon wrote:

Buildcubemap works though, you just have to have your map in the portal2_dlc1maps dirBuildmodelforworld is the same, it only updates maps in portal2_dlc1maps since the dlc.Maybe they broke it more... but I cant find ANY map, even that was built before the dlc that has this simpleworldmodel in them, apart from Valves.Rob.

Try some maps for other source games.

P.S The commands work, but they dont function, I cant see my cubemaps, even though I have built them. so are for the buildmodelforworld, if only someone still has pre-dlc p2

Quote from kwp21 pitts on January 31, 2012, 11:16 pm

Try to moving the env_cubemap entity lower.

Quote from Robdon on February 1, 2012, 7:00 pm

spongylover123 wrote:

Robdon wrote:

Buildcubemap works though, you just have to have your map in the portal2_dlc1maps dirBuildmodelforworld is the same, it only updates maps in portal2_dlc1maps since the dlc.Maybe they broke it more... but I cant find ANY map, even that was built before the dlc that has this simpleworldmodel in them, apart from Valves.Rob.

Try some maps for other source games.

P.S The commands work, but they dont function, I cant see my cubemaps, even though I have built them. so are for the buildmodelforworld, if only someone still has pre-dlc p2

Hmm, well they work for me, so I guess something isn't quite right.

Check this:

Firstly, make sure you have gotten rid of any bsp files of your map in the dirs. Portal will look for bsp files in this order and these dirs, so check them, baring in mind these paths are for Win 7 64, so you might need to change the 'program files (x86)' bit to 'program files':

C:program files (x86)steamsteamappscommonportal 2updatemapsyourmap.bsp
C:Program Files (x86)SteamSteamAppscommonportal 2portal2_dlc1mapsyourmap.bsp
C:Program Files (x86)SteamSteamAppscommonportal 2portal2mapsyourmap.bsp
C:program files (x86)steamsteamappscommonportal 2platformmapsyourmap.bsp

Then, to make it easier for building cubemaps and things its probably best if you change hammer to automatically copy the bsp file to the 'C:Program Files (x86)SteamSteamAppscommonportal 2portal2_dlc1maps' dir when you compile, since the buildcubemap command will only try to write back to the bsp in that dir. (and will crash portal if the file isnt there)

So close portal and hammer, and edit the file C:Program Files (x86)SteamSteamAppscommonportal 2binGameConfig.txt in notepad and change the following line:

"BSPDir" "C:Program Files (x86)SteamSteamAppscommonportal 2portal2maps"

to

"BSPDir" "C:Program Files (x86)SteamSteamAppscommonportal 2portal2_dlc1maps"

Now hammer will copy your bsp file to the dlc1 dir when you compile, so you dont need to move it around and stuff when building cubemaps.

In hammer place your cubemaps and stuff, and then compile, make sure you are in 'expert' mode and you select the 'Full compile -both -final (slow!) config

Now start portal and type the following in the console.

map yourmap
mat_hdr_level 2
buildcubemaps
mat_hdr_level 1
buildcubemaps
mat_hdr_level 2

Thats it, they should be there now.

If you recompile or rename the bsp file, you will need to do the build again, as this destroys the cubemaps.

I would recommend also closing and reopening portal each time you re-compile and change env_cubemaps or things. Sometimes portal seems to 'cache' the cubemaps and sometimes it doesnt. If it does then it can confuse you as to what your last change actually did or didnt do.

Note that cubemap reflections will only show if your settings for 'Shader Detail' are 'high' or 'very high', they wont show in Medium.

Also, not all entities will reflect in cubemaps, for instance env_portal_laser doesnt display correctly and only 2 red points will reflect at the origin and at the end point that the laser hits something. The actual laser 'line' wont reflect.

Another thing that can be helpful is to use the cubemap weapon. Have a look at bottom of this thread at Skotty's post and it will give you a link to getting the weapon and how to install/use it. Its a good tool for seeing which cubemap is active and what it can see.

http://forums.thinking.withportals.com/mapping-help/buildcubemaps-crashes-game-t4828-30.html

I've attached some demo vmfs, to show some reflections from cubemaps, and some prebuilt bsp files with cubemaps built and also not built to show the differences.

The best things to use for testing are glass vactubes and lightbridges

cubemap1: no env_cubemap in map

cubemap2: env_cubemap in map, but no cubemaps built

cubemap3: env_cubemap in map, and cubemaps built

Bare in mind, I've set my cubemap in hammer to have a size of '256x256' which can cause possible performance problems because its the highest quality. Its just so that it shows a good image of it in this test and its a simple map. I'm not sure 'how' bad this is for performance so you need to test which is the best for your map and performance, or just use 'standard'.

HTHs,

Rob.

Quote from Another Bad Pun on February 1, 2012, 7:27 pm

If you have multiple goo pits, make sure it isn't all one big brush. Having it all one big brush can cause reflection problems like yours.

Quote from DigitalMan on March 28, 2012, 6:55 am

This thread died a little while back, but I thought I'd revive it to share a few things I found out relating to the subject. I'm not sure if it's new to any of you, but I figured I'd share anyway. I decided to take several screenshots of one of the maps in Portal 2. The map I chose was sp_a2_bridge_intro.

I started with the original version from the game and took a shot showing most of the area and another of just the water. I also took these on both Low and High shader detail.

After doing that, I renamed the map file and retook the screenshots from the same areas as I took the others. Aside from the cubemaps being broken, the map looked the same on High shader detail. When I put it on Low, I noticed the water wasn't the same as it was before in the original. So if the water gets broken because of the rename, could that mean that there's a file somewhere (perhaps in one of the several vpks) that controls this?

I could have stopped there, but I didn't. I decided to decompile the map and do a full recompile to see what happened. So I recompiled the map under a different name and found that the map was a lot darker than the one in Portal 2. I also noticed that the water has weird marks all over it on High Shader detail, but they aren't present on Low. Now not every decompile is perfect, but could this also mean that Valve had some sort of special compile tool to make the maps appear the way they do?

Then to finish the little project I was doing, I decided to rename the file to the official name and found the same results as the one above. It should be noted that these were taking without building the cubemaps. I was going to take more with the cubemaps built, but I didn't have the time to do so.

I still have all the screenshots and I can try to post them here later today if you want to see them. Thanks for reading.

Quote from Robdon on March 28, 2012, 8:29 am

Hi,

What decompiler are you using and what version?

A while ago, I found a bug in BSPSource, that it was converting all boolean parameters to 'true'/'false' text instead of 0/1, and reported it to them.

This caused errors with those parameters, because the compiler takes 'false' and 'true' and turns them both in to '0', ie disabled.

This specifically effects lighting (but not only), because the models used for glass panels (glass_lightcover) have to have the 'Disable Shadows' set on the model, so that the light panel behind them shines through.

So because of this bug, all the glass_lightcover wont allow light to pass and therefore decompiled maps are always darker if light panels are used.

This was recently fixed in BSPSource release 1.3.4, so check your version and update if needed and re-decompile your maps.

http://ata4.info/bspsrc/downloads.html

Hopefully this should help the lighting and maybe other problems.

Rob.