[SOLVED] Skybox reflections on the water's surface

Quote from josepezdj on August 16, 2012, 10:11 amHey guys!
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:
- Code: Select all
$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?
Hey guys!
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:
- Code: Select all
$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?
Quote from HMW on August 17, 2012, 6:57 amHave you checked that "$reflectskyboxonly" isn't turned back on further down in the vmt file? (IIRC, if a setting is present more than once, the last occurrence will determine the actual value.)
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>".
Have you checked that "$reflectskyboxonly" isn't turned back on further down in the vmt file? (IIRC, if a setting is present more than once, the last occurrence will determine the actual value.)
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>".
Other Portal 2 maps: Medusa Glare
Portal 1 maps: Try Anything Twice | Manic Mechanic
Quote from greykarel on August 18, 2012, 5:11 pmI've extracted skybox and water files from your .bsp and made a map to test them. First of all I got wierd bug: all my world brushes became invisible when skybox got in field of view so I can only see the skybox and lights hanging in the air. Google said to remove line "$ignorez" 1 from skybox .vmt files. That works. Then I edited your water .vmt file. I just set $reflect2dskybox to 1 instead of 0 and got in game something like this
[spoiler]
[/spoiler]
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.
I've extracted skybox and water files from your .bsp and made a map to test them. First of all I got wierd bug: all my world brushes became invisible when skybox got in field of view so I can only see the skybox and lights hanging in the air. Google said to remove line "$ignorez" 1 from skybox .vmt files. That works. Then I edited your water .vmt file. I just set $reflect2dskybox to 1 instead of 0 and got in game something like this

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.

Quote from josepezdj on September 2, 2012, 11:53 am@HMW: Thanks for your suggestions, but after revising all that, it is not related to that.
@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:
- Code: Select all
"UnLitGeneric"
{
"$basetexture" "skybox/[skybox side name here]"
"$nofog" 1
}And the following lines must be included in the water texture .vmt file:
- Code: Select all
$reflectentities 1
$reflect2dskybox 1But 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).
2. 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:
- 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!!!
@HMW: Thanks for your suggestions, but after revising all that, it is not related to that.
@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:
- Code: Select all
"UnLitGeneric"
{
"$basetexture" "skybox/[skybox side name here]"
"$nofog" 1
}
And the following lines must be included in the water texture .vmt file:
- Code: Select all
$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).
2. 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:
- 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!!!
Quote from HMW on September 3, 2012, 3:57 pmjosepezdj wrote:- OnTrigger > [map's name here] > AddOutput > skyname whateverThat'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 [spoiler](rumoured to be non-existent)[/spoiler] cake!
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
Other Portal 2 maps: Medusa Glare
Portal 1 maps: Try Anything Twice | Manic Mechanic
Quote from FelixGriffin on September 3, 2012, 4:10 pmIsn't there a convar for the skybox name? But that does require a reload, so this is better.
Isn't there a convar for the skybox name? But that does require a reload, so this is better.

Quote from ChickenMobile on September 4, 2012, 5:00 amYou can change skyboxes mid-game? That is awesome. You could totally have a number of different skies if you spend too much time on a map and make it turn night or something...
Something I never knew is now known.
You can change skyboxes mid-game? That is awesome. You could totally have a number of different skies if you spend too much time on a map and make it turn night or something...
Something I never knew is now known.

Quote from josepezdj on September 5, 2012, 6:14 amAwesome! I'm so glad to check many of you found this information as useful as I did
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_controlWell, 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.
Awesome! I'm so glad to check many of you found this information as useful as I did
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.
Quote from FelixGriffin on September 5, 2012, 8:37 amlight_environment is different from light in that it's global, so I don't think the "light styles" thing applies to it.
light_environment is different from light in that it's global, so I don't think the "light styles" thing applies to it.