General information about Black Mesa new lights/Bugs and limitations

General Information

Entities ( Point Light | Spot Light | Directional | Spawner )

Settings Entities ( Light Settings | Godrays Settings | Gbuffer Settings )

Misc ( New Lights Editor | Bugs )

edit

All the bugs and limitations divided into the following categories:

• Lighting issues - mainly lighting shader issues.
• Shadow issues - issues related to shadowmaps.
• Godrays issues - issues related to godrays.
• NewLight_Point issues - bugs and limitations only for newLight_Point entity.
• NewLight_Spot issues - bugs and limitations only for newLight_Spot entity.
• NewLights_settings issues - bugs and limitations only for newLights_settings entity.

Note:Some entity specific bugs are in entity page.

Lighting issues

Transparency issues with deferred lighting

None of the available shaders that support transparency can render shadows and lighting on on objects if transparency is enabled. Usually other games and engines use deferred shading for opaque objects, then switch to forward rendering for transparent objects, but Black Mesa rendering is not doing so.

• 

  Example from bm_c2a5g, expected that the shadows from the ropes and the plastic road cone on the window will be rendered, but this doesn't happen.

• 

  The same scene, but with Counter-Strike: Global Offensive cascade lighting which is not using gbuffer.

Deferred lighting is also incompatible with transparency for VertexLitGeneric and Lightmapped_4WayBlend, it shows one of the lighting layers applied to the color of the transparent texture.

• 

  No $translucent. Behind the wall placed lighting and some models with in a small room.

• 

  With $translucent. Now the player can see everything, but only what the light covers.

This issue also applies to brushes with no transparency, but which is a part of a func entity with a transparent brush (the only exception is func_detail). This happen even if transparency used for shader that doesn't shows one of the lighting layers. Doesn't work only if brush has alpha texture.

• 

  This sticker is brush, that is part of func_brush, which uses glass as part of itself. Flashlight off.

• 

  This sticker is brush, that is part of func_brush, which uses glass as part of itself. Flashlight on.

The same will happen if used $decal material parameter.

• 

  Example from bm_c1a1c.

Similar issue will happen if overlay/decal is applied on a geometry with transparency.

• 

  The metal speaker is overlay that use $alphatest, but lighting from the health charger is still visible, because the overlay is applied on the transparent window.

If a func entity or model uses render mode Glow (3) or World Space Glow (9) - they will show one of the lighting layers as well. This means that you can't use these renders to make your brush transparent, you will need a separate texture with alpha texture and material with $translucent.

• 

  Example with multiple props and brush entity, they are using Glow render mode.

