Talk:Env projectedtexture

PCF fix?

I'd heard that changing the attenuation would "fix" some of the issues with the flickery grainy filters around the shadows, and I tried to mess around with the attenuation values but it looked like it was either turning them totally black or fading them out, which didn't really help with the problem. After a bit of experimenting (I made ConVars for a lot of the variables in struct FlashlightState_t ), I found that by changing the "m_flShadowFilterSize" from 3.0f to 1.0f it made the ugly graininess less obvious on the edges of shadows, and it's so far the best solution I've found for fixing it. --Wilsonc 03:09, 30 October 2009 (UTC)

Obviously the way to remove them completely would be to set the filter size to 0, but as you've probably seen it looks awful. The way to solve this would be to employ a different filtering method (maybe VSM - this would also help with some of the biasing problems) in the flashlight shader header (src\materialsystem\stdshaders\common_flashlight_fxc.h), but even though I've been able to successfully compile a modified shader DLL, the game just won't accept it somehow and continues using the default shader. In my opinion, however, there are far greater problems than the shadow map anti aliasing, for example the fact that the light attenuates based on the position of the camera rather than the position of the projector itself. --Hamish 11:40, 31 October 2009 (UTC)

You can sort of hide the attenuation problems by setting the FarZ to something really high (like 2048 instead of the default 700 or whatever). I've also noticed that depth-bias could be changed just by changing a few variables, and the shadows no longer look all blobby and are more defined, however any changing the depth-bias to anything below 4 resulted in ugly artifacts. I also noticed that you could enable projected textures on viewmodels just by changing ShouldReceiveProjectedTextures() in baseviewmodel_shared.h to return true. It's funny how all those graphic intensive mods are always hyping their awesome shadows and boast about how they can achieve awesome graphics even though they're just changing a few lines of code :P --Wilsonc 21:15, 23 December 2009 (UTC)

It's always going to be easy for a coder to say that, and not so much for the end user. Mods don't always hype, but the system itself can see a lot of improvements. Some of which I've been happy to contribute to this page.--Gear 13:25, 24 December 2009 (UTC)

Mysterious Inputs

*; target <entity> : Specify a new <target_desination> entity.
*; cameraspace <bool> : See above keyvalues.
*; LightOnlyTarget <bool> : See above keyvalues. : {bug|Non-functional.}}
*; LightWorld <bool> : See above keyvalues. : {bug|Cannot be re-enabled.}}
*; EnableShadows <bool> : See above keyvalues.
*; Ambient <float>
*; SpotlightTexture <VTF/string> :A VTF file (not VMT), relative to /models.

These inputs are not specified in base.fgd ... have they been removed? I've commented them out of the article for now. --Beeswax 16:09, 13 Apr 2008 (PDT)

They've never been in the FGD, but they are all in the source code. --TomEdwards 01:22, 14 Apr 2008 (PDT)

Thought it might be something like that ... thanks. I did try (in EP2) to test by firing the SpotlightTexture from a custom logic_auto output but I couldn't get it to work ... Any tips would be appreciated as this seems like the most exciting feature. --Beeswax 07:11, 14 Apr 2008 (PDT)

Make sure you're point it to a VTF, not a VMT. --TomEdwards 09:05, 14 Apr 2008 (PDT)

Yeah I read that in the article. Have you ever got it working ? --Beeswax 17:56, 14 Apr 2008 (PDT)

I've never not had it work... --TomEdwards 04:31, 15 Apr 2008 (PDT)

Player Parenting

How do you parent this entity to the Player? I tried various Targetname tokens (!player, etc) as parentname but it didn't like any of them ... --Beeswax 07:11, 14 Apr 2008 (PDT)

You need to enable the camera space value, I think. Never actually tried it myself. --TomEdwards 09:05, 14 Apr 2008 (PDT)

Use SetParent on the players ViewModel. Pseudo-code: ply.FlashLight:SetParent(ply:GetViewModel())

Light attenuation?

Seems there is also ways to change the Light's constant values and such, while hidden in the .cpp file. Yet you'll need a coder to help bring em out, and appear in hammer, and be accepted in game, however it seems that this entity also has these values built in as well.--Gear 01:00, 9 Aug 2008 (PDT)

I didn't notice this post before. I ended up setting this up as a keyvalue after discovering the value(flashlight has an atten ConVar). Sadly, this feature has a major downside though; on brushes(not models), when you get up close, the attenuation fades away. Gary 21:37, 10 October 2011 (PDT)

