CS2 Update (Sep 24, 2026)

This update quietly lays groundwork for creators and tool users: a big expansion of Smart Props for level dressing, major overhauls to Vulkan and RTX shaders, and a flood of new developer-focused commands and convars for particles, audio, networking, and map tools.

Smart Props: A New Generation of Procedural Detailing

A large chunk of the update introduces an extensive Smart Props framework – a data-driven system for placing, deforming, and styling world props. This is primarily aimed at map and content creators, but it may ultimately translate into richer, more varied environments for players.

• Smart Prop root & variables:

  • New core types like CSmartPropRoot, CSmartPropElement, CSmartPropVariable, and CSmartPropChoice define full Smart Prop graphs with:
    • A content version, max graph depth, variables, choices, children, and modifiers.
    • Typed variables for floats, ints, vectors, and material groups (for choosing model material variants).
  • This suggests creators will be able to expose parameters (e.g. scale ranges, style choices) to quickly reuse and configure prop setups.

• Placement elements (lines, paths, grids, volumes):

  • CSmartPropElement_Layout2DGrid: lays out children in a configurable 2D grid with width, length, spacing, origin mode, and alternating shifts.
  • CSmartPropElement_PlaceOnPath and CSmartPropSelectionCriteria_PathPosition: place children along paths with spacing, offsets, coordinate spaces, and rules like “every Nth position” or only at start/end.
  • CSmartPropElement_FitOnLine and CSmartPropSelectionCriteria_LinearLength: distribute children along a line segment, with options for orientation, up direction, and length-based filters.
  • CSmartPropElement_PlaceInSphere: randomly or regularly distributes children inside or around a sphere or ring, with min/max count, radius, randomness, and alignment settings.
  • CSmartPropElement_PlaceMultiple: simply repeats a child element N times, optionally driven by an expression.
  • CSmartPropElement_PlaceOnMesh plus mesh-focused criteria (topology edge count, edge angle) target placement along mesh features.
  • This toolset appears designed to quickly populate areas with props like debris, foliage, clutter, or trim pieces following paths, surfaces, or volumes.

• Model-based Smart Props:

  • CSmartPropElement_Model and CSmartPropElement_ModelEntity define model-based elements with:
    • Model name, material group, detail-object flag, scale (vector and uniform), LOD hints, surface property overrides, and shadow toggles.
  • CSmartPropElement_PropDynamic and CSmartPropElement_PropPhysics specialize this for dynamic and physical props, including deformable attachment/orientation modes and a m_bStartAsleep flag for physics props.
  • These classes should let creators swap between static, dynamic, and physics-based versions of the same prop without redoing layout logic.

• Transform operations (moving, rotating, scaling):

  • Direct transforms:
    • CSmartPropOperation_SetPosition / Translate: set or offset positions; coordinate space is configurable (world/element).
    • CSmartPropOperation_SetOrientation: orient elements using forward and up vectors, with an option to prioritize up.
    • CSmartPropOperation_RotateTowards: rotate from an origin toward a target (with weight and coordinate space controls).
    • CSmartPropOperation_ResetRotation: selectively clear pitch, yaw, and roll, with an option to ignore object rotation.
  • Interaction widgets:
    • CSmartPropOperation_CreateRotator: create a rotator handle with offset, axis, snapping, limits, and color.
    • CSmartPropOperation_CreateSizer: define a 3D sizing box (min/max X/Y/Z) that outputs min/max variables and can display a preview model.
    • CSmartPropOperation_CreateLocator: define movable/rotatable/scaleable locators with offsets and display scale.
  • Randomization:
    • CSmartPropOperation_RandomOffset, RandomRotation, and RandomScale: add bounded random transforms with snap increments.
  • These operations indicate a node-graph-like authoring workflow where designers can chain deterministic and random steps to get variation from shared logic.

• Deformers and advanced spatial logic:

  • Deformers:
    • CSmartPropElement_BendDeformer: bends geometry within a box, with origin, angles, size, bend angle, bend point, and bend radius.
    • CSmartPropElement_MidpointDeformer: defines a deformation region between two points with radius, offset, spline continuity, angles, scale, and falloff.
  • Trace-based operations:
    • Base CSmartPropOperation_Trace stores an origin, origin space, origin offset, surface-up influence, “no-hit” behavior, and ignore flags for sky, nodraw, translucency, models, entities, and cables.
    • TraceInDirection: cast along a direction with a specified length.
    • TraceToPoint: trace from an origin to a target point, with optional “trace away” and max length.
    • TraceToLine: trace toward a line defined by endpoints A/B, each with their own coordinate space.
  • Together, these likely allow props to “conform” to level geometry (matching slopes, walls, edges) in a data-driven way.

