NewLight Point

It creates an invisible deferred light source that shines in all directions, includes godrays and lightcookies.
Represented by class CNewLightPoint.
==Keyvalues==
==Inputs==
==Shadow filtering==
In versions of the game before Necro Patch uses PСF filter. The shadow edges are sharper and exhibit a more distinct transition. There are visible aliasing artifacts, particularly on the edges. Shadows from small or thin objects were also indistinguishable. However, it was pretty good for shadows with low resolution, because they looked blurry. The shadows are somewhat similar to those that can be seen from the projected textures in .
File:shadowfilter_old.jpg| frame |Barney's hand with old shadow filtering.
The Necro Patch replaced PСF filter with PCSS filter. The shadow edges appear smoother and less jagged. The transition from the shadow to the lit area has more gradient-like softening. Shadows have become more detailed for small objects. Because of this, you have to adjust the shadows more carefully.
File:shadowfilter_new.jpg| frame |Barney's hand with new shadow filtering.
This filter has one significant issue: there is now noticeable noise in the shadows. This is mostly noticeable in low resolution shadows, this spoils them quite a lot (although it makes them more detailed). There is no way to disable this effect. The noise also makes the shadows more similar to shadows from flashlight in . It is worth noting that such thing exists in more modern engines (Unreal Engine 5 for example), so you can ignore the noise if it's not very noticeable, especially on shadows with high quality.
The noise is adjusted via ShadowRadius and ShadowMapLOD values, mainly via ShadowRadius; you even can disable the noise with 0 value, but this will make your shadows will look like stairs/pixels. 
File:shadowfilter_new1.jpg| frame |The noise example.
==Static shadow maps==
If our light source remains in the same position and never changes it, we expect that shadows from world geometry, displacement, and even bmodels (brush entities) are completely static, this means that we don't need to update shadows for them every frame, so it would be nice to bake shadows for all such objects to save performance. This is why we need static shadow maps. 
When your light appears, static shadow maps skip all the dynamic models in their pass and take 1-6 pictures of everything mentioned above, then static shadow maps applies to the lighting from the light source and never change again (until save reload).
This doesn't happen if your light source is disabled, so you need to keep it enabled on spawn around 1 second. If you need disabled light source - set intensity value to 0 and then after 1 second turn off light source (don't forget to set required intensity value).
Static shadow maps are used for Static and Stationary light type. For Stationary type, engine also disable shadows passes in dynamic shadows for everything mentioned above, so that the use of static shadow maps makes sense (this still saves performance quite well). Dynamic light type don't use static shadow maps at all, because it can move, so we need to have dynamic shadows for everything.
Important to note that bmodels are also in static shadows maps, including , , , etc. This is true, despite the fact that such objects can be removed or moved. Most likely this is due to , which is very similar in principle to regular world geometry, but cannot be removed or moved, unlike all other brush entities. It gives some problems, because shadows from lab doors or elevators will remain static, while these objects are moving. There are 2 good ways to workaround this issue, "lazy" method and " time-consuming" method. The first is very simple and quick, just use Dynamic light type, this will reduce performance but will completely fix the problem and save your time. The second is using Propper with converting your brush to model, you'll need spend time on setting and brush replacing, but this will also save performance and solve the problem.
==Shadow map slots==
Shadow map slots is how many lights with shadows you can have per level. There are 3 separate shadow map slots, High (for lights with 1024 value for ShadowMap LOD property), Medium (for lights with 512 value for ShadowMap LOD property) and Low (for lights with 256 value for ShadowMap LOD property).
In High and Medium you can have 48 separate shadow maps, for Low you can have 47 separate shadow maps (143 shadow maps in total).
Each spot light with shadows takes 1 shadow map slot, so you can have 48/47 spot lights with shadows, if they are using the same value for ShadowMap LOD property.
Each point light with shadows takes 6 shadow map slots. This is due to point light isn't just omnidirectional light source, it's 6 spot lights in one entity. This means that you can have 8 point lights with shadows, if they are using the same value for ShadowMap LOD property. You can increase this value if you need, just disable shadows for one of the shadow face properties.
If one of the shadow map slots is full - you will not be able to have shadows for more lights with such shadow quality, you will need to use other value for ShadowMap LOD property.
Point lights and spot lights doesn't counts separately. You can't have 48 spot lights with 8 point lights, but you can have 6 spot lights with 7 point lights.
You can free up shadow map slots with Kill input. So, you can place triggers which will Kill lights that player can't see and spawn new lights via (uncheck the second flag for , this prevents some bugs). This helps a lot when you want to have many dynamic lights in different areas.
Important to note that due to some engine bugs you can't use many lights with shadows. Some tests show that 9th point light cause lights with shadows to be very glitchy. This can be done with spot lights as well. So don't be surprised if at some point you find something like this.
File:manyshadowslotsbugg.jpg| frame |The bug example.
It looks like you can workaround it if you will switch ShadowMap LOD property values from higher to lower.
==Lighting behavior with VIS and areaportals==
===Static type===
Static type is the most stable, since its shadows are baked in and updates only with save loads or while lighting turning on. It shows all shadows even with closed areaportal.
File:staticlight_0.jpg| frame |Areaportal is open.
File:staticlight_1.jpg| frame |Areaportal is closed.
===Stationary type===
Shadows for static props and brushes are baked, but not for physics props and other dynamic models. This means that shadows from dynamic models will disappear if they are hidden by a closed areaportal or if VIS is hiding such objects. Shadows for static props and brushes will not disappear.
File:stationlight_0.jpg| frame |Areaportal is open.
File:stationlight_1.jpg| frame |Areaportal is closed.
In some cases, this can be noticeable if dynamic model creates a large shadow.
File:Theboxshadow_0.jpg| frame |Areaportal hides the box, note that there is no shadow.
File:Theboxshadow_1.jpg| frame |Areaportal shows the box, now there is a shadow of the box.
With .
File:thewireboxshadow_0.jpg| frame |Areaportal hides the box.
File:thewireboxshadow_1.jpg| frame |Areaportal shows the box.
===Dynamic type===
Shadows for static props and world geometry are baked, but not for dynamic models and brushes. This means that shadows from dynamic models and brushes will disappear if they are hidden by a closed areaportal or if VIS is hiding such objects. Shadows for static props and world geometry will not disappear. Moving lighting will update shadows for static props and world geometry, even with closed areaportal.
File:dynlight_0.jpg| frame |Areaportal is open.
File:dynlight_1.jpg| frame |Areaportal is closed.
===Player spawn and areaportals===
If player spawned in position where areaportal don't hide objects - shadows will be fine. Otherwise, static shadowmap will not see models with bmodels and will bake shadows only for world geometry and displacements. This problem is not relevant only for Dynamic light type. The problem disappears after save reload from proper position.
File:psaa_0.jpg| frame |Player spawned in position where areaportal don't hide objects. The columns are , the pipes are .
File:psaa_1.jpg| frame |Player spawned in position where areaportal hide objects. Note that the columns and pipes don't have any shadows.
==Lighting behavior with start/end fade dist for prop_static==
This mechanic has some issues with static shadowmaps. It seems that there are limitations that don't allow to fix these issues, or this issues was not noticed at the development stage.
===Static type===
If player spawns in fade radius - shadows will never disappear (until save reload if out of radius).
File:fadepropstaticlight_1.jpg| frame |In radius.
File:fadepropstaticlight_0.jpg| frame |Out of radius.
If player spawns out of radius. - shadows will never appear (until save reload in radius).
File:fadepropstaticlight_3.jpg| frame |
The same for props with both Start and End fade dist.
===Stationary type===
The above mentioned issues are also available for this type.
Appears issue for prop_static with both Start and End fade dist.
If player spawns in Start fade radius - shadows will never disappear (until save reload if out of radius). The same happens if player spawns in End fade radius.
If player spawns out of radius - shadows will appear if you are in End fade radius and disappear if you are in Start fade radius (until save reload in radius). This happens because prop_static actually disappears completely, and creates a separate object as a fading model (this is also why decals disappear if player is out of Start fade radius).
File:fadepropstatiorlight_1.jpg| frame |In radius.
File:fadepropstatiorlight_2.jpg| frame |Out of Start fade radius.
File:fadepropstatiorlight_3.jpg| frame |Out of End fade radius.
===Dynamic type===
Dynamic type don't use static shadowmaps at all. This means that there is no problems with fading prop_static at all.
==Dedicated ConVars==
==Bugs/Limitations==
See /Bugs and limitations
== See also ==
* - directional sun light with godrays only.
* - spawner of deferred point lights.
* - cinematic dynamic lens flare.
* - spot deferred light entity.
* - entity that changes deferred light settings.
* - entity that changes godrays settings.
* - deferred cascade sun light entity.
* New Lights Editor - in game deferred lights editor.
* Effect flags - effects flags, some of them are dynamic light effects.
* BlackMesa XenEngine: Part 4 – Lighting & Shadows - page from Chetan (lead programmer for Black Mesa) about new lights.
* BlackMesa XenEngine: Part2 – How a Frame is Rendered - page from Chetan (lead programmer for Black Mesa) about how a frame is rendered.
* BlackMesa XenEngine: Part1 – Heavily Modified Source Engine page from Chetan (lead programmer for Black Mesa) about .