Moving Object Parenting

How do you make this entity parented to a moving object ? There's a parent field, but it doesn't follow the moving object at all. The light just stay where it was turned on, and never follow it's parent until it is turned off and on again (then it appears at the same level than its parent, but don't move). --NykO18 15:38, 28 Aug 2008 (PDT)

I have updated the article with several bug fixes including the one for this particular problem. As of now, you can only parent this entity in a mod that incorporates these fixes. Yatar 19:49, 7 Nov 2008 (PST)

Parenting is broken again somehow. I've tested this with just a base fix of all the code presented to test. So for now I'm going to place this here until one of us figures out how to re-fix it.

By default, this entity's position only gets updated when it gets turned on. Thus, parenting does not work. To fix this, open c_env_projectedtexture.cpp and in line 225, comment out 3 lines like this:
    //	if ( bForceUpdate == false )
    //	{
    		g_pClientShadowMgr->UpdateProjectedTexture( m_LightHandle, true );
    //	}
In line 233 in the Simulate function, change the argument false to true like this:
    UpdateLight( true );

--Gear 20:57, 14 Jan 2009 (PST)

This is not a fix, but merely a workaround.

You can use this if you feel it is important for your map to have an env_projectedtexture which is parented and also updates in real-time.

Make two env_projectedtexture with the exact same settings (unless you're going for a flickering look), but uncheck "Enabled" on the second one.

Give them appropriate names and parent both to the same object, I've named mine "projectedTexture1" and "projectedTexture2".

Now make a logic_timer and set the "Refire Interval" to 0.02.

Go to the outputs section of the logic_timer and add the following:

Object Properties: logic_timer

My Output	Target Entity	Target Input	Delay
OnTimer	projectedTexture1	TurnOff	0.00
OnTimer	projectedTexture2	TurnOn	0.00
OnTimer	projectedTexture1	TurnOn	0.01
OnTimer	projectedTexture2	TurnOff	0.01

That's it.

If you want to kill or temporarily disable the lights, you should do something about the timer as well.

Remember, what this does is that it continuously switches between the two lights in a hundredth of a second, so if you want some flickering action make irregularities between the two.

--P4INKiller 00:55, 29 December 2009 (UTC)

I've also been messing around with this and I've found that a logic_relay that continually triggers itself to re-parent the entity to an object works too. Apparently from what I've seen, re-parenting works just as well as turning it on and off. --dky 16:35, 29 March 2010 (UTC)

Setting r_flashlightscissor to 0

I'm not sure how to go about doing this, as it's not included in the SDK, in c_hl2mp_player.cpp I tried adding:

 DLL_IMPORT ConVar *r_flashlightscissor;

Below other ConVar definitions on line 54 and 55 and then in the class's constructor I added:

 r_flashlightscissor->SetValue( 0 );

However this doesn't compile, what am I missing and how can I fix this? -- Sicolet 17:31, 26 Nov 2008 (PST)

The problem is that it is a cheat, and therefore needs to tell Source to turn it on and initiate every time a map is loaded. I managed to get around this by loading another Dll's settings much like you did, but our coder also did a "Fuck you Source" in the code. I'll ask him how he managed to do it in the code.--Gear 16:59, 15 Dec 2008 (PST)

ConVar *r_flashlightscissor = cvar->FindVar( "r_flashlightscissor" );

r_flashlightscissor->SetValue( 0 ); You can thank some of the guys on the Steam Powered forums for this.--1/4 Life 15:33, 12 Jan 2009 (PST)

Configurable Values for number of lights?

The article has this:

m_nMaxDepthTextureShadows = YOUR_CHOSEN_MAX; //with your number

So, I figured i could make it configurable based on a ConVar so i could set it without compiling code for easy performance testing, and to determine how many lights is too many.

so I did this:

ConVar max_projected_lights( "max_projected_lights", "1" );

and this later on:

m_nMaxDepthTextureShadows = max_projected_lights.GetInt();

but there's a problem. first of all, I'm seeing a warning message "too many shadow maps this frame" just when the map loads.

I didn't think that was a huge problem, but then the player flashlight has weird behavior of projecting the result of the projection of one of the env_projectedtexture in the level. for example, i have a creature in front of an env_projectedtexture, then i click on my flashlight (while in a different part of the level) and i'm seeing the shadow of the creature in my flashlight.

This doesn't happen when I hard code an integer value for m_nMaxDepthTextureShadows. vecima 02:52, 30 March 2009 (UTC)

You're working with the init() function, which sounds very much like something called only once. You'll need your convar to execute a callback function that changes m_nMaxDepthTextureShadows whenever it's called. --TomEdwards 21:10, 30 March 2009 (UTC)

I might not have been clear. I don't want to change the number of allowed lights on the fly, I just want a number that is decided in the config file, so when the game starts up it uses that number. I didn't define the ConVar in the Init(), I just called it's GetInt(). vecima 04:23, 31 March 2009 (UTC)

If you want to save a cvar's value to save you'll need to give it the FCVAR_ARCHIVE flag. Beyond that, I don't know... --TomEdwards 18:23, 31 March 2009 (UTC)

I tried both FCVAR_ARCHIVE and FCVAR_REPLICATED and had the same problem both times. I guess it's not a big deal, but one of the things I was thinking of doing was making a mod codebase with entirely configurable values for those who don't code. for now I'll just use a set value. thanks anyhow. vecima 03:46, 6 April 2009 (UTC)

Be careful on setting the number of lights in a single map, oddly this value effects Render Targets by a large amount. 20 would be reasonable.--Gear 09:02, 6 April 2009 (UTC)

maybe adding the convar as static convar helps --Pfannkuchen 15:13, 10 February 2010 (UTC)

Portal 2 only using shadow-mapped lighting?

I don't think Portal 2 uses this as it's only light source, looking at pictures there appears to be ambient lighting which env_projectedtexture does not produce. I am pretty sure Portal 2 uses it as a majority light source. I may be wrong but we can only assume until official information is released.

I just think where it says that Portal 2 uses it as it's only light source should be changed to something like "Portal 2 appears to use shadow-mapped lights for a large portion of it's lighting." so people don't think that these things are going to replace all other light sources.

Not a big deal, just expressing my thoughts on the subject. --Gary

Yeah, I was thinking the same thing, portal 2 does not appear to be only using projected textures. I think the sentence "Support for projected textures will be greatly enhanced in Portal 2, which appears to use them for 100% of its lighting." should be reworded- or removed entirely. It doesn't really serve much of purpose, and it's only conjecture, based on some work in progress images for a game that's not due out for probably another 8+ months. --Stoopdapoop 04:04, 24 June 2010 (UTC)

Honestly, I don't think there's any difference between Portal 2's engine and source 2009. It looks like they just applied some of the fixes from this wiki (and not even all of them, notice how the viewmodel isn't lit properly, the shadows are grainy as hell). The cool radiosity effects and motion blur and ambient occlusion are always in the bullshot source film maker videos, but just like in the other source games those effects never make it into the game. Anyways what I'm trying to say is the shadows in Portal 2 are nothing new and could be done in source 2009. --Wilsonc 09:31, 6 November 2010 (UTC)

