Skylicht Engine: a lightweight C++ engine descended from Irrlicht

What Skylicht Engine inherits and what it replaces

Skylicht Engine is described as an evolution of the Irrlicht Project, with upgraded features including the sound engine, the physics engine and the particle engine. The point of the fork, stated in the README, is a high-performance and lightweight game framework that works on both web and mobile platforms, and it is free to use.

The rendering backends are the concrete list of what was modernised. Direct3D 11, OpenGL 4+, OpenGLES 3+ and the Google Angle GLES video driver. Angle matters more than it first appears, because it is what makes the same GLES code path run in a browser, which is the web half of the stated goal.

The platform matrix is broad: Android, iOS, Win32 and Win64, UWP, Linux, macOS and HTML5. The render pipeline supports both forward and deferred rendering, and there is a lightmapper, a particle system and a GUI in the sample set.

The samples are the best evidence of the feature surface, and there are a lot of them. Samples cover Animations, Audio, BlendShape, BoidSystem and BoidSystemVAT, CharacterController, Collision, DrawPrimitives, GUI, Graph, HelloWorld, HttpRequest, HttpServer, Instancing and InstancingPointLight, Lightmap, LightmapUV, several Lightmapping variants including directional, vertex and per-light, LoadScene, LuckyDraw, Materials, Noise2D and Noise3D. A built-in HTTP server and client, a boids system, a blend shape system and lightmapping under several configurations are not things a minimal engine ships by default, so the sample set doubles as a feature list.

Cloning with Git LFS and building the asset bundle

The prerequisites are CMake 3.12 or higher, Python 3.x, and Visual Studio 2017 or higher if you are building on Windows.

The clone needs one extra step that trips people up. The README states that the project has used large files like .tga and .fbx for demo samples, so Git LFS must be installed, and the command to run after checkout is given.

git lfs pull

Without that, the sample assets are pointers rather than files, and the asset bundle step produces an empty or broken result.

The asset bundle is then built with a Python script in the Assets directory.

C:\skylicht-engine>cd Assets
C:\skylicht-engine\Assets>python BuildAssetBundles.py
C:\skylicht-engine\Assets>cd ..

The README then says to run CMake from the current directory to generate a Visual Studio project or an Xcode project, and gives the generator flags for each platform.

C:\skylicht-engine>cmake -S . -B ./PrjVisualStudio -G "Visual Studio 16 2019" -A x64
C:\skylicht-engine>cmake -S . -B ./PrjVisualStudio -G "Visual Studio 17 2022" -A x64
/User/Skylicht/Documents/skylicht-engine$cmake -S . -B ./PrjMac -G Xcode 
$ skylicht-engine$ cmake -S . -B ./PrjLinux -G "Unix Makefiles"

Once the solution opens, the instructions are to right click a SampleXXX project, set it as the startup project and press play to run the demo app. The BuildCommand folder holds the more detailed command lines.

The optional asset pipeline: texture compression and shader inlining

Two asset tools are documented, and the README is clear that both are optional. You skip the texture step if you do not modify any resource texture, and you skip the shader step if you do not modify any shader. That framing matters, because a reader who thinks the pipeline is mandatory will spend an evening on Python dependencies they did not need.

The texture tool converts .TGA textures into compressed formats, .DDS, .ETC2 and .PVRTC, to reduce GPU memory at runtime. It needs two Python packages, tinydb for the database it stores state in and Pillow for image processing.

C:\Python37\Scripts\pip install tinydb
C:\Python37\Scripts\pip install Pillow
C:\skylicht-engine\Assets>python BuildTextureCompressDDS.py
C:\skylicht-engine\Assets>python BuildTextureCompressETC.py

The shader tool uses a C preprocessor to inline shader scripts, GLSL and HLSL. It needs the pcpp package.

C:\Python37\Scripts\pip install pcpp
C:\skylicht-engine\Assets>python BuildShader.py

The shader step is where the mobile tuning happens. The README says you can optimise shaders for iOS and Android by recompiling with HARD_SHADOW defined, by editing the shadow library and adding that define before rebuilding the shaders. The same file has a commented-out PCF_NOISE alternative, so the shadow filtering strategy is a compile-time choice rather than a runtime setting.

Adding a project and creating a new application

Two workflows are documented for extending the engine. The first is adding source files to an existing project.

New source files or subfolders go under Projects/{ProjectName}/Source, and then the project is regenerated with the same CMake command as before.

C:\skylicht-engine>cmake -S . -B ./PrjVisualStudio -G "Visual Studio 17 2022" -A x64

