# OGSR-Engine is an evolved X-Ray engine for the S.T.A.L.K.E.R. games > OGSR-Engine is a community continuation of the X-Ray engine, built in C++ for Visual Studio, with the stated aims of fixing original engine errors, improving and optimising graphics, updating engine components and adding developer features, and with separate branches for the Shadow of Chernobyl, Call of Pripyat and Clear Sky games. **OGSR/OGSR-Engine** — OGSR Project - Evolution of X-Ray Engine - Repository: https://github.com/OGSR/OGSR-Engine - Website: https://discord.com/servers/ogsr-508530704674455562 - Stars: 604 · Forks: 109 - Language: C++ - License: NOASSERTION - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/ogsr-ogsr-engine ## Four aims, stated plainly The OGSR project describes itself as the evolution of the X-Ray Engine, and it states its aims in four bullets: fix original engine errors, improve and optimize graphics, update engine components, and implement new features for developers. That list is short and it is the whole strategy. The X-Ray engine is the technology behind the original S.T.A.L.K.E.R. games, and it is famously capable and famously dated. Fixing errors means the crashes and the odd behaviours people remember, improving and optimizing graphics means bringing the rendering up to what a modern machine can do, updating engine components means replacing the parts that were frozen in 2006, and new features for developers means giving modders the tooling the original never had. None of this is a new engine. The value proposition is that the engine is known, the game data is known, and the community around it is large. A team that wants to fix a rendering problem in an existing game, or a modder who wants features the original engine could not offer, starts from working code rather than from scratch. The implementation language is C++, with cpp20 among the repository topics, and the platform is x64 Windows. There is no Linux or macOS build path in the documentation, which follows from the toolchain the project chooses. ## One repository, three games, two branches The repository carries a table of supported games, and the branch column is the part that matters operationally. S.T.A.L.K.E.R. Shadow of Chernobyl is built from the main branch. S.T.A.L.K.E.R. Call of Pripyat is built from main_cop_cs. S.T.A.L.K.E.R. Clear Sky is also built from main_cop_cs, and its release entry is marked as to be determined, which is the one place in the table where the project has not made a commitment. So there are two source branches for three games, and the same branch serves two titles. That is a sensible arrangement for an engine where the two later games share a codebase, and it does mean a fix made on main_cop_cs does not automatically exist on main. The release tags are numbered in a way that mixes two schemes, which is a small annoyance when you are trying to map a tag to a build. The recent ones are 3.558_CoP with the title 3.597_CoP on 2026-08-29, 3.548 with the title 3.596 on 2026-08-28, and 3.529 on 2026-06-14. The CoP suffix marks the Call of Pripyat line, and the tag name and release title differ, so a changelog entry can refer to a different number than the tag it came from. Expect to look twice when reading release notes. The releases themselves are built artefacts published on the repository's releases page, which is where a user who wants to play rather than build should go. ## Building on Windows, with pinned components The build requirements are the latest version of Visual Studio 2022 or 2026 with the Desktop C++ workload set up, and Git. There is no Linux path, and the build is a Visual Studio solution build rather than a scriptable command line build. The instructions are short. Clone the repository locally, run Update_Components.cmd to get the pinned versions of engine dependencies, open Engine.sln in Visual Studio, then set the platform to x64 and the configuration to Release and select Build and then Build solution. ```text * Run `Update_Components.cmd` to get pinned versions of engine dependencies * Open `Engine.sln` in Visual Studio * Set the platform to `x64` and the configuration to `Release`, then select `Build` -> `Build solution` ``` The updater step is the one that deserves attention, because it is what makes the build reproducible. The engine dependencies are not vendored at their current state; they are fetched at the versions the project has pinned, and the script is what performs that fetch. A build where that step is skipped, or run at the wrong moment relative to a branch switch, is the most likely source of a mismatch between your binary and the engine components it expects. There is a second script, cleanup.cmd, in the top-level entries, which by its name resets the working tree. In a repository that pulls in external components, having an explicit reset is the small piece of tooling that makes branch switching between main and main_cop_cs practical. ## What the tree contains, and where the graphics work lives The top-level entries describe a fairly conventional engine repository. There is a 3rd_party directory, a Game directory, the ogsr_engine directory that holds the engine itself, Engine.sln as the solution, OgsrBuildProps.props as the shared build properties, Update_Components.cmd and cleanup.cmd as the scripts, and LICENSE.md. The build properties file is the piece to look at if you are adding a module or a new compiler setting, because it is where the common configuration for every project in the solution would live rather than being repeated in each. The graphics direction is visible in the repository topics rather than in the README prose. They include d3d11, directx11 and dx11, which is the DirectX 11 renderer, along with dlss and fsr3, which are the two competing upscaling technologies, NVIDIA's Deep Learning Super Sampling and AMD's FidelityFX Super Resolution 3. There is also a x64 tag and the engine, game, gamedev and cpp tags. The README does not describe how the upscaling options are exposed in the game, whether they are toggles in a menu or build-time configuration, or how the DirectX 11 renderer relates to the original renderer. Those are the questions the wiki exists to answer, and the README points to it for the changelog and further information. For an engine whose headline is improved graphics, that is the first place to read. ## The credits reveal the lineage The acknowledgements section is longer than the build instructions, and it is more informative about the project. The names listed include Im-dex, SkyLoader, Shoker, vTurbine, solbjorn, abramcumner, ForserX, Xottab-DUTY and morrey, which are the individual contributors or mod teams whose work the engine builds on. Then there are the projects: OpenXRay's xray-16, the S.T.A.L.K.E.R. Anomaly Engine, the X-Ray Engine by Alpet and KD, and CoC-Xray. The addons listed are shader packs from ModDB, including Screen Space Shaders, Enhanced Shaders and Color Grading and Shader 3D Scopes, all from the Anomaly mod family. This is a map of the scene. The X-Ray engine has been forked many times, and each fork adds something. OpenXRay is a maintained continuation of the original X-Ray line, Anomaly is a separate monolithic engine, and CoC-Xray is the Call of Pripyat variant. OGSR draws on all of them, and the shader addons show that the graphics work has partly been done elsewhere and imported rather than reinvented. For a developer choosing between these projects, that list is the most useful thing in the repository. The differences between the forks are mostly about which upstream they track and which rendering extras they carry, and the credits list is where you find that out. ## Where the project talks, and what the licence says The homepage recorded for the repository is a Discord server, described in the badge as the official OGSR community, and that is where most of the conversation happens for a project of this kind. The rest of the channels follow the GitHub pattern. There is a wiki carrying the changelog and further information, an issues tracker for bug reports, and a discussions area for suggestions, questions and everything else. The README distinguishes the two explicitly, which is a small sign of a community that has settled into a working pattern rather than still figuring out where to post things. The licence is the part to read carefully. It is recorded as a custom licence that GitHub cannot classify, with a pointer to the LICENSE.md file at the root. For an engine that is distributed as a source repository and built by the user on their own machine, the terms that matter are what LICENSE.md says about redistribution of the engine and about the game assets it is designed to run, and the README does not restate them. This is a pointer to where the answer is rather than a legal opinion. The project is not archived and the last push was on 2026-10-11, so the tree is being worked on. The releases, though, are the practical artefact for most people, and the gap between the two is the usual pattern for an engine project: the source moves continuously, and the built versions land in the releases page when the maintainers decide a build is worth publishing. ## Conclusion OGSR-Engine fits a modder or a developer who wants to fix, extend and re-render the classic S.T.A.L.K.E.R. games on modern hardware, and who is prepared to work on Windows with Visual Studio and to track a per-game branch. It is the wrong choice if you want a finished game rather than an engine to build on, since the project is an engine and toolkit rather than a title, and it is the wrong choice if you cannot accept a build that requires the pinned component updater and a licensed copy of the original game assets. Before building it, read the wiki and changelog rather than the README, check which branch corresponds to the game you want, and read LICENSE.md, because the recorded licence is a custom one that GitHub cannot classify. ## FAQ ### What is OGSR-Engine? It is the OGSR project, an evolution of the X-Ray Engine, with the stated aims of fixing original engine errors, improving and optimizing graphics, updating engine components and implementing new features for developers. It is written in C++ for Windows x64. ### Which S.T.A.L.K.E.R. games does OGSR-Engine support? S.T.A.L.K.E.R. Shadow of Chernobyl is built from the main branch, while Call of Pripyat and Clear Sky are both built from main_cop_cs, with the Clear Sky release entry still marked as to be determined. ### How do I build OGSR-Engine? You need the latest Visual Studio 2022 or 2026 with the Desktop C++ workload and Git. Clone the repository, run Update_Components.cmd to fetch the pinned engine dependencies, open Engine.sln, set the platform to x64 and the configuration to Release, and build the solution. ### Does OGSR-Engine support modern upscaling? The repository topics include dlss and fsr3 alongside d3d11 and directx11, indicating work on DirectX 11 rendering and on the two upscaling technologies. The README does not describe how these options are exposed, so the wiki is the place to check the details. ### Where do I report bugs or ask questions in OGSR-Engine? Bug reports go in the GitHub issues tracker, suggestions and questions go in the discussions area, and the wiki carries the changelog and further documentation. The community itself is on the Discord server linked from the repository homepage. ## Sources - [Issues](https://github.com/OGSR/OGSR-Engine/issues) - [OGSR/OGSR-Engine on GitHub](https://github.com/OGSR/OGSR-Engine) - [Project website](https://discord.com/servers/ogsr-508530704674455562) - [README](https://github.com/OGSR/OGSR-Engine/blob/main/README.md) - [Releases](https://github.com/OGSR/OGSR-Engine/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ogsr-ogsr-engine