I honestly don't know the difference between the 2007 and the 2009 engine. I know the shadows in AS sucked as they were horribly grainy.

Also, I assume the view model shadowmap receiving will be fixed in the release build of Portal 2. I do believe they did something with this entity, the shadows are far better looking from what I've seen, but that could just be a higher shadow map resolution(which us modders can already do). I remember seeing the video that had Whitley's flashlight, it had a few shadow mapped lights in there. Maybe they optimized them? Maybe they have definable resolution and grain per entity? Which reminds me to ask, anyone have any idea how to make the shadow map resolution definable per entity, for example; I could have a big light with a resolution of 2048 and a small light with 512? --Gary

And they still forgot to make the portal gun receive dynamic shadows. XD --Welsh Mullet 00:04, 16 November 2010 (UTC)

Some more info

After much researching and stuff, I have come to the following understandings:

-Source 2007/OB shadow mapping sucks, besides having poor shadow filtering, it has many graphical problems such as ghosting and bleeding. This entity is almost useless due to these problems as they take away almost as much as they give to a scene. Filtering can be fixed in code but the rest I believe is lower level then we have access to.

-AlienSwarm's shadow mapping is the best we got SDK access to, it fixes all of the errors in Src2007 and gives many more features. There is even code for per-entity shadow map resolution, material(VMT) projection, and ortho projection. Now if only I could get the AS coebase to work without crashing constantly.

