kool: a Vulkan, WebGPU and OpenGL engine written in Kotlin

One engine, three graphics backends, three target platforms

kool is described as a multi-platform Vulkan, WebGPU and OpenGL game engine that works on Desktop Java, Android and browsers, and the primary language is Kotlin. That combination is the unusual part of the project, because a JVM language compiling to WebAssembly for the browser is not a normal thing to do, and it is what lets the same Kotlin source run in three places. The rendering side is not a thin abstraction either. The topic list names Vulkan, WebGPU, OpenGL, PBR shading, deferred shading and a Vulkan game engine, and the demos cover screen-space reflections, screen-space ambient occlusion, instanced and LOD drawing, physically based rendering with image based lighting, shell shading for fur, compute shader particles and a compute shader path tracing implementation. The core module is published to Maven Central under the de.fabmax.kool group, and the build is a Gradle Kotlin DSL project with a buildSrc directory and a gradle wrapper checked in.

The web demos fall back to WebGL, and some features disappear with it

The demo gallery is the fastest way to see what the engine does, and the readme is upfront about the browser situation. Chrome is highly recommended because it is still the only browser with WebGPU support, and other browsers should work but use the WebGL backend, which does not support all features or demos. Several demos are labelled WebGPU only, and they are the showpieces. The vehicle demo is a drivable vehicle based on the Nvidia PhysX vehicles SDK and is described as a good demonstration of deferred rendering with screen-space reflections, artifacts included. The bloom demo, the path tracing demo built on a compute shader implementation of Ray Tracing in One Weekend, the procedural geometry demo and the deferred shading demo with thousands of dynamic light sources all carry the same marker. By default the demos use the WebGPU backend and fall back to WebGL, and the backend in use is printed in an extended info panel in the lower right corner. You can also force one by appending a backend query parameter to the URL.

Physics is the PhysX SDK and the 2D engine is separate

The physics stack is not homegrown. The vehicle demo is built on the Nvidia PhysX vehicles SDK, and the ragdoll and joints demos exist alongside it, with the joints demo described as a chain running over two gears using a lot of multi shapes and revolute joints. There is a separate 2D physics demo with many dynamic bodies and two kinematic rotors, and the repository layout reflects the split, with separate kool-physics and kool-physics-2d directories. The collision demo is described as the obligatory one, covering a range of different shapes. The 2D stack is a meaningful inclusion because a 3D engine that also handles 2D physics in the same language and with the same scene graph saves a project that needs both from having a second toolchain. The demos are also a decent map of the engine's own capability, since the readme frames them as a set of techniques rather than a single showcase, from procedural geometry generation to interactive mesh simplification based on the traditional error-quadrics approach.

A UI framework built inside the engine, with compose-style effects

The embedded UI demo is the one that shows how the engine is meant to be used for tools rather than only for games. It is described as an integrated UI framework implemented completely within the engine, fast, highly customizable and easy to use, offering advanced features such as a compose-style LaunchedEffect and animations with a separate easings demo. Implementing the UI inside the engine rather than bolting on a platform toolkit is what allows the same interface code to run in a browser, on the JVM and on Android, which is the same argument the multi-platform backend makes. The engine also ships a scene editor implemented within itself, including its own UI, which is a neat constraint to work under. The repository has dedicated directories for kool-compose-ui, which is the UI layer, and for kool-editor and kool-editor-model, which separate the editor application from the model it edits.

A graphical scene editor that is still early

The scene editor is the newest and least finished part, and the readme sets expectations clearly. The editor used to be a code-only engine, but the author recently made some progress in implementing a graphical scene editor, and it is still in an early state and lacks several rather essential features, although the basics already work quite well. It is fully implemented within the engine itself, including the UI, and there is a web version you can open in a browser with Chrome recommended. To get the full potential of the editor you should run it locally, and the readme starts describing a route for that by downloading the project from the web version using a Save Project button in the upper right corner. The honest reading is that this is a tool the author uses to build the engine, published early, and the scene editing workflow it supports is still being shaped.

The demo project is the quickest way to run the engine yourself

The demos are published as a live site, but the readme also says you can run them locally by cloning the repository and running the demo subproject through the gradle wrapper, with the command given as ./gradlew :kool-demo:runDesktop. The demo code lives in the kool-demo subproject, in the demo package under the commonMain source set, which is worth noting because the commonMain convention is the Kotlin multiplatform mechanism, and the same source is what compiles for the browser and for Android. The engine core is published to Maven Central as de.fabmax.kool kool-core, so a project that only wants the runtime can depend on the artifact rather than building the whole workspace. The project also links a finished game built with the engine, Blocks and Belts, published on itch.io and described as free, which is a useful reference point for what the engine can carry in practice rather than only in a demo.

A regular release line and a busy main branch

On maintenance, the signals are healthy. The repository is not archived and the last push was on 2026-10-20, and the recent releases are v0.19.0 from 2025-12-20, v0.18.0 from 2025-09-28 and v0.17.0 from 2025-03-26, which is a roughly quarterly release cadence for a graphics engine with three backends. The version numbers sit below 1.0, so the usual expectations about API stability before a 1.0 apply. The licence is Apache-2.0, and the repository has the usual companion files including a CODE_OF_CONDUCT.md and a build workflow badge for the main branch. The topic list also names the areas the engine is pushing into, with physics, deferred shading and PBR shading all called out, and the WebGPU and WebGL2 topics indicating that the older browser backend is still maintained alongside the newer one.

Editorial conclusion

kool fits a Kotlin team that wants to ship one 3D codebase to the JVM, Android and the browser, with a UI framework and physics already in the engine rather than as separate dependencies. It does not fit a project that needs the full feature set on the WebGL backend, because several demos including the vehicle, bloom, path tracing and deferred shading are marked WebGPU only, and Chrome is described as the only browser with WebGPU support. Before you adopt it, check the WebGL fallback against the features you need, run the demo subproject locally with the gradle wrapper to see the engine on your own hardware, and treat the scene editor as an early tool rather than a production workflow, since the readme says it still lacks several essential features.

Frequently asked questions

Official sources

1. kool-engine/kool on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases