3Dmigoto: a DX11 modding wrapper you compile yourself

A DX11 wrapper born out of stereoscopic fixes

3Dmigoto started life as Chiri's wrapper for fixing broken stereoscopic effects in DX11 games, and the project now also presents itself as a general purpose DX11 modding tool. The repository is C++ and ships a Visual Studio solution named StereovisionHacks.sln, so what you get is source code that you compile yourself rather than a finished binary. That framing matters for anyone evaluating it. You are looking at a code base, not a product. The project sits in an unusual middle ground between an accessibility patch for VR and stereo displays on one side, and a general hooking layer for DirectX 11 titles on the other, and the same tree holds both identities. The project description also carries a warning that 3Dmigoto[.]com is a phishing site and not the project's own site, which tells you the author is thinking about how the tool is distributed and impersonated.

The Visual Studio 2022 build path

The setup instructions start with a specific toolchain rather than a package manager. You download VS2022 Community for Windows Desktop, install it, and select three components: the Visual C++ workload, the Windows 10 SDK (10.0.19041.0), and MSVC v143, which the notes say is currently using C++14. Cloning happens through the Git menu inside Visual Studio, with this repository URL:

https://github.com/bo3b/3Dmigoto.git

After the clone you make the new local repository the active one, open StereovisionHacks.sln from the home menu, wait for Solution Explorer to parse all the files, and press F7 to build the full solution. Every step here is Windows only. The project has been moved to Visual Studio 2022 Community so that development is free, which lowers the cost of getting a first compile, but there is no other supported environment described anywhere in the repository.

What lands in the x64 Debug build folder

The build output is written to a single location:

.\builds\x64\Debug

The files placed there are d3d11.dll, nvapi64.dll, d3dx.ini, uninstall.bat and a ShaderFixes folder. Two of those names explain the architecture. A d3d11.dll that sits next to an uninstall script means the wrapper is delivered as a drop in DirectX 11 component inside a game directory, and CopyToGames.bat at the repository root has a name that implies copying that payload into game installs. The ShaderFixes folder indicates the tool ships with a collection of shader patches as its working content. d3dx.ini points to ini based configuration, and the root of the tree backs that up: ini_parser_lite.cpp sits beside util.cpp, log.h and version.h, so configuration appears to be read through a small hand written ini parser rather than a heavyweight configuration library. A version.h at the root also suggests the build stamps its own version somewhere.

DirectX9 through DirectX11 and five shader compiler versions

The repository layout is wide. Alongside DirectX9, DirectX10 and DirectX11 directories there are D3DCompiler_39, D3DCompiler_41, D3DCompiler_42, D3DCompiler_43 and D3DCompiler_46, each a separate copy of a shader compiler for a different runtime generation. HLSLDecompiler and BinaryDecompiler sit next to them, and the tree also holds D3DCompiler, NVAPI, ThirdPartyLibs, Dependencies and a crc32c-hw-1.0.5 directory. The many compiler versions are the clearest sign that the wrapper deals with shader bytecode rather than only live HLSL, and the presence of both a decompiler for HLSL and one for binary blobs backs that reading. Supporting old shader compilers and older DirectX generations is exactly the kind of breadth that makes this a useful base for modding work across many titles. It is also the main maintenance cost, since each of those trees is another place where a runtime change has to be tracked.

A licence GitHub cannot classify

GitHub lists the licence as Other, which is its label for a custom licence the platform cannot categorise, and the pointer is to read the LICENSE file. The repository root also carries COPYING.txt and LICENSE.GPL.txt next to that LICENSE file, so the tree mixes at least two licence texts with the custom one. If you plan to fork 3Dmigoto, redistribute a build, or bundle it with a game mod pack, that ambiguity is the first thing to resolve. AUTHORS.txt in the same directory points to the attribution expectations the authors want, and the README credits Chiri explicitly for open sourcing the project. None of this is legal advice. The practical step is simply to read the LICENSE file before shipping anything, and to check which directories carry the GPL text if your distribution mixes them.

Release numbers that skip eight years

The version history tells its own story. The 1.2 series ended with 1.2.73 in June 2017, 1.3.16 shipped in January 2018, and 1.4.9 arrived as a pre release beta build in February 2026. Between the 1.3 release and the 1.4 beta there is a long quiet stretch, so the numbering reflects an irregular release pattern rather than a steady one. The repository is not archived and the last push was on 2026-09-06, so someone is still working in the tree, although a push date is not the same as a maintained release line. The project's own framing, that this is the developer version of the tool rather than the end user version, explains why the build step matters more here than the tag list. There is also no changelog file in the tree to explain what changed across those years.

Where the documentation stops

The README does not document how to author a shader fix, what syntax the ini files accept, how the injector decides which process to attach to, or how to roll back an installation. The directory structure implies more than one technique, with an NVAPI directory, a dedicated Injector directory and the D3DCompiler family, but no page explains how those parts connect to the d3d11.dll that ends up in the game folder. For a project whose stated audience is people fixing bugs, adding features and documenting how to use it, that gap is the real cost. The code is there, and the map of the code is not. Expect to spend time reading source before your first useful fix, and treat the ShaderFixes folder as examples to reverse engineer rather than as documented recipes.

Editorial conclusion

3Dmigoto suits developers who need to build their own DirectX 11 modding layer, particularly anyone working on stereoscopic or VR presentation problems inside a DX11 title. It is the wrong choice for end users who want a ready made package, and for teams that need documented configuration and predictable releases, since the setup instructions stop at the build steps and the tags jump from 2018 to a 2026 beta. Before committing, build StereovisionHacks.sln under Visual Studio 2022, read the LICENSE file, and check that the d3dx.ini format in your own build matches what the target game expects.

Frequently asked questions

Official sources

1. bo3b/3Dmigoto on GitHub
2. Issues
3. README
4. Releases