-Portal 2's shadow mapping is the best of all but it limited due to blocks in code such as the shadow map res capped at 1024 and you can only have one projectedtxture active per map. It is quite sad we don't have real SDK access to this codebase...

So, yeah... I really think we should add some more info to the page. Such as sections for different engine branches(2007, AS, Portal 2, etc) explaining these points and maybe even showing pictures. Env_projectedtexture uses the most popular dynamic shadowing method in gaming world(shadowmapping) and can be extremely useful or degrading to a scene. The more info we put out the better. Gary 01:06, 10 October 2011 (PDT)

Was just messing around with the entity more and(in Src2007 codebase) I noticed that the fade distance for projectedtextures doesn't apply to models(in contrast to BSP, where the lighting will fade when you get a few feet away).

Also, this entity is useful for when you need a dynamic per-pixel light source. Which looks way better than per-vertex. Here is an example of projectedtextures on a door prop: [1]

Gary 21:30, 10 October 2011 (PDT)

Hey, wouldn't it be possible to use the projected texture as sunlight if it followed the player and somehow hides lightmaps that its projected over? I got env_projectedtexture to follow the player but I couldn't get it to keep its angle and height from getting all weird, and I have no idea how to use it to hide lightmaps :S --Wilsonc 23:35, 20 October 2011 (PDT)

Portal 2 and I think ASW has something along those lines. Though, because the method is still only using one shadow map, it will only work in specific scenes. Gary 10:26, 2 November 2011 (PDT)

Forgot to respond... There are two entities, env_global_light and Sunlight_shadow_control, added in AlienSwarm. They are just ortho(flashlight state option) flashlights bound to the camera. But only a single flashlight. I was able to modify this to use multiple: http://www.interlopers.net/forum/viewtopic.php?p=476920#p476920

Sadly, a major contributor to the cost of flashlights, is the area they cover. So this is kinda slow covering large maps. Gary 00:15, 21 July 2012 (PDT)

Left 4 Dead 2

Does anyone know how to get this to work with any other VTF (not the default flashlight)? I've tried to enter a vtf without smartedit, tried using logic_auto and setting SpotlightTexture, but then the flashlight just disappears. I'm trying to make a projector displaying something, as in cs_office in CS:GO. I had hoped they had already fixed the bugs in the L4D2 engine? --StephenB 07:52, 22 October 2012 (PDT)

Thinking about it, if it's shadow casting, it will likely be screwed up when you; shoot a gun, turn on the flashlight, or do a thirdperson animation event(healing, grabbed by infected, etc.). I doubt L4D2 has more than one shadow map enabled, like all Valve games excluding CSGO's CSM system. Gary 19:07, 2 December 2012 (PST)

That's sad. There's a bit of hope though: [2] --StephenB 14:34, 7 December 2012 (PST)

Ambient

I've been told by Practical Problems that the Ambient input and keyvalue both do nothing. I haven't seen any effect from them myself so I'm going to take them off the page since they aren't in the FGDs either. Also, I changed "episode two" to "episode one" near the top. This page was first made in 2006, clearly episode one was the first game to have it. Pinsplash (talk) 00:23, 30 September 2018 (UTC)

Remove Fading?

if i move far away from the light, it will fade and disappear.
so is there any way to remove this? -- Ze Voidah

Well, if there are any keyvalues related to fade distance, setting them to 0 might fix that. Of course, it would be better to fade out when the player cannot see it from their current position. --Tiny Desk Engineer (Talk Page) 09:39, 21 June 2022 (PDT)

Intensity part of of the Color Keyvalue is broken

As far as I can tell, at least in Portal 2, changing the intensity part of the projected texture's color to anything that isn't the default 200 causes the entire entity to stop projecting anything. This weird behavior has given me countless headaches, and it doesn't seem to be on the main page for this entity. Should we get this added?

How expensive is env_projectedtexture exactly?

This page says that "env_projectedtexture is more expensive than other forms of lighting" and that it should be "used sparingly" but Garry's Mod seems to handle several lamps without noticeable frame drops, and this very page says that Portal 2 uses them extensively for world lighting. How little is "sparingly" exactly?

Portal 2 only supports One env_projectedtexture, Garry's Mod's limit is Nine, Mapbase's limit is Four, and Portal 2: Community Edition's limit is Eight. --GaijinViking 11:58, 21 June 2022 (PDT)