Horde3D, a small C++ 3D engine you build and link into your own application

An engine designed to stay small and call from any language

Horde3D is a 3D rendering and animation engine written in C++, and the stated goal is to keep it lightweight and conceptually clean. The audience is developers who want rendering capability inside an application they already control, not a ready made game. The API is C-style, which the project presents as making it usable from virtually any programming language, so a binding layer in another language is a realistic path in. The design also avoids dependencies where possible. Resource handling is part of the design rather than an afterthought: resources are garbage collected and can be loaded from virtually any type of data stream, which matters for toolchains that serve assets over a network or generate them on the fly. On top of that sits a full scene system and a low-level animation system, so the engine covers the path from asset to animated, lit frame.

The übershader pipeline is where the engine's flexibility lives

Rendering in Horde3D is organized around übershaders, a customisable pipeline that is central to the engine rather than an optional extra. Pipelines can be hot-reloaded, which is what makes it practical to try a different rendering technique while an application is running. The pipeline supports post processing effects such as bloom, depth of field and motion blur, and it covers almost all forward, deferred and High Dynamic Range techniques. Real-time reflections and other effects that need several cameras are supported, and the shader stage includes geometry, tessellation and compute shaders. Shadows come from Parallel Split Shadow Maps, and particle systems can cast shadows and carry motion blur effects. The trade-off is that the flexibility lives in shader code you write and maintain, so the ceiling of the engine is set by how much of the übershader approach you are prepared to learn.

One CMake configure step, then the generator of your choice

Building requires a C++14 compiler and CMake 3.14 or newer. CMake is a meta-build system, so it produces Makefiles or Visual Studio project files through a generator, and the documentation walks through the common ones. The command line path for Makefiles looks like this:

mkdir build-make && cd build-make && cmake -G "Unix Makefiles" .. && make

The documentation notes that exporting JOBS=MAX speeds the build up. For Xcode, create a build-xcode directory and generate with the Xcode generator, then open the generated project; for Ninja, use the Ninja generator and run ninja. On Windows the documented route is cmake-gui, or a command line equivalent that creates a build-vs directory, runs cmake with a Visual Studio generator and opens the resulting Horde3D.sln. One detail in that Windows paragraph looks like a copy and paste leftover, since it tells you to choose OGDF as the source path, which is not a Horde3D directory, so treat the source path as the repository root.

Sample dependencies are downloaded for you unless you say otherwise

The samples need a windowing library, GLFW above version 3 or SDL at 2.32.8 or newer, and if neither is present on the system a default version is downloaded, built and linked automatically. You can force that behavior with a CMake flag from your build directory:

cmake -DHORDE3D_FORCE_DOWNLOAD_GLFW=ON ..

The same pattern applies to SDL through HORDE3D_FORCE_DOWNLOAD_SDL. On Debian and Ubuntu you also need the development package for X11 headers:

sudo apt-get install xorg-dev

If you are only after the engine library and not the sample programs, you can turn the samples off:

cmake -DHORDE3D_BUILD_EXAMPLES=OFF ..

That flag is worth knowing on a build machine, since the automatic download and build of a windowing library adds a network dependency to an otherwise self-contained compile.

Android builds pair CMake with Gradle, and expect specific versions

Mobile support is not a single toolchain. The Android build requires two build systems, CMake and Gradle, and a Gradle project is included in the Horde3D distribution. The requirements listed are the Android NDK, the Android SDK and a Java runtime, and Android Studio is recommended but not required. The console path configures CMake with the NDK toolchain file, the ABI, the platform level and the GLES3 and SDL switches:

mkdir build_android && cd build_android
cmake -G "Ninja"   -DCMAKE_TOOLCHAIN_FILE=<path to android ndk>/build/cmake/android.toolchain.cmake   -DANDROID_ABI=arm64-v8a   -DANDROID_PLATFORM=android-27 -DHORDE3D_USE_GLES3=ON -DHORDE3D_USE_SDL=ON -DHORDE3D_FORCE_DOWNLOAD_SDL=ON -DANDROID_SDK_ROOT_PATH=<path to android sdk> -DANDROID_SDK_BUILD_TOOLS_PATH=<path to android sdk>/build-tools/36.0.0/  ..
ninja

The tested configuration is Ubuntu 26.04 with OpenJDK 21, NDK r27d and SDK 36, and the documented GUI route adds the same values as CMake entries. iOS is mentioned only in terms of the hardware requirement, so the mobile story is uneven: Android has concrete instructions and iOS does not.

Scene graph, animation and content formats in one engine

A unified scene system is one of the clearer design statements in the project. World, models and skeletons are scene nodes rather than special objects, and visibility is handled by frustum culling over a spatial graph plus hardware occlusion culling, with level of detail applied to model geometry and materials. The animation system is deliberately low-level: key frame animation for joints and meshes, skeletal animation with up to four weights per vertex for articulated models, layered blending and mixing through masks and additive channels, and morph targets for facial animation and lip synchronization. Joint data is exposed for dynamic animation and ragdoll physics, and vertex data is accessible for collision detection and physics interoperability. The content pipeline mixes formats on purpose, with pipeline, material and scene descriptions in XML, models and animations in binary, and textures in common image formats, plus a COLLADA converter for assets coming from common DCC tools.

The licence is unstated, and releases came far apart

Two things deserve a look before anyone builds on this. First, the licence is listed as unknown, so no MIT, BSD or Apache grant is visible, and the top-level file listing does not include a LICENSE file. For a project you intend to link into a product, that is a real blocker rather than a formality, and it is the first thing to check. Second, the release history is uneven. Version 2.0.1 shipped in October 2021 and version 2.0.2 in April 2022, and the next release, v2.1.0, only appeared on 2026-09-08. The repository is not archived and the last push was on 2026-09-09, so work is happening, but the gap between 2.0.2 and 2.1.0 spans years rather than weeks. The engine is old enough to be predictable and young enough to have just changed; whether that combination helps you depends on whether the version you depend on matches the one your dependencies expect.

Editorial conclusion

Horde3D fits teams that want a rendering and animation engine they can link directly into an existing C++ application, a single scene graph, and an übershader pipeline they can reload while the app runs, and it suits anyone who values a short dependency list over a built-in editor workflow. It does not fit a project that needs a turnkey editor, a physics stack, or a modern mobile toolchain beyond what the Android instructions describe. Before you commit, confirm the licence yourself, since it is listed as unknown and the top-level file listing shows no LICENSE file, and check that your target hardware clears the OpenGL 2.0 requirement, or OpenGL ES 3.0 on Android and iOS.

Frequently asked questions

Official sources

1. horde3d/Horde3D on GitHub
2. Issues
3. Project website
4. README
5. Releases