• Vector math and geometry helpers:

  • ComputeVectorBetweenPoints3D, ComputeDistance3D, ComputeNormalizedVector3D, ComputeDotProduct3D, ComputeCrossProduct3D, and ComputeProjectVector3D (including plane projection mode) provide simple math nodes.
  • SaveDirection stores predefined directions (e.g. forward) in variables.
  • These nodes are aimed at creators who want fine control over orientation and alignment without scripting.

• Color and material operations:

  • CSmartPropOperation_MaterialTint: pick a specific color or gradient location to tint a material, with modes for color selection.
  • CSmartPropOperation_SetTintColor and RandomColorTintColor: choose between discrete color choices or a gradient, with support for random or specific selection and ApplyColorMode_t for how color is applied (like multiply object color).
  • CSmartPropOperation_SetMateraialGroupChoice: set material group selections via variable choices and selection modes.
  • CSmartPropOperation_MaterialOverride: apply per-material replacement overrides, with an option to clear existing overrides.
  • Filters for placement like CSmartPropFilter_MaterialAttributes and CSmartPropFilter_SurfaceProperties allow including/excluding surfaces by attributes or surface property names.
  • This all points toward a system where the same base prop can appear with different skins, tints, or surface treatments based on context.

• Selection criteria & filters:

  • Path position & line length criteria (PathPosition, LinearLength) help control which placements along a path/line actually spawn elements.
  • Mesh criteria:
    • TopoEdgeCountCriteria: filters mesh edges by open-edge count (topology-based), with invert options.
    • EdgeAngleCriteria: filters by angle ranges, again with invert support.
  • These criteria suggest authors can, for example, only place trim on certain types of edges or only every Nth segment along a path.

• Smart Prop composition & nesting:

  • CSmartPropElement_Group: a basic group that holds child elements.
  • CSmartPropElement_SmartProp: instantiates another Smart Prop (referenced by resource name) with an option for local evaluation state.
  • This modularity likely makes it easier to build libraries of reusable detail systems.

For players, these are all under-the-hood systems, but they may translate into maps with more dynamic, consistent, and varied environmental detail, particularly in future content drops or Workshop creations.

Hammer, Modeldoc, and Tooling Improvements

The update also touches multiple Source 2 tool modules, mainly around editing and visualization workflows.

• New tool module metadata:

  • Added module metadata files for tools_postprocessingeditor, tools_sfm, assetrename, toolframework2, tools_subrecteditor, toolscenenodes, modeldoc_utils, physicsbuilder, propertyeditor, helpsystem, and vrad3.
  • These metadata entries list new tool-side classes like CBindableCamera, CGlobalHotkeyCommands, CLightingControlRig, CQToolSceneWidget, CQCurveEditorWidget, and CQHelpEditorWidget.
  • This suggests continued investment in internal editors (post-processing, SFM, model tools, etc.), which should help Valve and advanced modders iterate more quickly on visuals and animations.

• Hammer-specific convars and commands:

  • Numerous hammer_ convars cover grid behavior, gizmo size, isosurface settings, Dota-specific path painting, gridnav previews, worklight parameters, SSAO toggles, terrain updates, vertex normal painting, and more.
  • Commands like hammer_bake_cubemap_debug_colors, hammer_save_gridnav, hammer_dota_rebuild_paths, and GPU preview lighting/raytracing toggles extend Hammer’s baked lighting and navigation workflow.
  • These changes indicate a deeper integration between CS2’s rendering pipeline and the editor (including RTX-based baking and visualization).

• Model and physics utilities:

  • mesh_trace_data_memory_report, print_model_bind_pose, reload_model, phys_get_model_materials, and phys_set_model_materials provide more diagnostics and control for model skeletons and physics surface properties.
  • Combined with Smart Prop material group variables, this likely helps keep models, physics, and materials in sync.

For Workshop mappers and advanced tool users, this update appears to improve the performance and ergonomics of creating and baking complex CS2 environments.

Vulkan, RTX, and Shader Overhauls

A very large number of changes land in Vulkan shader code and ray-traced lighting.

• Core engine shaders:

  • Many files in game/core/shaders_vulkan_dir/shaders/vfx were updated, including:
    • rtx_pathtracer, rtx_default_hitgroup, rtx_vrad3_lightmap, rtx_vrad3_vertexlight, rtx_vrad3_farfield, rtx_vrad3_farfield_metrics, and utilities for raytraced lightmap sampling and marking occupied space.
    • General-purpose shaders like spritecard, generic, refract, sky, SSAO, bloom, shadowing, wind, skinning compute, aggregate culling, and various debug visualizers.
  • This points to broad iteration on both real-time and baking pipelines—especially around RTX lightmap solutions and far-field lighting.

