AnKi builds its Android shaders with a host binary you compile first

A small dependency list, borrowed from SDL

AnKi is an open source game engine for Linux, Windows and Android that runs on Vulkan, and the README makes a point of its dependency situation: a great effort was made to ease the building process, which is why the number of external dependencies is almost none.

The mechanism behind that claim is unusually concrete. Rather than listing its own dependencies, the README instructs Linux users to install libsdl2-dev or libsdl3-dev and states that AnKi has the same dependencies as SDL. One package installation covers the listed Linux development libraries.

The support matrix is small and explicit: Linux on x64 with Vulkan, Windows on x64 and arm64 with Vulkan and DX12, Android on arm64 with Vulkan. Nothing else is claimed, and macOS is not in the table despite being a common engine target.

The build system is CMake, and the project publishes per-platform CI badges for Linux and Windows. The repository layout is conventional: AnKi/ for the engine, Samples/, Tests/, Sandbox/, Tools/, ThirdParty/, EngineAssets/, Docs/ and CMakeLists.txt at the root, plus platform and language specific configuration such as.clang-format, a separate.clang-format-hlsl for shader code, AnKi.natvis for Visual Studio debugging and.luarc.json for the Lua language server.

Building on Linux, and what ccmake is for

The Linux prerequisites are CMake 3.15 or later, GCC 12 or later or Clang 18 or later, and the SDL development libraries. Get the source and configure a release build:

git clone https://github.com/godlikepanos/anki-3d-engine.git anki
cd path/to/anki
mkdir build
cd ./build
cmake .. -DCMAKE_BUILD_TYPE=Release
make

Build options are not meant to be discovered by reading CMakeLists.txt, and the README says so. Running ccmake in the build directory opens an interface listing every available option:

cd path/to/anki/build
ccmake .

One of those options is ANKI_BUILD_SAMPLES, which is on by default and is why four sample projects are built for you. The toolchain floor is worth noting: GCC 12 and Clang 18 are recent requirements, and a distribution with older compilers will need backports.

The Windows path is a standard Visual Studio generator build with CMake 3.10 or later, Python 3 or later with the interpreter on PATH, and Visual Studio 2022 with the Windows 10 SDK for Desktop C++ component. The generator is named explicitly:

cmake .. -G "Visual Studio 17 2022" -DCMAKE_BUILD_TYPE=Release
cmake --build . --config Release

Recent Visual Studio versions can also open the repository root as a local folder, and Visual Studio recognises the CMake project, populates the cache and lets you press build all.

Android needs a host build, and the reason is shaders

The Android path is the part that surprises people, and the README explains it properly rather than glossing over it.

You need Android Studio with the NDK and CMake installed from its package manager. You also need a completed host build of the engine on Linux or Windows. The reason is specific: the Android build requires the ShaderCompiler, or ShaderCompiler.exe, which is a host executable, so the host build is what produces it.

With the host binary in place, you generate a Gradle project per build target. For the Sponza sample on Linux:

cd path/to/anki
./Samples/Sponza/GenerateAndroidProject.sh path/to/Binaries/ShaderCompiler

On Windows the equivalent is GenerateAndroidProject.bat with the path to ShaderCompiler.exe.

The generated project lands in the repository root and is named after the sample, so the Sponza run produces a directory called AndroidProject_Sponza. From there you open it in Android Studio and build, debug and run it as an ordinary Android project.

That two-stage workflow is the honest cost of shipping precompiled shaders across a different GPU toolchain. A pipeline that compiled shaders on the Android side instead would avoid the host build, and this one does not.

Four samples, built by default, and how to run them

The samples are how you judge the engine, and they are not decorative. Four are built by default through the ANKI_BUILD_SAMPLES option.

Sponza is the Crytek scene, the standard reference environment for a renderer because it has known geometry and lighting. SimpleScene is a Cornell box, which is the smallest scene that still shows shadows and reflections. PhysicsPlayground is programmer art with physics interactions, which is how you check the physics integration. SkeletalAnimation is a scene with an animated skin, which exercises the skeletal path rather than static meshes.

Running them is a matter of executing the binary from any working directory:

./path/to/build/Binaries/Sponza

On Windows you run Sponza.exe. The README recommends running the samples from a terminal on both platforms, because the output prints information including possible errors, and that output is the first thing you want when a sample fails to bring up a window.

Two other repository directories tell you where the engine is expected to be exercised next. Tests/ is where the test suite lives, and Sandbox/ is the conventional scratch space for experiments. Tools/ holds the tooling, including the per-sample Android project generators.

Licence, contributing rules, and what is not here

The licence is BSD, and the README's interpretation is practical rather than legalistic: you can use the source or parts of it in proprietary and non-proprietary products as long as you follow the conditions. The repository metadata classifies the licence as one GitHub cannot categorise, so read the LICENSE file rather than relying on that field.

Contributing has one rule that matters and one that is optional. There are no special rules for small changes: open a pull request. For anything big, contact the lead maintainer before writing code, because the README states the project cannot accept that change upstream. There is also a code style guide at Docs/CodeStyle.md, and the request is to read it carefully.

The official website is anki3d.org and development news goes out through a Twitter feed at twitter.com/anki3d.

What is absent is as informative as what is present. There are no GitHub releases, so there is nothing to pin and no changelog to read, and the last push was on 2026-10-07 with the repository not archived. There is no asset editor, no scene editor and no build system for game content described in the README, so a game is assembled by writing or generating AnKi resource files rather than by clicking through a tool. There is no published compatibility statement for Android API levels or for Vulkan versions, and the samples are the only reference for what the engine does out of the box.

Editorial conclusion

AnKi suits a C++ developer who wants a readable modern renderer with a small dependency footprint and a Vulkan-first design, and who is willing to read Docs/CodeStyle.md before contributing. It is the wrong choice if you need a managed asset pipeline or editor, since the repository documents a sample-and-CMake workflow rather than a tool chain. Verify first that your platform is in the support matrix, Linux x64 or Windows x64 and arm64 with Vulkan and DX12 or Android arm64, and note the Android path needs a host build first to produce the ShaderCompiler before GenerateAndroidProject.sh can run.

Frequently asked questions

Official sources

1. godlikepanos/anki-3d-engine on GitHub
2. Issues
3. Project website
4. README