# Skyrim Community Shaders: a SKSE plugin that replaces Skyrim's rendering with HLSL shaders > Community Shaders is a C++ SKSE core plugin for Skyrim Special Edition and Anniversary Edition that swaps the game's own rendering for community written HLSL shaders, and it is built as a feature set you can package individually or as one all in one archive. The build chain is Visual Studio, CMake and vcpkg, and the licence is GPL-3.0 with a separate exceptions file. **community-shaders/skyrim-community-shaders** — Community-driven advanced graphics modifications for AE, SE and VR. - Repository: https://github.com/community-shaders/skyrim-community-shaders - Website: https://discord.com/invite/nkrQybAsyy - Stars: 1,136 · Forks: 208 - Language: C++ - License: GPL-3.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/community-shaders-skyrim-community-shaders ## What the plugin actually replaces in the game Skyrim Community Shaders is a SKSE core plugin for community driven advanced graphics modifications. The project description calls it community-driven advanced graphics modifications for AE, SE and VR. The topic tags name the technical surface: c-plus-plus, directx, game-engine, graphics, rendering, shaders, skse, skse64 and skyrim, with hacktoberfest, fun, learning and modding among the rest. The mechanism is a rendering replacement rather than an in-game settings panel. The plugin hooks into the game engine and swaps the shipped rendering for shaders written by the community, which is why the repository is a C++ codebase rather than a collection of loose shader files, and why the build produces a plugin package rather than a texture or configuration download. The SKSE part is the load order foundation. SKSE is the Script Extender for Skyrim, and the project ships both skse and skse64 in its topics, which covers the 32-bit and 64-bit forms. The user requirements section lists two mandatory pieces: Address Library for SKSE, needed for SSE and AE, and SSE Engine Fixes. Neither is optional, and both come from Nexus Mods, which is also where the project itself is published, at a mod page numbered 86492. There is a developer-facing wiki entry as well, on modding.wiki, under the Skyrim developers section for community shaders, and the repository links to a DeepWiki page as a badge. So the project is built to be read as well as used, which is a reasonable expectation for a codebase whose own documentation is spread across a wiki, a repository README and a Discord server, since the homepage for this project is a Discord invite rather than a website. ## The build chain: Visual Studio, CMake and a pinned vcpkg The requirements list is specific and unforgiving. You need a terminal of your choice, such as PowerShell, Visual Studio Community 2026 with the Desktop development with C++ workload plus CMake Tools for Windows and HLSL Tools, and Git, with the Git.exe install path added to the PATH environment variable. CMake and Vcpkg are listed as optional, with the note that CMake and Vcpkg come with Visual Studio in Developer Command Prompts already, and that you should install them manually only if you want them in everywhere. CMake 4.2 or newer is now required, and its cmake.exe path also goes on the PATH. For Vcpkg, the README says to install vcpkg using the directions in its Quick Start Guide, then add a new environment variable named VCPKG_ROOT with the value as the path to the folder containing vcpkg. That vcpkg instruction carries the sharpest warning in the whole document. Make sure your local vcpkg repo matches the commit id specified in builtin-baseline in vcpkg.json, otherwise you might get another version of a non pinned vcpkg dependency causing undefined behaviour. A graphics plugin whose behaviour depends on the exact version of a library is a difficult class of bug to debug, and the project is protecting you from it up front. The repository listing shows the build infrastructure: a CMakeLists.txt at the root, CMakePresets.json, a CMakeUserPresets.json.template, a cmake/ directory, vcpkg.json, an extern/ directory for submodules, a .gitmodules file, and a set of batch wrappers named BuildDebug.bat, BuildDev.bat, BuildDevFast.bat, BuildPR.bat and BuildRelease.bat. The .claude/ directory is worth noticing, since it holds the project instructions for AI tooling, and the README points to a specific section of .claude/CLAUDE.md for the detail on the packaging targets. The repository also carries AGENTS.md, a .coderabbit.yaml configuration, a .pre-commit-config.yaml, a .clang-format and a .clangd, so formatting, linting and pull request review are configured rather than left to convention. ## Two ways to build: open the folder or drive CMake presets There is a Visual Studio path and a command line path, and the README documents both. The Visual Studio path is short. Clone the repository with all submodules, then open the folder in Visual Studio and follow the prompts to Configure and Build: ```bash git clone https://github.com/community-shaders/skyrim-community-shaders.git --recursive cd skyrim-community-shaders ``` The recursive flag matters because the project uses git submodules through extern/ and .gitmodules, and a non-recursive clone gives you a build that cannot find its dependencies. The result of the Visual Studio build is an AIO package in the ./build/ALL/aio folder by default. Switching Solution Explorer into the CMake Targets View reveals optional targets that create zip packages per feature, and building one of those puts the zip in ./dist/. The command line path uses presets, and it requires you to open the Developer PowerShell for VS 2026 or the x64 Native Tools Command Prompt first, because those set up the Visual Studio toolchain for you. The README also advises that if you prefer to run the VC environment manually, launch Developer PowerShell or the x64 Native Tools prompt instead of calling vcvarsall.bat directly from PowerShell. From the repository root, three commands do the work: ```pwsh # Generate the build files (uses the ALL preset) cmake --preset ALL # Build using the preset cmake --build --preset ALL # Install an AIO package somewhere, e.g. $MOD_FOLDER cmake --install --preset ALL -- --prefix $MOD_FOLDER ``` The install step takes a prefix, so the AIO package can be dropped straight into a mod folder. The convenience wrapper BuildRelease.bat captures these steps, and it accepts a parameter naming the preset to configure, for example .\BuildRelease.bat ALL-WITH-AUTO-DEPLOYMENT. ## Feature level packaging and the two CMake options that matter Packaging is where this project differs from a typical build. The README lists the optional targets: AIO_ZIP_PACKAGE, Package-AIO-Manual, Package-Core, and Package-. ```pwsh # Create a AIO package in ./dist/ # Automated AIO zip (requires AIO_ZIP_TO_DIST=ON) cmake --build ./build/ALL --config Release --target AIO_ZIP_PACKAGE # Manual AIO package (install + tar) cmake --build ./build/ALL --config Release --target Package-AIO-Manual # Create a CommunityShaders core package in ./dist/ cmake --build ./build/ALL --config Release --target Package-Core # Create a feature package in ./dist/ (example: GrassLighting) cmake --build ./build/ALL --config Release --target Package-GrassLighting ``` The distinction between the two AIO targets is worth understanding. The automated AIO zip requires the AIO_ZIP_TO_DIST option to be on, while the manual package is an install followed by a tar. The difference between them, and the other options, is documented in the Manual packaging targets section of .claude/CLAUDE.md, which is a slightly unusual place to keep build documentation but tells you the project treats its agent instruction files as documentation proper. The per feature target, with GrassLighting given as the example, is the important one for anyone who does not want everything. The repository listing has a features/ directory, and a target exists for each feature, so a build can produce just the core plugin or just one shading feature. That granularity is what lets the project be used by people who want a single effect rather than a full graphics overhaul. Two CMake options are documented. AUTO_PLUGIN_DEPLOYMENT defaults to OFF, and you set it to ON in CMakeUserPresets.json, along with a CommunityShadersOutputDir value pointing at your desired outputs, where multiple folders are separated by a semicolon as shown in the template example. TRACY_SUPPORT also defaults to OFF, and enabling it turns on tracy support, with the caveat that you might need to delete the build folder when the option changes. A CMakeUserPreset example is available by copying CMakeUserPresets.json.template to CMakeUserPresets.json. The tracy option is the only profiler hook in the project, and it being off by default tells you the rendering path is not normally profiled. ## A containerised Windows build and a release pipeline The Dockerfile in this repository is unusual and tells you something about how the project is developed. It is a Windows container, not a Linux one, based on mcr.microsoft.com/windows/servercore:ltsc2022, with the shell set to cmd through PowerShell invocations. The build installs the toolchain from scratch. Chocolatey is installed and used to add curl, git and 7zip, plus cmake with the ADD_CMAKE_TO_PATH=System install argument. The Visual Studio Build Tools installer is then downloaded from the Microsoft URL and run silently, adding the Visual C++ tools component and the Windows 11 SDK 26100 component while removing the older Windows 10 SDK components and the Windows 8.1 SDK. The special case is handled, since a restart exit code is turned into a success. Then vcpkg is cloned and bootstrapped, and VCPKG_ROOT is set as a machine-wide environment variable. The container then creates C:\skyrim-community-shaders as its working directory and its entrypoint is a PowerShell script, containerbuild.ps1, which is also in the repository listing. The reason for this is the Windows toolchain. A shader plugin for a DirectX game needs the Windows SDK and the DirectX shader compiler, and reproducing that in a Linux container is not realistic. Building the toolchain inside a container is what makes the CI path possible at all, and the release workflow referenced in the Dockerfile comment,.github/workflows/release-docker-ghcr.yml, is the publishing side of the same arrangement. The release naming in the repository is worth noting. The three most recent release tags are v1.9.0-pr2931, v1.9.0-pr2930 and v1.9.0-pr2929, all on 2026-10-15, with release titles of the form Community Shaders 1.9.0 PR #2931. Every build is cut per merged pull request, which matches the presence of BuildPR.bat in the repository. The result is a very fine grained release history, useful for bisecting a shader regression, and a long tag list. The last push was on 2026-10-19 and the default branch is dev rather than main, which tells you where the active work happens. ## Licence, exceptions and the maintenance signals The licence is GPL-3.0, with a COPYING file at the root and an EXCEPTIONS.md alongside it. The exceptions file is the detail to read rather than skim, because the combination of a copyleft licence and a separate exceptions document is the mechanism by which a project of this kind grants additional permission over specific parts. The COPYING file is what the GPL-3.0 terms mean for redistribution of the plugin, and for a mod that people download and install rather than sell, the practical question is what you may do with a modified version and what you must publish. The README does not summarise this, so the two files are the source. The project is not archived and the last push was on 2026-10-19, so development is active. The release tags show per pull request builds, and the presence of a hacktoberfest topic alongside a.coderabbit.yaml badge tells you the project takes outside contributions and reviews them with automated tooling. Two more resources in the repository listing are worth noting. TRANSLATING.md indicates the project is localised, which for a shader plugin is mostly about the user interface strings and the menu, and the docs/ directory holds developer documentation. The Discord server is the project's homepage, so it is where announcements and support actually live, and the Nexus Mods page is where the user facing release is distributed. For anyone reading this to decide whether to build it, the honest summary is that this is an active, community run rendering platform with a real CI pipeline, per pull request releases and a per feature packaging model, but a heavy Windows-only build chain. The build is not a single click, and the result is a plugin that has to be installed into a modded Skyrim with SKSE, Address Library and SSE Engine Fixes already in place. ## Conclusion Skyrim Community Shaders fits a modder who wants to write or tweak HLSL for Skyrim's rendering pipeline and can accept a Windows toolchain, a SKSE dependency chain and a shader compilation step in the loop. It is the wrong tool if you are a player looking for a preset, since the repository is a development platform rather than an installer, and the wrong tool for other Bethesda engines, since the plugin targets SKSE and SSE. Before building, install Address Library for SKSE and SSE Engine Fixes, make sure your vcpkg checkout matches the builtin-baseline commit in vcpkg.json as the README warns, and check EXCEPTIONS.md and COPYING to understand what the GPL-3.0 grant covers in this codebase. ## FAQ ### How do I build Skyrim Community Shaders from source? Clone the repository with the --recursive flag so submodules come too, then either open the folder in Visual Studio 2026 and follow the Configure and Build prompts, or open a Developer PowerShell and run cmake --preset ALL, cmake --build --preset ALL and cmake --install --preset ALL -- --prefix $MOD_FOLDER. The result is an AIO package. ### What do I need installed before building Skyrim Community Shaders? Visual Studio Community 2026 with Desktop development with C++, CMake Tools for Windows and HLSL Tools, plus Git on the PATH. CMake 4.2 or newer is required, and vcpkg needs to be installed with VCPKG_ROOT pointing at its folder, matching the builtin-baseline commit in vcpkg.json. ### Can I build only one shader feature instead of the whole package? Yes. The optional CMake targets include Package-Core for the CommunityShaders core package and Package- for individual features, with GrassLighting given as the example. Building one of these puts the zip in ./dist/. ### What must be installed in Skyrim for Community Shaders to work? Address Library for SKSE, which is needed for SSE and AE, and SSE Engine Fixes. The plugin itself is a SKSE core plugin, and the mod is published on Nexus Mods. ## Sources - [community-shaders/skyrim-community-shaders on GitHub](https://github.com/community-shaders/skyrim-community-shaders) - [License: GPL-3.0](https://github.com/community-shaders/skyrim-community-shaders/blob/dev/LICENSE) - [Project website](https://discord.com/invite/nkrQybAsyy) - [README](https://github.com/community-shaders/skyrim-community-shaders/blob/dev/README.md) - [Releases](https://github.com/community-shaders/skyrim-community-shaders/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/community-shaders-skyrim-community-shaders