Talk:Light environment

From Valve Developer Community
Jump to: navigation, search

I'm amused that the ambient lighting thing is identical in concept to something I added to HLRAD some years ago. I'm sure it's more a case of great minds thinking alike... :-] --Cargo Cult 06:20, 6 Aug 2005 (PDT)

It's worth noting that light_environment only works outside, so if you're using a hollowed out box your map will be black (you can get around this by applying the tools/skybox texture to the ceiling) --Black Majic 14:14, 13 Nov 2005 (PST)

Multiple Light_Envs

Is it possible to use multiple light_environments in a map? It could be kinda neat if I could diffrently light areas in my name, so that in the begging of my map it's the down is going down, and in the later parts it's nearly night, without splitting up the map. --Sortie 10:18, 29 Mar 2007 (PDT)

See Intermediate_Lighting --Angry Beaver 12:38, 29 Mar 2007 (PDT)
Well, I know it's currently impossible with vrad, but I kinda wondered if, there were any 3rd party compile tools that supported that tech. Unsigned comment added by Sortie (talkcontribs). Please use four tildes (~~~~) or {{Message}} template to sign your username.
One thing to consider is that the 2D sky is the same for the entire map, so it would look quite odd if you did get the different lights going. --Daedalus 06:11, 5 Apr 2007 (PDT)
Yeah, I'm aware of that. Still in this map it might kinda work.--Sortie 23:53, 5 Apr 2007 (PDT)

I have a similar concept which would require two different light_envs: I have a map which takes place in a space station inside a giant nebula, with two fairly large sources of light in approximately opposite directions in the skybox, so I'm having trouble determining exactly how I should handle that. Or possibly have one of them mostly obscured by, say, a much larger structure in the 3D skybox. —Yar Kramer 11:47, 3 Dec 2008 (PST)

One idea that came to mind was of setting up a texture which would glow the specified color, make it invisible, and put it in front of the skybox, but the trick would be getting it to stay "constant" the way skybox lights do ...—Yar Kramer 14:53, 4 Dec 2008 (PST)

SunSpreadAngle

I just added a little note on realism - increasing SunSpreadAngle will make it look like a cloudy day because shadows are blurred. Meh, me myself I'm just sick of seeing sharp shadows when it's like raining or something. --Solar 13:36, 11 Sep 2008 (PDT)

Could you add another example of value for night time ? --NykO18 02:15, 12 Sep 2008 (PDT)
Ok, added. I also thought originally that SunSpreadAngle was a ratio, but it turned out to be degrees: the value has been upped so it actually works visibly now. --Solar 06:09, 16 Sep 2008 (PDT)
Thank you so much. --NykO18 07:34, 16 Sep 2008 (PDT)

3D Skybox requirement?

Is it a requirement that your light_environment be in the 3D skybox hull, if you have one? In one of my maps, I put it in the main hull and there was no static light, but vertex light worked fine, so I had bright models in a pitch black world. Then I moved the entity into the 3D skybox and it worked fine. It may be a freak incident, but if its a requirement, I never knew about it and it should be stated. --TracerDX 03:14, 26 April 2009 (UTC)

Something similar is going wrong with my map. If I place the light_environment in my 3D skybox, the skybox elements and props in the players world are lightened, but brushes aren't. If I remove the 3D skybox and move the light_environment to the players world, everything is lightened the way it should. The same thing happens even if I have two light_environments with the same values. It ignores the light_environment in the players world and uses the 3D skybox's entity. --Mattshu 20:27, 28 February 2011 (UTC)
light_environment should always be in the 2d skybox space. Oddly though it shouldn't matter where the physical entity exists. Kind of odd that you guys are having issues like that.--MrFourVideoCards 03:04, 1 March 2011 (UTC)

:::FIX - My sky_camera was set at a scale of 32. After changing it to the default 16, my light_environment was working! —Mattshu (Talk) 03:37, 2 March 2011 (UTC)

False alarm, its happening again, regardless of the sky_camera scale. Grrr. —Mattshu (Talk) 06:20, 2 March 2011 (UTC)
I've never had my light_environment betray me. I'm using the Episode 1 engine and never put the entity within any 3D skybox model, if that helps. I don't know if Valve never put their light_environments in their 3D skyboxes either, but I've seen plenty of light_environments inside the actual map, so this entity is not supposed to be placed within a 3D skybox model. I guess that if you do, the lightsource for the brushes might be scaled with the skybox geometry, to the point where it stops counting (when it's over 16?). This is a guess - try that out. --MossyBucket (formerly Andreasen) 06:33, 2 March 2011 (UTC)
OK! I'm not sure about TracerDX's problem, but I figured out mine. I facepalmed after realizing what the error was, too. The problem was, in my 3D skybox, I have the Citadel (models/props_combine/Combine_Citadel001b_open.mdl). I copied the actual 3D skybox from a Valve map, then added other models used for the skybox (those refineries that are made just for a skybox). I wanted my map to take place a bit farther than Gordon's storyline, so I moved the Citadel model farther away. Well, the Citadel model seems to take up 1/4th of the void, not only because of it's awing height, but it's widely spanned "cables" that are attached around the city. My sky_camera was INSIDE the border of the model. This explains the erroneous lighting. The model was enveloping the sky_camera, distorting the light. I won't add a bug note for this in light_environment, because it was my stupidity. :P For future facepalms, please reference me. —Mattshu (Talk) 06:57, 2 March 2011 (UTC)