|
|
Line 1: |
Line 1: |
| {{LanguageBar}}
| | ==Lightcookies== |
| {{back | Black Mesa Level Creation}}
| | ===What is a lightcookie texture ?=== |
| [[File:NewLight_PointMain.jpg|720px||thumb|right|NewLight_Point in {{code|End Game}} chapter (used for the portal).]]
| | Lightcookie (a. k. a. "Texture Light") a texture or mask applied to a light source. It is usually used to shape the light's output or fake shadows with specific patterns (which, unlike shadowmaps, can be translucent and look more accurate). It also can be used for stuff like projectors, cautists, disco spheres, etc. |
| {{this is a|point entity|name=newLight_Point|game=Black Mesa|sprite=NewLight Point.png}} It creates an invisible [[Deferred lighting|deferred light]] source that shines in all directions, includes godrays and lightcookies.
| |
| {{Note|You can have only 512 point light entities placed in the map editor.}}
| |
| Represented by class <code>CNewLightPoint</code>.
| |
| {{todo|Rework this page.}}
| |
| ==Keyvalues== | |
| {{KV Targetname}}
| |
| {{KV|Pitch Yaw Roll (Y Z X)|intn=angles|angle|nofgd=1|This entity's orientation in the world. Pitch is rotation around the Y axis, yaw is the rotation around the Z axis, roll is the rotation around the X axis.
| |
| :{{note|There is almost no differences if you're using point light with no texture. Things changes if you're using textures.}}
| |
| }}
| |
| {{KV BmNewLightOldFalloff}}
| |
| {{KV BmNewLightBaseMain}}
| |
| {{KV BmNewLightShadowMain}}
| |
| {{KV BmNewLightShadowFace}}
| |
| {{KV BmNewLightShadowBias}}
| |
| {{KV BmNewLightCookieMain}}
| |
| {{KV|LightnGodRayMode|intn=LightnGodRayMode|choices|This determines what effects will be available to use for the light source. Keep in mind that the default choice is Light.
| |
| :*0: Light - light only.
| |
| :*1: Godrays - godrays only.
| |
| :*2: Both Light and GodRays - both light and godrays.
| |
| :{{bug|hidetested=1|Even if godrays is turned off, the game will still think that the godrays is used if choice is <code>Godrays</code> or <code>Both Light and GodRays</code>.}}
| |
| }}
| |
| {{KV BmGodraysNormal}}
| |
| {{KV BmGodraysFancy}}
| |
| {{KV BmNewLightShadowPasses}}
| |
|
| |
|
| ==Inputs==
| | In Black Mesa, it can be used via "'''Texture name for TexLight''' ''(texName)''" property (to specify the texture) and "'''Enable Texture Light''' ''(bTexLight)''" (to enable the feature). |
| {{I|SetColorLight|param=color255|Change light's color value. Doesn't affect the godrays.}}
| |
| {{I|SetIntensityForLight|param=float|Change light's intensity value. Doesn't affect the godrays.}}
| |
| {{I|TurnOnGodRays|param=void|Turn the godrays on.}}
| |
| {{I|TurnOffGodRays|param=void|Turn the godrays off.}}
| |
| {{I|TurnOn|param=void|Turn the light on.}}
| |
| {{I|TurnOff|param=void|Turn the light off.}}
| |
| {{I|Toggle|param=void|Toggle the light's current state.}}
| |
|
| |
|
| ==Shadow filtering==
| | This game used lightcookies mainly for fake shadowmaps and cautists. They are used for some entities by default ([[Item battery (Black Mesa)|batteries]] and grunt pods for example). |
| 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 texture|projected textures]] in {{portal2|4}}.
| |
| <gallery mode=packed heights=410px>
| |
| File:shadowfilter_old.jpg| frame |Barney's hand with old shadow filtering.
| |
| </gallery>
| |
| 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.
| |
| <gallery mode=packed heights=410px>
| |
| File:shadowfilter_new.jpg| frame |Barney's hand with new shadow filtering.
| |
| </gallery>
| |
| 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 {{hl2|4}}. It is worth noting that such thing exists in more modern engines ([https://en.wikipedia.org/wiki/Unreal_Engine 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.
| | <gallery mode=packed heights=290px> |
| <gallery mode=packed heights=310px> | | File:lightcookie0.jpg |Lightcookie is disabled. |
| File:shadowfilter_new1.jpg| frame |The noise example. | | File:lightcookie1.jpg |Lightcookie is enabled. |
| </gallery> | | </gallery> |
| {{note|It is not entirely clear which term is correct, '''PCSS''' or '''PCCS''', since it could be orgography, but it is possible (though unlikely) that they created their own filter.}}
| |
|
| |
|
| ==Static shadow maps== | | Lightcookies are disabled with 2 ('''Low''') value for {{cmd|nr_shadow_quality}} ('''Dynamic Shadow Quality'''). |
| If our light source remains in the same position and never changes it, we expect that shadows from world geometry, [[displacement]], {{ent|prop_static}} and even [[bmodel|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.
| | ===Texture mask=== |
| | The texture mask defines which pixels will display the lighting and also affects their color. Black pixel color will not render the light at all, white will render the light and its color value, other colors (red, blue, yellow, etc.) will be mixed with the light color value, depending on their intensity and how close they are to white. Alpha channel doesn't affect anything, so make sure you don't use it in your texture. |
|
| |
|
| 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).
| | Point lights requires "Environment Map" texture to work with lightcookies, because point lights are using 6 separate faces, so each face requires separate texture. Follow [[$envmap#Creating_a_custom_static_cubemap_texture|these steps]] to create "Environment Map" texture. |
|
| |
|
| 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).
| | Spot lights can use any texture basically. |
|
| |
|
| 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.
| | It is recommended to use '''No Mipmap''' and '''No Level Of Detail''' flags for your [[VTF]] file, so the texture will not cause aliasing issues. |
|
| |
|
| Important to note that bmodels are also in static shadows maps, including {{ent|func_physbox}}, {{ent|func_door}}, {{ent|func_breakable}}, etc. This is true, despite the fact that such objects can be removed or moved. Most likely this is due to {{ent|func_detail}}, 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 {{ent|propper_model}} setting and brush replacing, but this will also save performance and solve the problem.
| | <gallery mode=packed heights=290px> |
| | | File:lightcookie_aliasing.jpg |Two point lights with two different lightcookie textures. The left don't use the flags, unlike the right texture. |
| ==Shadow map slots==
| |
| Shadow map slots is how many lights with shadows you can have per level. There are 3 separate shadow map slots, <code>High</code> (for lights with <code>1024</code> value for <code>ShadowMap LOD</code> property), <code>Medium</code> (for lights with <code>512</code> value for <code>ShadowMap LOD</code> property) and <code>Low</code> (for lights with <code>256</code> value for <code>ShadowMap LOD</code> property).
| |
| | |
| In <code>High</code> and <code>Medium</code> you can have 48 separate shadow maps, for <code>Low</code> 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 <code>ShadowMap LOD</code> 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 <code>ShadowMap LOD</code> 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 <code>ShadowMap LOD</code> 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 <code>Kill</code> input. So, you can place triggers which will <code>Kill</code> lights that player can't see and spawn new lights via {{ent|point_template}} (uncheck the second flag for {{ent|point_template}}, 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.
| |
| <gallery mode=packed heights=410px> | |
| File:manyshadowslotsbugg.jpg| frame |The bug example. | |
| </gallery> | | </gallery> |
|
| |
|
| It looks like you can workaround it if you will switch <code>ShadowMap LOD</code> property values from higher to lower.
| | {{important|Lightcookies are not using [[VMT]] materials, you only need texture.}} |
|
| |
|
| {{tip|You can use {{command|nr_debug_print_shadow_slots_info}} to get full info about shadowmap slots.}}
| | ===Animation=== |
| | Spot lights also support 2 different animation types, which allow you to animate a texture in two different ways. |
|
| |
|
| ==Lighting behavior with [[VIS]] and [[areaportals]]== | | ====Texture Cookie FPS==== |
| ===Static type===
| | {{todo}} |
| 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]].
| |
| <gallery mode=packed heights=410px>
| |
| File:staticlight_0.jpg| frame |Areaportal is open.
| |
| File:staticlight_1.jpg| frame |Areaportal is closed.
| |
| </gallery>
| |
| ===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.
| |
| <gallery mode=packed heights=410px>
| |
| File:stationlight_0.jpg| frame |Areaportal is open.
| |
| File:stationlight_1.jpg| frame |Areaportal is closed.
| |
| </gallery>
| |
|
| |
|
| In some cases, this can be noticeable if dynamic model creates a large shadow.
| | ====Texture Cookie Scroll Mode==== |
| <gallery mode=packed heights=410px>
| | In this mode, lightcookie texture can scroll in X and Y directions. This feature can be enabled with '''Tex Cookie Scroll Mode''' (''bTexCookieScrollMode'') property. |
| 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.
| |
| </gallery>
| |
| With {{command|mat_wireframe|1}}.
| |
| <gallery mode=packed heights=410px>
| |
| File:thewireboxshadow_0.jpg| frame |Areaportal hides the box.
| |
| File:thewireboxshadow_1.jpg| frame |Areaportal shows the box.
| |
| </gallery>
| |
|
| |
|
| ===Dynamic type===
| | X direction controlled by '''ScrollSpeedU''' (''fScrollSpeedU'') property. Y direction controlled by '''ScrollSpeedV''' (''fScrollSpeedV'') property. Both takes a float value. The default X direction is left, Y is up. Using a value multiplied by -1 will reverse direction, this allows you to use 8 different scroll directions. 0 means don't move in this direction. The size of the value affects the scroll speed. |
| 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.
| |
| <gallery mode=packed heights=410px>
| |
| File:dynlight_0.jpg| frame |Areaportal is open.
| |
| File:dynlight_1.jpg| frame |Areaportal is closed.
| |
| </gallery>
| |
|
| |
|
| ===Player spawn and areaportals===
| | Here is the [https://youtu.be/FkUFF6CLTq8 video] showcase of all 8 directions and how the feature look like. |
| If player spawned in position where areaportal don't hide objects - shadows will be fine. Otherwise, static shadowmap will not see models with [[bmodel|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.
| |
| <gallery mode=packed heights=410px>
| |
| File:psaa_0.jpg| frame |Player spawned in position where areaportal don't hide objects. The columns are {{ent|func_detail}}, the pipes are {{ent|prop_static}}.
| |
| File:psaa_1.jpg| frame |Player spawned in position where areaportal hide objects. Note that the columns and pipes don't have any shadows.
| |
| </gallery>
| |
|
| |
|
| ==Lighting behavior with start/end fade dist for prop_static== | | ==Shadow filtering== |
| 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.
| | 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 texture|projected textures]] in {{portal2|4}}. |
| ===Static type===
| |
| If player spawns in fade radius - shadows will never disappear (until save reload if out of radius).
| |
| <gallery mode=packed heights=410px> | | <gallery mode=packed heights=410px> |
| File:fadepropstaticlight_1.jpg| frame |In radius. | | File:shadowfilter_old.jpg| frame |Barney's hand with old shadow filtering. |
| File:fadepropstaticlight_0.jpg| frame |Out of radius.
| |
| </gallery> | | </gallery> |
| If player spawns out of radius. - shadows will never appear (until save reload in radius).
| | 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. |
| <gallery mode=packed heights=410px> | | <gallery mode=packed heights=410px> |
| File:fadepropstaticlight_3.jpg| frame | | | File:shadowfilter_new.jpg| frame |Barney's hand with new shadow filtering. |
| </gallery> | | </gallery> |
| The same for props with both Start and End fade dist.
| | 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 {{hl2|4}}. It is worth noting that such thing exists in more modern engines ([https://en.wikipedia.org/wiki/Unreal_Engine Unreal Engine 5] for example), so you can ignore the noise if it's not very noticeable, especially on shadows with high quality. |
| ===Stationary type===
| |
| The above mentioned issues are also available for this type. | |
|
| |
|
| Appears issue for prop_static with both Start and End fade dist.
| | 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. |
| | |
| 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).
| |
| | |
| <gallery mode=packed heights=210px>
| |
| 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.
| |
| </gallery>
| |
| | |
| ===Dynamic type===
| |
| Dynamic type don't use static shadowmaps at all. This means that there is no problems with fading prop_static at all.
| |
| {{important|All the issues is also available for {{ent|func_lod}}.}}
| |
| ==Godrays Implementation==
| |
| ===Implementation===
| |
| Godrays in this game are based on [[Sprite|sprite]] entities. They are a post-processed 2D plane that always turns to player's camera. The size of such plane is consistent with the screen size making it appear larger at a distance, in comparison to the world, similar to how '''Glow''' render mode works for {{ent|env_sprite}}, but unlike the render mode, such plane are rendered so that the sprite will cut through any surrounding geometry, similar to how '''Additive''' render mode works for {{ent|env_sprite}}.
| |
| <gallery mode=packed heights=210px>
| |
| File:grandsprite_0.jpg| frame |Sprite.
| |
| File:grandsprite_1.jpg| frame |Godrays.
| |
| </gallery>
| |
| This plane is also not affected by VIS, which means that you will always see it, even if your area in which your light source is located is closed by an areoportal.
| |
| <gallery mode=packed heights=290px>
| |
| File:cRaysDraw.jpg| thumb | left | 510px |
| |
| </gallery>
| |
| Such implementation has several consequences that limits amount of cases when you can use it.
| |
| ===Limitations And Use Tips===
| |
| Local point light godrays can "leak" (example on the pictures), since nothing limits the rendering and the size of the plane. The only you can do is place triggers that will turn on/off godrays, but this also basically means you can't use godrays in multiplayer levels, because multiple players can be located in different places of your map (there is no way to disable godrays for each client separately).
| |
| <gallery mode=packed heights=310px> | | <gallery mode=packed heights=310px> |
| File:godraysleak0.jpg| frame | | | File:shadowfilter_new1.jpg| frame |The noise example. |
| File:godraysleak1.jpg| frame |
| |
| </gallery> | | </gallery> |
| Because godrays always turns to player's camera, make sure you are using this effect in areas where view angle for player is very limited. The reason is showed in this short video [https://youtu.be/YvhWpE_X4RU clip], note how battery stops processing at some moment.
| | {{note|It is not entirely clear which term is correct, '''PCSS''' or '''PCCS''', since it could be orgography, but it is possible (though unlikely) that they created their own filter.}} |
| <gallery mode=packed heights=310px>
| |
| File:godrayslimiting0.jpg| frame |Bad example, player's view angle is not limited, the player also can walk around in any direction. Both factors are making godrays leaking and bad clipping most of the time.
| |
| File:godrayslimiting1.jpg| frame |Good example, player can look at the godrays forwardly only. The player also can walk only back or forward in this area. Both factors making the godrays nice looking.
| |
| </gallery>
| |
| {{note|Everything mentioned here also applies to the disks.}} | |
| | |
| ==Dedicated [[ConVars]]==
| |
| {{varcom|start}}
| |
| {{varcom|nr_allow_hammer_nerfs|0|[[Integer]]|Allow new lights nerfs via {{ent|Newlights_gbuffersettings}} entity.
| |
| | |
| 0 - Disabled.
| |
| | |
| 1 - Allowed.
| |
| | |
| 2 - Enabled/Forced.
| |
| }}
| |
| {{varcom|nr_allow_hammer_nerfs_4ways|0|Integer|Allow {{code|Enable4WaysFastPath}} property from {{ent|Newlights_gbuffersettings}} entity.
| |
| | |
| 0 - Disabled.
| |
| | |
| 1 - Allowed.
| |
| | |
| 2 - Enabled/Forced.
| |
| }}
| |
| {{varcom|nr_shadow_max_passes_per_frame|16|[[Float]]|Frame per second in shadowmaps. The higher the value, the smoother and faster the shadows from objects can change. The recommended value is 24-28, not higher.
| |
| {{important|The game can change its value independently, depending on the number of shadowmaps in frame. The game returns to the previous value if the number of shadowmaps decreases.}}
| |
| {{bug|hidetested=1|'''"End Game"''' chapter crashes with 29 and higher values.}}}}
| |
| {{varcom|nr_shadow_quality|4|Integer|Sets shadow quality and enable/disable shadows for all or certain objects. Controlled by '''Dynamic Shadow Quality''' option. Only 5 values are available here.
| |
| | |
| 0 (Disabled) - Shadows and lightcookies are completely disabled.
| |
| | |
| 1 (POTATO) - Shadows are available for world geometry and displacements, only for '''Static''' and '''Stationary''' light types. The shadows are very pixelated. The player's flashlight also gets very simple shadows with "stairs".
| |
| | |
| 2 (Low) - Added brush entities and static props in shadowmaps, only for '''Static''' and '''Stationary''' light types. Enabled lightcookies.
| |
| | |
| 3 (Medium) - All the shadows are also available for '''Dynamic''' light type.
| |
| | |
| 4 (Hight) - Added dynamic models in shadowmaps for '''Stationary''' and '''Dynamic'''.
| |
| {{note|This cvar needs save reload to see changes.}}}}
| |
| {{varcom|mat_unlock_gfx_highend_unsupported|0|[[Bool]]|When enabled this convar will unlock extreme graphics options. There will be a significant FPS drop when running game on ULTRA or INSANE configs. Game will consume upto 3 gigs of VRAM when some of the extreme graphics options have been enabled. These high end graphics config options are not officially supported. Don't enable this unless you have at least 3.5 GHZ quad core CPU with GTX 1080. These options are mainly for debugging and modders.}}
| |
| | |
| {{varcom|nr_lights_quality|4|Integer|Sets lights quality, state (for specific entities), enable/disable effects. Controlled by '''Dynamic Light Quality''' option. Only 7 values are available here.
| |
| | |
| 0 (POTATO) - Disabled muzzle flash light (regardless of {{command|muzzleflash_light}}), lighting from batteries (regardless of {{command|cl_battery_dlights}}), light sources from [[dynlightscript.txt]], dynamic lights are also disabled for some other entities. Halflambertion is disabled. New specular is disabled. Bumpmaps are disabled. Lights are disabled completely in secondary cameras (monitors, water, etc). Overlaying on viewmodel looks pretty broken. Light is not smoothed out (most noticeable in the least bright areas).
| |
| | |
| 1 (Low) - Allowed muzzle flash light, lighting from batteries, enabled light sources from [[dynlightscript.txt]], other dynamic lights are also enabled for some other entities. Enabled bumpmaps for models.
| |
| | |
| 2 (Medium) - Enabled bumpmaps for brushes. Lights in secondary cameras, but most effects is disabled.
| |
| | |
| 3 (Hight) - Halflambertion with new specular is enabled. Fixed overlaying on viewmodel. Light is smoothed out.
| |
| | |
| 4 (Very Hight) - Bumpmaps are also uncompressed, this makes lighting on surfaces more detailed.
| |
| | |
| 5 (INSANE) - All the effects is enabled in secondary cameras.
| |
| | |
| 6 (DevOnly) - This one for developers only. Includes uncompressed buffers and 32-bit depth. Don't use if you are general player or modder.
| |
| {{note|This cvar needs save reload to see changes.}}}}
| |
| {{varcom|nr_shadow_res|0|Integer|Affects the quality of shadows. Controlled by '''Dynamic Shadow Memory''' option. Only 4 values are available here.
| |
| | |
| 0 (Hight) - Hight quality.
| |
| | |
| 1 (Medium) - Medium quality.
| |
| | |
| 2 (Low) - Low quality.
| |
| | |
| 3 (POTATO) - Very low quality.
| |
| {{note|This cvar needs save reload to see changes.}}}}
| |
| {{varcom|nr_shadow_res_dkvk|0|Integer|It doesn't seem to work.}}
| |
| | |
| {{varcom|r_4way_minimal_mode_override|-1|Integer|Enable/disable bumpmaps for {{ent|Lightmapped_4WayBlend}}. Since one material of this shader provides 4 bumpmaps at once, disabling them will significantly affect performance.
| |
| | |
| -1/0 - Enabled.
| |
| 1/2 - Disabled.
| |
| {{note|This cvar needs {{command|mat_reloadallmaterials}} to see changes.}}}}
| |
| {{varcom|np_gr_quality|2|Integer|Enable/disable godrays. Controlled by '''God Rays''' option or '''Enable God Rays''' button (if used [[VGUI]]).
| |
| | |
| 0 - Disabled.
| |
| | |
| 1/2 - Enabled. 1 supposed to enable godrays only for {{ent|newLight_Dir}}, 2 for both point lights and {{ent|newLight_Dir}}, but currently both values enable both types.}}
| |
| {{varcom|np_gr_quality_sample_count|3|Integer|Amount of samples for godrays. This affects the quality/detail of the rays. Controlled by '''God Rays''' option, although the original game never changes the value (always 3). Min value is 0, max is 4. The max value is not recommended, it has a huge impact on frame rate, at the same time it does not create a big difference in the game.}}
| |
| {{varcom|np_gr_quality_pass_count|1|Integer|Pass count. Not very clear what exactly this affects, but it significantly reduces performance, and Fancy Rays also become pretty buggy. Controlled by '''God Rays''' option, although the original game never changes the value (always 1). Min value is 0, max is 4. Use the default value only.}}
| |
| | |
| {{varcom|nr_gbuffer_for_reflection_enabled|1|Bool|Enable/disable gbuffer for water reflections.}}
| |
| {{varcom|nr_gbuffer_for_refraction_enabled|1|Bool|Enable/disable gbuffer for refractions.}}
| |
| {{varcom|nr_gbuffer_for_secondary_cams_enabled|1|Bool|Enable/disable gbuffer for secondary cameras (monitors, etc).}}
| |
| {{varcom|nr_gbuffer_for_secondary_cams_quality|-1|Bool|New lights quality in secondary cameras and water reflections. With -1 it will use quality from {{command|nr_lights_quality}} cvar. With 0-5 it will use itown quality settings (in the same way as {{command|nr_lights_quality}}).}}
| |
| | |
| {{varcom|nr_shadow_filter_quality|2|Integer|Sets shadow filter quality. Min value is 0, max is 3.
| |
| | |
| 0 (POTATO) - Shadow filter disabled.
| |
| | |
| 1 (Medium) - Medium quality.
| |
| | |
| 2 (Hight) - Hight quality.
| |
| | |
| 3 (INSANE) - Best filter quality.
| |
| | |
| }}
| |
| | |
| {{varcom|nr_shadow_rad_Low|1.0|Float|Sets shadow filter quality scale for lights with 256 ShadowLOD value.}}
| |
| {{varcom|nr_shadow_rad_Med|1.5|Float|Sets shadow filter quality scale for lights with 512 ShadowLOD value.}}
| |
| {{varcom|nr_shadow_rad_Hight|1.5|Float|Sets shadow filter quality scale for lights with 1024 ShadowLOD value.}}
| |
| | |
| {{varcom|nr_shadow_biasoverwrite|0|Bool|Used by [[New Lights Editor]]. Allows/disallows to overwrite bias related values.}}
| |
| {{varcom|nr_shadow_nearz_overrite|-1.0|Float|Used by [[New Lights Editor]]. Changes NearZ value for all new lights.}}
| |
| {{varcom|nr_shadow_rad_override|0|Bool|Used by [[New Lights Editor]]. Allows/disallows to overwrite shadow radius related values.}}
| |
| {{varcom|nr_shadow_fov_overrite|-1|Float|Used by [[New Lights Editor]]. If the value of this convar is higher than -1 it will overrite FOV for shadowed lights.}}
| |
| {{varcom|nr_shadow_biasdepth|0.0002|Float|Used by [[New Lights Editor]]. Changes Depth Bias value for all new lights.}}
| |
| {{varcom|nr_shadow_biasnormaloffset|1|Float|Used by [[New Lights Editor]]. Changes Normal Bias value for all new lights.}}
| |
| {{varcom|nr_shadow_biasslope|0.2|Float|Used by [[New Lights Editor]]. Changes Slope Depth Bias value for all new lights.}}
| |
| {{varcom|nr_shadow_active|666|Integer|Sets max active shadowmaps. The value seems hardcoded.}}
| |
| | |
| | |
| {{varcom|nr_debug_print_shadow_slots_info||[[Void]]|Prints text to the console about shadowmap slots and their light sources.
| |
| | |
| It prints light type (point or spot) with their index, shadowmap enabled state (for each face), shadowmaps number, new light's targetname and position of it.
| |
| | |
| Below it also prints information about free shadowmap slots for each shadow resolution.
| |
| }}
| |
| | |
| | |
| {{varcom|nr_debug_force_shadowmap_res|-1|Bool|Only for debugging. Forces all new lights to use specified shadowmap resolution. -1 means use value from the property.}}
| |
| {{varcom|nr_debug_force_dynamic_on_all_stationary_lights|0|Bool|Only for debugging. Forces all stationary new lights to be fully dynamic and update even baked shadows.}}
| |
| {{varcom|nr_debug_force_lightstyle|0|Integer|Only for debugging. Forces all new lights to use specified appearance/light style. Possible values are 0-13. 13 for custom style from {{command|nr_debug_force_lightstyle_custom_string}}. 0 means use use value from the property.}}
| |
| {{varcom|nr_debug_force_lightstyle_custom_string|1|[[String]]|Only for debugging. Forces all new lights to use custom appearance/light style. Works the same as with lightmapped lights.}}
| |
| {{varcom|nr_debug_shadow_render_internal_disable|0|Bool|Only for debugging. Forces all new lights to disable shadowmaps rendering.}}
| |
| {{varcom|nr_debug_shadow_print_indices_assignment|0|Bool|Only for debugging. Prints text to the console about all new light sources and shadowmaps after level/save loading.}}
| |
| {{varcom|nr_debug_lights_mesh|0|Bool|Only for debugging. Enable/disable new lights mesh.}}
| |
| {{varcom|nr_debug_lights_mesh_fullscreen|0|Bool|{{todo|}}}}
| |
| {{varcom|nr_debug_light_mesh_volumesize_large|0|Bool|Only for debugging. Enable/disable new lights large mesh volume size mesh.}}
| |
| | |
| {{varcom|nr_debug_cull_deferred_lights|1|Bool|{{todo|}}}}
| |
| {{varcom|nr_debug_cull_deferred_code_lights_via_bsp|1|Bool|{{todo|}}}}
| |
| | |
| {{varcom|nr_dev_shoot_lights_enabled|0|Bool|Enable/disable point lights on each shoot. Only for player and only for bullet weapons. Shotgun can create several at once. Disappears after save reload.{{warning|Kills performance.}}}}
| |
| {{varcom|nr_dev_lights_quality_override|0|Bool|Enable/disable light quality override. Required for some cvars with {{code|nr_dev_}} prefix.}}
| |
| {{varcom|nr_dev_gb_debug_type|4|Integer|0 - DepthOnly. 1 - GBuffer_Fast 2 - GBuffer_Fast2. 3 - GBuffer_Fast3. 4 - Gbuffer_Slow.}}
| |
| {{varcom|nr_dev_gb_quality|2|Integer|Changes gbuffer quality.}}
| |
| {{varcom|nr_dev_lb_quality|1|Integer|0 is broken. 1 - default mode. 2 - debug materials with new specular.}}
| |
| | |
| {{varcom|nr_disable_setting_auto_reload|0|Bool|{{todo|}}}}
| |
| | |
| {{varcom|nr_fps_spam|0|Bool|For devolopers only. Spamming in the console performance values. Numbers aren't accurate.}}
| |
| | |
| {{varcom|nr_light_spot_bbox_optimizie|2|Intenger|Sets BBOX type for spot lights. Min value is 0, max is 3. There are note that 1 is broken. 3 makes BBOX size very small, so spot light sources will disappear even if they are in the player's field of vision.}}
| |
| {{varcom|nr_light_spot_mesh_volumesize_large|0|Intenger|This makes BBOX larger than it needs to be.}}
| |
| | |
| {{varcom|nr_lights_info||Void|Used by the game when you launch it. Prints in the console info about hardware support for texture formats, allocated formats and quality settings.}}
| |
| | |
| {{varcom|nr_lights_vol_check_threshold|10|Float|{{todo|}}}}
| |
| {{varcom|nr_light_settings_transition_exp|2|Integer|Affects the quality of the transition for changes from {{ent|newLights_settings}}. 0 - no transition. 1 - transition. 2 - smooth transition.}}
| |
| | |
| {{varcom|nr_lights_procedural_disable_all_lights|0|Bool|Disable all proceduraly created new lights ({{ent|npc_zombie_hev}}, {{ent|item_battery}}, weapons, etc).}}
| |
| {{varcom|nr_lights_procedural_enable_lights_priority_check|1|Bool|If enabled - all the code based procedural lights will go through priority based check before adding to render queue.}}
| |
| | |
| {{varcom|r_nr_deffered_debug_normals|0|Bool|Enable/disable normals debug.}}
| |
| {{varcom|r_nr_deffered_force_diffuse_only|0|Bool|Forces new lights to use diffuse texture only.}}
| |
| {{varcom|r_nr_deffered_lights_hlslclip_range_on|1|Bool|Enable/disable actual new light range in normals debug.}}
| |
| {{varcom|r_nr_deffered_lights_hlslclip_dir_on|0|Bool|{{todo|}}}}
| |
| | |
| | |
| {{varcom|r_nr_deferred_AA_fix_multiplier|1|Bool|Fixes anti aliasing issues.
| |
| | |
| :{{expand|title=Example|
| |
| <br>
| |
| <gallery mode=packed heights=500px>
| |
| File:deferred_AA_fix_multiplier0.jpg| thumb | left | 510px | Disabled.
| |
| File:deferred_AA_fix_multiplier1.jpg| thumb | left | 510px | Enabled.
| |
| </gallery>
| |
| }}
| |
| {{varcom|sv_ignite_light_mode|2|Integer|Sets fire light source availability for ignited objects. Min value is 0, max is 3.
| |
| | |
| 0 - Fully disabled.
| |
| | |
| 1 - Available for marines, doesn't work.
| |
| | |
| 2 - Available for all NPCs.
| |
| | |
| 3 - Available for everything, including physics objects and player.
| |
| | |
| }}
| |
| }}
| |
| | |
| {{varcom|end}}
| |
| {{note|Work in progress! It's not full list.}}
| |
| | |
| ==Bugs/Limitations==
| |
| See [[/Bugs and limitations]]
| |
| | |
| == See also ==
| |
| * {{ent|newLight_Dir}} - directional sun light with godrays only.
| |
| * {{ent|NewLights_Spawner}} - spawner of deferred point lights.
| |
| * {{ent|env_lensflare}} - cinematic dynamic lens flare.
| |
| * {{ent|newLight_Spot}} - spot deferred light entity.
| |
| * {{ent|newLights_settings}} - entity that changes deferred light settings.
| |
| * {{ent|godrays_settings}} - entity that changes godrays settings.
| |
| * {{ent|env_cascade_light}} - deferred cascade sun light entity.
| |
| * [[New Lights Editor]] - in game deferred lights editor.
| |
| * [[Effect flags]] - effects flags, some of them are dynamic light effects.
| |
| * [https://chetanjags.wordpress.com/2023/07/18/blackmesa-xenengine-part-4-lighting-shadows/ BlackMesa XenEngine: Part 4 – Lighting & Shadows] - page from Chetan (lead programmer for Black Mesa) about new lights.
| |
| * [https://chetanjags.wordpress.com/2023/07/11/blackmesa-xenengine-part2-how-a-frame-is-rendered/ BlackMesa XenEngine: Part2 – How a Frame is Rendered] - page from Chetan (lead programmer for Black Mesa) about how a frame is rendered.
| |
| * [https://chetanjags.wordpress.com/2022/06/01/blackmesa-xenengine-part1-a-heavily-modified-source-engine/ BlackMesa XenEngine: Part1 – Heavily Modified Source Engine] page from Chetan (lead programmer for Black Mesa) about {{xe|4}}.
| |