• CS2-specific material shaders:

  • game/csgo_core/shaders_vulkan_dir/shaders/vfx updates include:
    • Materials like csgo_lightmappedgeneric, csgo_vertexlitgeneric, csgo_character, decals, water, unlit materials, beach foam, various tool materials, and composition/generic material combiners.
  • game/csgo/shaders_vulkan_dir/shaders/vfx sees changes to:
    • Weapon and glove shaders, complex/environment/environment_blend materials, foliage, static overlays, glass, eyeballs, smoke volumes, skyboxes, effects, outlines, bloom, depth-of-field, sniper scope, grenade camera, UI textures, and multiple post-processing passes.

• RTX-specific tuning:

  • The vrad3 module adds references to materials/dev/vrad3/farfield_metrics.vmat and farfield_raytrace.vmat, indicating new dev materials for path-traced lighting metrics and far-field raytrace visualization.
  • New RTX convars:
    • rtx_allow_blas_compact and rtx_allow_blas_create control bottom-level acceleration structure creation and compaction.
    • rtx_perf_stats and rtx_show_bounce report or isolate specific bounces in path-traced views.
  • These should help Valve and technical creators profile and refine ray-traced lighting, which may translate into more stable and efficient RTX features over time.

• Vulkan memory and pipeline controls:

  • New or updated renderer convars include:
    • r_allow_low_gpu_memory_mode: permit low-GPU-memory operation (especially relevant for map builds or low-end setups).
    • r_memory_aliasing, r_vma_defrag_enabled, r_vma_defrag_algorithm, r_vma_defrag_threshold_mb, and several r_vma_defrag_* knobs for GPU memory defragmentation.
    • r_vulkan_accurate_renderarea: toggles more precise render pass regions vs. using render-target size.
    • r_vulkan_sw_cmd_lists: enables “software command lists” for Vulkan.
    • Debug and stats commands like vulkan_framebuffermgr_print, vulkan_memgr_print, vulkan_memgr_fragmentation_print, vulkan_pipelinemgr_print, vulkan_shader_table_print, vulkan_vma_defrag, and vulkan_vma_gpu_mem_dump.
  • While these are developer-facing, they suggest ongoing work on GPU memory stability and performance, likely improving hitching and VRAM usage in demanding scenes.

Players may not see an immediate visual toggle from these changes, but over time they are likely to improve performance, especially with ray tracing and complex particle-heavy scenarios.

Particle System Controls and Debugging

Particles receive a notable expansion of configuration options and debugging tools.

• Client particle behavior (cl_ convars):

  • cl_particle_batch_mode, cl_particle_fallback_base, cl_particle_fallback_multiplier, cl_particle_max_count, cl_particle_retire_cost, cl_particle_sim_fallback_base_multiplier, cl_particle_sim_fallback_threshold_ms, and cl_particle_simulate are updated or repurposed with clearer semantics:
    • Base/multiplier/threshold control when systems fall back to cheaper effects and how aggressively.
    • cl_particle_newinit enables an optimized initialization path.
    • cl_particle_log_creates and cl_particle_create_duplicate_work_for_profiling support profiling/debug.
  • These controls are marked as development/cheat in many cases, so typical players won’t touch them—but they enable better tuning of particle performance under load.

• Renderer particle controls (r_ convars):

  • A long list of new r_particle_* convars covers:
    • Cables: culling, bounds, dynamic roundness, meshlet rendering, shadow casting, and debug visualization.
    • Debugging: filters, forced sleep/awake simulation, showing attributes, control points, rope segments, sort positions, and random seed behavior.
    • Performance: fast-path enabling, explicit fetch, GPU implicit simulation modes (r_particle_gpu_implicit*), max detail level, max draw distance, culling sizes, texture layers, min timestep, mixed-resolution view starts, and model-per-thread counts.
    • Testing: r_particle_render_test, r_particle_warn_threshold_ms, and r_particles_memset_at_init help measure overhead and catch regressions.
  • r_freezeparticles is now a cheat with a clear description (“Pause particle simulation”), and r_drawparticles / sc_particle_debug_visualizer have menu-bar hooks.

• Particle-centric commands:

  • New commands like dumpparticlelist, particle_profile, particle_profile_spike, particle_reset_assertions, particle_stop_all, particle_stop_specified, and particle_stop_unspecified give fine-grained control over which systems run and how they’re measured.

