My problem is that I've opted for not letting the skybox be reflected on the water's surface because if I try, this is what I get:

As far as I know these could be the commands related to my enquiry:

$reflectentities 1  //this one reflects entities (lol)
$reflect2dskybox 1  //this is the one that make the skybox appears on the water's surface
$reflectskyboxonly 0  //with this I was trying the skybox not to spread all around...

If I give a value of "0" to the command $reflect2dskybox, all the reflection I get is a black space where the skybox is supposed to be like so:

If I must decide I take this last one with no doubt... but I would like the skybox to be reflected only in the brushes textured with the toolsskybox texture, the same as it happens above the water,... so anyone knows if this is even possible to be achieved?

It might also be the case that "$reflectentities" is what's turning the world geometry off, instead of "$reflect2dskybox", so try it with the skybox on and entities off.

It took me some experimenting to get the right values for all of these settings. I found that the best way to go about this, is to have the vmt file open (in Notepad or whatever) and have Portal 2 open simultaneously in a window. After making changes to the parameters, you can reload the material with the console command "reloadmaterial <VMT file name>".

I think this is what you want and I'm sure if you had more time you'd found out it yourself.
The question is how did you implement you skybox with "ignorez" 1 in .vmt files. Did I miss something?

EDIT Oh, I've got it. You have 3D with sky_camera. And this must be the reason of your trouble with reflection.

EDIT I've tryed it as you did in your map and without $ignorez 1 line in skybox .vmt files it works fine too. But when I put in this parameter back I got that bug again and moreover the water reflection became as you have in your first screenshot. So I asume this is the reason.

@Greykarel: I sincerely thank you all the effort and help about this (and with beta-testing my map ofc). You have found an answer for all the questions related to this issue and more!

So I'd like to say what Grey has found in the case someone wants to solve a similar issue:

1. The line $ignorez means "ignore z axis" and it looks like if set to a value of "1", the skybox is rendered in a first plane, and if set to "0" it is not. Regarding the reflections on the water surface, a value of "1" is what ends up spreading the skybox all over the water's surface... So these are the best settings you can have into your .vmt files:

"UnLitGeneric"
{
   "$basetexture" "skybox/[skybox side name here]"
   "$nofog" 1
}

And the following lines must be included in the water texture .vmt file:

$reflectentities 1
$reflect2dskybox 1

But now the problem is that if you have placed an env_sun entity into your 3D skybox box, it won't ever appear. For a sun to appear, at least the side texture of the skybox where the sun appears in, must have the "$ignorez 1" in its .vmt file, otherwise the sun won't show up (in my case it was the front side called "otherft.vmt"). Another interesting find by Grey was that it isn't mandatory that all .vmt files have the same content, which leads us to only include "$ignorez 1" into that side of the box where we know the sun will appear (I really wanted the sun at least in 2 rooms in my map, otherwise the shadows and lighting won't be justified enough).

1. Of course, when you look to the water's surface and see the reflected skybox, it only gets spreaded that side in which we kept the "$ignorez 1". I was happy with that because it only appeared in my map in 2 ocasions, and maybe the player won't notice... but then Grey thought "what if we could change the skybox in-game?"... and that one was his next awesome find that I thank another ton . The map's properties can be changed in game, and so the sky name with the AddOutput output . It's necessary to give your map a name into the map's properties dialog window in order to refer to it later and that's all. I built another group of 6 .vmt files for each 6 sides of the skybox (pointing to the same .vtf in $basetexture command) but with a different name so it's a different skybox and ofc with none of the skybox's sides including the "$ignorez 1"; then we were able to trigger each skybox by this output:

2. OnTrigger > [map's name here] > AddOutput > skyname whatever

(and replacing whatever by the name of the other skybox, but into the "With a parameter override of..." box)

And it works like a charm!

All that was tested and "discovered" by GreyKarel and, even though he says he's doing for his own sake due to the fact that he learns while he helps, I have to say THANK YOU SO MUCH GREY!!!

josepezdj wrote:
- OnTrigger > [map's name here] > AddOutput > skyname whatever

That's an awesome hack! I am so abusing the hell out of that one for the later sci-fi themed Sendificate levels.

Also: I didn't know skybox textures were messing with ignorez... Thought it was only used for UI overlays. Anyways, glad you got that solved. That skybox is really the visual icing on the (rumoured to be non-existent) cake!

Something I never knew is now known.

First thing I said to Greykarel when he asked me "is it possible to change the skybox in-game?", was "I don't think so, it's the map's properties...". And when he found this feature, and told me, I discovered that the map's properties is indeed an entity, called worldspawn. Isn't it an awesome name? Thanks to Greykarel again

I think this feature of changing the skybox in game is absolutely powerful. Even though I wouldn't like to vary much the atmosphere along the same level, I want to introduce some variations, for example between my elevators shafts (where I'm starting to open the walls to the skyboxes ) and the different chambers of each level.

Another important thing that comes to my mind now is this: in a 3D skybox there are the main entities, right?

• env_sun (with or without an info_target to make it head to a certain point of our choice)
• light_environment
• shadow_control

Well, in order to properly define a skybox when we change it in game, could we fire an output to change the ambience/brightness into the light_environment entity? due to the fact that we'll have to name this entity, will we mess up everything and get our beloved "too many lights on a face at... ALL DAMN PLACES" yellow message?

As I said above, maybe we'd better be prudent and only change amongst skyboxes with the same tone and keep the atmosphere throughout the level.

HMW wrote:
Just a random idea: you could tweak the colour correction and/or HDR settings to make it look like the light in the map changes, while it actually doesn't...

Oh, you mean with the color_correction entity? good point

Some time ago, when I was about to release the Second Exodus v2.0, I found all these problems related to the reflections on the water's surface. Apart from all discovered above that allowed me to have the skybox and water into the map very well set up, there still was an annoying issue that I only found right after I released the map... Some of you will know that depending on the Shader Detail *video settings, only certain reflections are allowed. The skybox and the entities (marked to "Render in fast reflections"*) can only be seen if the shader detail setting is HIGH or VERY HIGH.

The problem is that when the Shader Detail is set to Medium, it is not only that you can't see the skybox and entities reflected, but, unless you have a very well made custom water material prepared for all the cases, all that you will see is some annoying flashy water reflections like in this solution video that Sickle recorded of my map playthrough.

Well, in that time HMW helped me out to be able to run the command "buildmodelforworld" that stores a 'cheaper' version of your map inside the bsp file (here is the thread). But there's a terible drawback, overall when you want to upload your map to the workshop: this command doubles your bsp's size!...

OK, after some research over the internet, I found this helpful thread in here:
http://forums.thinking.withportals.com/portal-two/console-commands-and-variables-for-all-in-game-options-t4031.html. Where it says the number that corresponds to each Shader Detail option when talking of the console commands to change them: setting.gpu_level: 0 = low, 1 = medium, 2 = high, 3 = very high

So I reminded having seen something like "GPU<=1" into some water materials. After I searched, I found some of them that included this kind of 'conditional' parameters... So I took all that information and included into my custom water material the following lines:

"GPU<2?$forceenvmap" 1
"GPU<2?$envmap" env_cubemap
"GPU>=2?$reflecttexture" _rt_WaterReflection

PROFIT! When the shader detail is below 2 (High) then the engine doesn't even try to build reflections, but it produces a semi-real-reflection making use of the env_cubemap to "mimic" something similar to the water's reflections (completely ugly though :p); but the flashy stupid reflections are gone! And the water material is prepared for all shader detail settings possibilities, ofc including the high /very-high ones where the skybox and entities are reflected properly.

I hope this will be helpful for you guys!