Using other render modes (except Normal (0) and Don't Render (10)) on a brush entity will cause many rendering issues. Example in this short video.

The cloak material shader parameter will also cause this issue, even if object is not transparent at the moment.

• 

  Example in bm_c2a3c. The female assassin is not transparent, but the lighting layer is still showing through.

There is not much workarounds. In some cases, $alphatest can be used, because it can give similar to $translucent result, it will also allow object to create dynamic shadows.

• 

  $translucent.

• 

  $alphatest.

Confirm:Is there more ways to get transparency issues ?

---

No lighting for particles

Due to the issues with transparency, dynamic lights can't lit particles. For env_smokestack it can be partially workaround by using env_particlelight entity. Using ambient or bounced light from lightmapped lights can help in some cases.

• 

  Example using dynamic light and regular light for func_smokevolume.

---

Decals issues with deferred lighting

Decals and overlays don't use bump maps, this causes lighting to using bump map from object the decals applied to, this can cause issues like in the picture.

• 

  Papers on a concrete surface. Everything looks good.

• 

  Added alarm red light, now the papers are barely visible.

If a decal is applied to surface with alpha channel, using deferred light on such decal will make it transparent on pixel where alpha channel uses black color.

• 

  The metal ring on a grate around the yellow pipe. Everything looks good.

• 

  Enabled green light source from the player. Now the metal ring is transparent there the grate has holes.

---

Brush polygons clipping deferred lighting

Sometimes brush polygons clip deferred lighting. Can be fixed if divide invalid brush into two parts.

Note:Usually happens if used fast compile settings for a map.

• 

  First example with mat_wireframe 0.

• 

  First example with mat_wireframe 1.

• 

  Second example with mat_wireframe 0.

• 

  Second example with mat_wireframe 1.

---

Objects with refract shader can "self refract" if illuminated by deferred lighting

If a model uses texture with the refract shader and a regular texture with deferred lighting support, the lighting layer for regular texture will be visible in the model's refraction.

• 

  Black Mesa: Azure Sheep, as_c3map01 - flashlight disabled, everything looks good.

• 

  Black Mesa: Azure Sheep, as_c3map01 - flashlight enabled, now this magnifying lamp "refracts self".

Similar issue happens if the model texture behind wall with refraction.

• 

  Flashlight disabled, everything looks good.

• 

  Flashlight enabled, now this wall shows the lighting layer for the regular texture.

Workaround:Divide model into two separate parts, the first should use only regular textures, the second should use only textures with the refraction shader.

---

Viewmodel lighting in frame buffers where it should not exists

Despite the separate render pass for viewmodel lighting, it still appears in shaders where used the player's camera. This affects _rt_FullFrameDepth, _rt_PowerOfTwoFB, _rt_WaterRefraction and shaders that use these.

• 

  Example for _rt_FullFrameDepth and _rt_PowerOfTwoFB.

This also affects Refract and motion blur shaders.

• 

  Refract.

• 

  Motion blur.

This bug doesn't appear with disabled viewmodel rendering (r_drawviewmodel 0).

Todo: Find out if there is more shaders with this issue.

---

Gbuffer is not displayed during cubemaps building

This causes lighting and other gbuffer related affects not shown in cubemap reflections, which in some cases significantly affects the difference between the scene in the cubemap and the real scene.

• 

  The actual scene (used dynamic yellow lighting for the crystal).

• 

  The scene during cubemaps building (the tunnel appears to be dark, although the crystal glows due to $selfillum).

• 

  The scene from the cubemap image in the game on RPG viewmodel (the crystal is visible, but no the cave).

---

Gbuffer is not displayed 3D Skybox

Due to gbuffer is not included for sky_camera, this causes gbuffer effects not displayed in 3D Skybox, including lighting, godrays, cascade shadows, lensflares, etc.

• 

  Example, the sky_camera is used in this small area with alien grunt melee model and newlight_point, but the lighting and godrays is not visible in 3D Skybox.

---

Gbuffer is broken with -tools window

If Full Screen is not used, the gbuffer will not work properly. One of issues caused by this is full absence of deferred lighting. It doesn't affect anything, but it can interfere in rare cases when working with -tools window.

• 

  In Full Screen.

• 

  Out Full Screen.

---

Broken water transition for viewmodel

After the Necro Path update, viewmodel lighting does not transit properly between water surface. Only for water with enabled refraction.

• 

  Example with crowbar, note that the top part is not lit.

---

Shadow issues

Deferred lighting shines through nodraw texture

The toolsnodraw texture doesn't create dynamic shadows for dynamic light sources, there is no option for this feature to be enabled/disabled.

Workaround:If a dynamic light source illuminates face that the player will never see, use cheap textures with low resolution, a good solution would be toolsblack or any UnlitGeneric texture.

• 

  The scene from player's position in bm_c2a2a map.

• 

  The scene from the opposite side.

---

Shadow acne when player's camera is at a great distance

Shadows ache can appear if the player is at a great distance from the light source. This happens because of aliasing issues. It is affected by the game resolution as well, for example, in bm_c4a1b1 this bug shows up in 1920x1080 resolution, while with 3840x2160 doesn't (although the light still flickers). The crossbow scope camera doesn't affect the bug, unlike regular zoom.

Workaround:Can be fixed by increasing the NormalBias value.

• 

  Example in bm_c4a1b1.

• 

  bm_c4a1b1. NormalBias - 1.

• 

  bm_c4a1b1. NormalBias - 5.

• 

  Black Mesa: Black Ops - Restored, bmops_map_2. NormalBias - 0.5.

• 

  Black Mesa: Black Ops - Restored, bmops_map_2. NormalBias - 1.5.

---

Lights with enabled shadowmaps disappear after materials reload

Only for lights which uses shadowmaps. This issue happen when Hammer opens while running the game, when a client disable cubemaps with mat_specular 0, when a client reload all materials with mat_reloadallmaterials, e. t. c. Can be fixed with save reload. This bug doesn't affect anything directly, but can confuse many mappers.

• 

  Before mat_reloadallmaterials.

• 

  After mat_reloadallmaterials. Note that the dynamic lighting from the tripod spotlight disappeared.

---

Shadow acne with moving lights

Shadow acne (also can be called "projection clipping") appears for moving lights with shadows if parent is moving at high speed. This issue appears even if used a very high value for nr_shadow_max_passes_per_frame console variable. This issue causes black squares or dark floors due to incorrect shadow overlaying. Multiple examples can be seen in this 1 minute long video.

• 

  Example in bm_c1a1c. Before the elevator falls.

• 

  Example in bm_c1a1c. During the elevator falls.

Can be partially fixed with NormalBias value increasing. Also, if your moving light is just simple decoration (the puzzle crystals from Xen is great example), it is highly recommended to disable shadows to save limits and performance.

• 

  NormalBias - 1

• 

  NormalBias - 10

---

Noise in shadowmaps

The PCCS-based soft shadow filtering (implemented since Necro Patch) includes a noticeable noise effect. A compromise choice for ShadowRadius and ShadowLod helps minimize noise while keeping shadows soft.

• 

  Example in bm_c2a2b.

---

Shadows doesn't appear instantly after save load

The game doesn't load shadowmap for dynamic lights instantly, which is why light sources remain without shadows for a short time. This issue doesn't depends on how powerful device the game running at. The more dynamic lights with shadows level has, the more noticeable this issue, because for the game it takes longer to load shadowmaps. Example in a short video.

• 

  Before save load.

• 

  After save load (note that the large shadow from the bucket disappeared).

Workaround:Enable in worldspawn settings Level Fade In to hide this issue, this setting also will hide some other issues with loads in Black Mesa. env_fade entity can be used for this as well.

---

No self-shadowing support for viewmodel

Deferred lights doesn't support self-shadowing for blackmesa_viewmodel entity, like env_cascade_light or env_projectedtexture from older Valve engine branches. There is also no virtual lighting system.

• 

  Example with cascade shadows, note how one of gluon gun switches creates dynamic shadow on the model.

• 

  Example with newLight_Spot, note that there is no shadows on the gun.

---

Shadows doesn't appear instantly if light wasn't enabled

If dynamic light source was disabled on spawn, shadows will not appear instantly, this also happens if player's camera didn't see this light source enabled initially. It is noticeable in dark areas. Example in this short video.

Workaround:Use 0 value for light intensity on spawn. When should be turned on - set required value via SetIntensityForLight input with delay of ~0.1-0.5 seconds after turning on.

---

Flickering shadows and low frame rate

Using lots of lights in single frame can cause low frame rate for shadowmaps, unnatural flickering and "pulsing" shadows. Using a hight value from nr_shadow_max_passes_per_frame (60-100 or highter) can help fix the issue, but in some cases it won't help. Example in this short video.

---

Godrays issues

Transparency issues with godrays

Godrays and their also disk doesn't work with materials if enabled $translucent, or $decal, or cloak, or any render mode except Normal (0), or decal/overlay applied on a geometry with transparency. Disable godrays when you need or use $alphatest if it'll give required results.

• 

  Bug example in bm_c1a3c.

• 

  Sign from the other side.

---

Godrays doesn't process viewmodel if the player is underwater

Necro Patch fixed the old issue with godrays that wasn't processing models above water. This fix caused new issue. Godrays doesn't process blackmesa_viewmodel entity if the owner is underwater. Doesn't happen with func_water and func_water_analog.

• 

  The player is not underwater.

• 

  The player is underwater.

---

Godrays can't be displayed in monitors and reflections

Godrays for monitors and reflections was added with Necro Patch. However, this is disabled in the code by default in the client code, because of incorrect godrays position. There is no way to enable this feature.

• 

  Example with water.

• 

  Example with monitor.

---

Godrays doesn't work with refraction

Even if godrays is behind surface with refraction, they will not correspond to the refracted scene, an object can be refracted, but not its shadow from the rays. Godrays will also not blend with refraction color.

• 

  Example, note that the magnifying glass is refracted, but not rays.

---

NewLight_Point issues

Shadowmaps split boundary artifacts

newLight_Point uses 1–4 separate shadowmaps to cover its projection volume. When an object is positioned close to the boundary between these shadowmaps, the shadow may appear broken, clipped, or misaligned. This artifact is most noticeable with point lights using low-resolution shadowmaps, where precision issues become more visible.

• 
• 
• 

---

Clipping near new light BBOX volume corners

If a client is near newlight_point's BBOX volume corner, the lighting starts clipping on the client side in a form of triangle shape. The size of clip depends on how close the client to the BBOX corner volume, it can be minimal or hide lighting completely. This bug disappears (the triangle shape goes away) if the client is in BBOX or is not near one of the 4 corners. The distance and how far/close should be the client directly depends on BBOX volume size.

• 

  Example with enabled BBOX rendering.

---

NewLight_Spot issues

Sharpness for spot light with shadowmap

This is noticeable if the spotlight is not pointing straight ahead.

Workaround:Can be partially fixed by increasing the NormalBias value.

• 

  Example.

• 

  Example bm_c1a2b.

---

Сlipping shadowmap for rotating spot light

This appears if newLight_Spot rotates at medium or high speed. Using high value for NormaBias can partially solve this issue. Disabling shadows will solve the problem. Example in this video.

• 

  Example in a dark room.

---

Rotation interpolation issue for shadowmap

Rotating spot light can have troubles for shadowmap rotation interpolation, this issues causes unnatural "twitching". Example in this video.

• 

  First frame, everything looks good.

• 

  Second frame, the shadow from the car battery is in a wrong position.

• 

  Third frame, everything looks good again.

---

NewLights_settings issues

Range increasing doesn't increase BBOX

This results in the lighting disappearing before the player's field of view moved away completely from the lighting. This affects all light types, including Dynamic type.

Workaround:You can use InputFixRotBugDueToTram input to reset BBOX values for newLight_Spot entity.

• 

  Before applying settings. Range - 56.
  

• 

  After applying settings. Range - 500.
  

---

OuterAngle increasing/decreasing doesn't change ShadowFOV

Static shadowmaps will be broken after increasing outer angle value for newLight_Spot (fixes after save reload). For Static light type, you will not have notable issues with decreasing, but shadows will not look better. Stationary light type will be broken after decreasing as well.

• 

  Before applying settings. OuterAngle - 30.
  

• 

  After applying settings. OuterAngle - 60.
  

---

AngularFallOff may broke shadows for Stationary light type

Sometimes, for some reason, changing AngularFallOff value for Stationary light type will make your shadows look broken.

• 

  Before applying settings. AngularFallOff - 0.
  

• 

  After applying settings. AngularFallOff - 5.
  

---

Range increasing/decreasing will make static shadowmaps broken

Range increasing/decreasing doesn't update static shadowmaps, this leaves old static shadowmaps that cannot be properly overlaid with the changed range value.

This is how it looks with increasing.

• 

  Before applying settings. Range - 50.
  

• 

  After applying settings. Range - 500.
  

• 

  This is how it supposed to look like.
  

This is how it looks with decreasing.

• 

  Before applying settings. Range - 500.
  

• 

  After applying settings. Range - 50.
  

• 

  This is how it supposed to look like.
  

---