The second is creating a whole new application, which uses a script in the Scripts folder. The example creates an application called NewApplication in the Samples folder.

    C:\skylicht-engine>python Scripts\create_project.py NewApplication Samples\NewApplication

After that, CMakeProjects.cmake needs a new line pointing at the new subdirectory, and the projects are regenerated. The new application then appears as a project in the Visual Studio solution, where you set it as the startup project.

That two-step pattern, script then edit the CMake file, is the one detail worth internalising. There is no project registry in the engine, so every new application is a directory plus a line in a CMake list, which is simple and transparent but also means the engine has no view of your own project structure.

The Android path and the NDK build

Android has its own prerequisites: Android Studio and the SDK, mingw-w64 for Windows, and the Android NDK.

The build has a first step, building the native library, and the README directs you to edit a file, BuildCommand/BuildAndroidNDK.cmd, with a text editor to set your own paths for MINGW and NDK.

set MINGW=C:\MinGW\bin
set NDK=C:\Android\android-nd

The reason for the mingw dependency on a Windows host is that the NDK toolchain expects a host cross-compiler, so a Windows machine needs one installed and pointed at.

The project also carries the CI configuration for the platforms it supports. The README's build status table shows Cygwin64 on AppVeyor, Windows, macOS, iOS, Linux and Emscripten on GitHub Actions, and Android on CircleCI. The presence of an Emscripten build is the clearest signal that the web target is a first-class one rather than an experiment, since Emscripten is what compiles C++ to WebAssembly for the browser.

Where Skylicht Engine is the wrong choice

The first limitation is the toolchain, and it is not a small one. Getting a first build to run means CMake, Python, an IDE, Git LFS, and a Python environment for the asset tools, and the README's own example paths show a Windows layout with Python 3.7 in C:\Python37. There is no editor, no asset browser and no scene authoring tool in the repository, so the workflow is code and command line, and if you come from Unity or Unreal the difference in iteration speed is immediate.

The second is that the demo assets are large files in Git LFS. That is a deliberate choice, since .tga and .fbx assets are what the samples need, but it means a clone pulls a substantial amount of data and a CI setup has to handle LFS as well as the code.

The third is the Python tooling age. The README's install commands point at C:\Python37\Scripts\pip, and the texture tool depends on Pillow at a 4.1.x version in the documentation link and tinydb for state. A 2018-era Python dependency set on a project whose last push was on 2026-10-18 is a mismatch worth checking before you invest in the pipeline.

The fourth is the fork relationship itself. Skylicht Engine is an evolution of Irrlicht, which means the API and asset pipeline follow Irrlicht conventions rather than current practice, and a developer with Irrlicht experience will adapt faster than one with modern engine experience. The upside is the opposite: if you know Irrlicht, this is a recognisable codebase with a much broader platform story.

The fifth is that the project publishes no GitHub releases, so there is no versioned binary to download and no changelog to consult. Version.txt sits at the top level of the repository, but the versioning story is thin, and a team evaluating the engine has to read the source to judge its state.

Licence, maintenance and the cost of running the pipeline

The project is under the MIT licence, with LICENSE.md at the root of the repository, and the README states that the framework is free and available to everyone. For an engine, that matters because the licensing of the upstream Irrlicht code and of any bundled asset has to be checked separately from the engine's own terms.

The repository is not archived and the last push was on 2026-10-18, so the engine is being worked on. The default branch is master, the language is C++, and the topics list names the Irrlicht Engine, directx11, opengles3, Google ANGLE, lightmapper, particle and game-engine tags, which is an accurate summary of the technical centre of gravity.

The cost of running the pipeline is dominated by the asset tooling rather than by the engine itself. A developer who only changes C++ code never touches the Python tools. A developer who changes a texture or a shader runs a compression step or a shader inlining step, and the README's hard shadow flag means a shader change for mobile is a rebuild rather than a recompile of the C++ side.

The other recurring cost is platform work. A cross-platform engine with Direct3D 11, OpenGL 4+, OpenGLES 3+ and Angle backends means a change in the render path has to be validated on each of them, and the CI matrix in the README's build status table shows that this is a continuous obligation rather than a one-off.

Editorial conclusion

Skylicht Engine fits a developer who wants an Irrlicht-style C++ engine with modern mobile and web backends, a forward and deferred pipeline and a working set of samples, and who is prepared to follow the asset tooling rather than work around it. It does not fit a team that wants a modern editor-driven workflow, because the project ships a build script and sample projects rather than a scene editor. Verify your toolchain versions first, CMake 3.12 or higher with Python 3.x, and be ready to install Git LFS, since the demo assets are stored as large files.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. skylicht-lab/skylicht-engine on GitHub