These are mostly for Valve and technical creators, but they aim to keep smoke, fire, and other effects both stable and performant across a wide range of hardware.

Steam Audio and Spatial Sound Tuning

The Steam Audio integration gains a huge array of tuning, baking, and debugging controls.

• Reverb and HRTF controls:

  • snd_steamaudio_enable_reverb, snd_steamaudio_reverb_level_db, snd_steamaudio_reverb_order, snd_steamaudio_reverb_order_rendering, and snd_steamaudio_reverb_update_rate manage how detailed and how often reverb is simulated and updated.
  • HRTF-related options include:
    • snd_steamaudio_enable_custom_hrtf, snd_steamaudio_enable_ordertruncated_ambisonics_hrtf, snd_steamaudio_default_hrtf_volume_gain, snd_steamaudio_max_hrtf_normalization_gain_db, and snd_steamaudio_normalize_default_hrtf_volume.
  • These may lead to more consistent perceived loudness and directionality across different HRTF sets.

• Baking and probe systems:

  • Numerous snd_steamaudio_*bake* and *_probes_* convars control:
    • Numbers of rays, samples, bounces, and probes used when baking dimensions, occlusion, pathing, and reverb.
    • Whether compressed reverb lookup is used and which baked datasets (dimensions, materials, occlusion, pathing, reverb) are loaded.
    • Grid height spacing, max heights, and max ray lengths for dimension baking.
  • Diagnostics like snd_steamaudio_baked_data_stats, snd_steamaudio_diagnostic_baked_occlusion_single_probe, and various display/debug toggles help verify results.

• Occlusion and pathing:

  • Occlusion parameters include baked occlusion modes, pathing deviation slopes, reflection factors and regularization, air absorption coefficients, spatial filters, and probe lookup settings.
  • Pathing has options for caching (snd_steamaudio_pathing_enable_caching, snd_steamaudio_pathing_caching_threshold, snd_steamaudio_pathing_enable_source_probe_interp), rendering order, and validation.

• Runtime and editor integration:

  • Commands like snd_steamaudio_display_probes, snd_steamaudio_source_pathing_debug, snd_steamaudio_halton_sequence, and Hammer-related debug options indicate a tighter loop between map authoring and spatial audio tuning.

For players, these systems are mostly invisible, but they support more physically accurate and consistent soundscapes, particularly in complex indoor/outdoor transitions.

Input and UI Quality-of-Life

Several new input and UI-related convars and commands appear, some of which are relevant to normal players.

• Cursor and keyboard:

  • cl_auto_cursor_scale: automatic cursor size scaling.
  • cl_cursor_scale: manual cursor size scale factor.
  • cl_input_enable_raw_keyboard: toggle for raw keyboard input (bypassing OS-level adjustments), useful for players who want the most direct input path.
  • key_updatelayout: command to resync the game’s keyboard layout with the current OS layout.

• Gamepad and joystick:

  • cl_joystick_enabled: toggles joystick input globally.
  • joy_axisbutton_threshold: controls how far an analog axis must move to register as a button press.

• Misc UI/tooling hooks:

  • toolhud_enable and various graphcanvas_* convars are tool-side, but they reflect ongoing work on UI frameworks used by in-engine editors.

Players who rely on non-standard input setups or want precise cursor sizing may benefit from experimenting with these options once exposed through menus or config files.

Networking and Server Safeguards

Networking gets a broad set of monitoring and limiting tools, focused on robustness and debugging.

• Packet compression and logging:

  • net_use_packet_compression and net_compresspackets_minsize control whether and when packets are compressed.
  • net_filelogging, net_log_processing, net_detailed_canpacket_log, and net_showmsg/net_showreliable/net_showoob/net_showudp enable various levels of visibility into traffic.

• Server-side receive limits:

  • New safeguards like:
    • net_limit_sv_recv_max_message_size_kb.
    • net_limit_sv_recv_segments_per_packet.
    • net_limit_sv_recvbuffer_kb and net_limit_sv_recvbuffer_msg.
  • These limit how much data the server will accept from a single client, reducing exposure to abusive or buggy traffic.

• Per-client processing caps:

  • net_max_message_process_count and net_max_message_queue_size set upper bounds on how many messages are processed or queued per frame.
  • sv_net_client_message_process_time_ms_warn and sv_net_client_message_process_time_ms_drop warn or drop clients whose messages take too long to process.

• Diagnostic commands:

  • A family of net_* commands covers:
    • Connection and channel stats (net_channels, net_connections_stats, `net_status