Filament supplies rendering without an editor or game systems
Filament gives an application a physically based renderer and leaves the surrounding product architecture to its caller. Native code creates an engine, swap chain, renderer, view, scene, and camera, then supplies platform windows and renderable entities. That is a good boundary for a map, product viewer, design tool, or custom engine that needs 3D inside an existing app. A game team seeking an editor, physics, scripting, and asset authoring would have to add those elsewhere.
The engine covers glTF 2.0 loading, image-based lighting, shadows, color grading, dynamic resolution, and several material models. Host tools compile materials, generate environment lighting, and convert meshes. This scope lives in a repository that our scan measured at 52,456 files, about 9,314,458 source lines, and 1,537.2 MB. Filament may be small inside an Android product by design, but its source tree and contributor surface are substantial.
Release 1.76.0 supports six targets and several backends
The README names Android, iOS, Linux, macOS, Windows, and WASM as targets. Native clients use C++, Android also gets Java and JNI, and the web build exposes JavaScript. Backend choices include OpenGL, OpenGL ES, Metal, Vulkan, WebGPU, and WebGL 2.0, with availability varying by platform. Android developers can consume Maven artifacts, while iOS users get a CocoaPods path. Release archives include the host tools needed to prepare assets.
Version 1.76.0 shipped on August 28, 2026 with an API change to async completion callbacks, a PowerVR OpenGL ES picking fix, and support for up to 4 extra unshadowed directional lights. It also removed a material variant bit and introduced material changes that require recompilation. In a 1,537.2 MB checkout, those cross-cutting changes are a reason to read every release note before moving the runtime and material compiler together.
What happened when we ran it
Our sandbox run at commit 97b6c66 targeted docs_src/build, the Python documentation tooling. Installation succeeded in 21 seconds, adding 45 packages and using 63 MB on disk. That documentation build succeeded in 7 seconds. The machine was an unprivileged Debian container with 3 CPUs, 8 GB of RAM, no secrets, and a Python 3.12 uv image. We did not compile or execute the C++ rendering engine.
Pytest ran for 6 seconds and exited with code 5. Its complete summary was no tests ran in 0.00s, so 0 tests passed and 0 failed out of 0. Pip-audit reported 0 known vulnerabilities in the installed Python packages. The repository scan found 14 CI workflow files, no Dockerfile, and a tests directory. These findings describe the documentation subproject and repository signals, not native renderer correctness or GPU performance.
Source builds start with CMake, Clang, and Ninja
A native Linux build requires CMake 3.22.1 or newer, Clang 17 or newer, Ninja 1.10 or newer, libc++, and several X11 or OpenGL development packages. The supplied build.sh can create debug or release output after those prerequisites exist. Windows follows a Visual Studio route, while WebAssembly adds Emscripten and an EMSDK setting. Prebuilt releases avoid much of this work when the target package already fits the application.
Android source builds add Android Studio Quail or newer, NDK 29 or newer, Java 21, and an ANDROID_HOME path. The host build must come first because Android needs tools that run on the developer machine. A universal AAR also expects 4 ABI builds unless the project filters them. The 14 CI workflows show serious platform coverage, yet the lack of a project Dockerfile means the repository does not hand Linux contributors one fixed toolchain image.
Material tools and runtime libraries must share a release
Materials are compiled into binary packages by matc, and the README explicitly tells users to pair host tools with the same release as the runtime library. Environment maps need preprocessing with cmgen or the related library. Those steps belong in the product's build and asset pipeline, along with glTF validation and device checks. Updating only the Maven or CocoaPods dependency can leave generated material data behind when a release changes its format.
Our 45-package Python environment only exercised documentation generation. Its 7-second build says nothing about CMake compile time, shader compilation, rendered output, or frame rate. A useful evaluation should take representative models and materials through the matching release tools, render them on each chosen backend, and compare images on real devices. Filament exposes many backend choices; the application still owns the test matrix and the policy for falling back when one driver misbehaves.
WebGPU still has unfinished async operations
GitHub recorded a last push on September 5, 2026, 20,453 stars, and 212 open issues and pull requests. The latest release was eight days earlier, and pull requests for WebGPU, Android samples, binding checks, and backend safety were active during the first week of September. That is current maintenance across several platforms. The queue also documents gaps that matter to anyone choosing a particular backend or mobile effect.
Issue 10374 says most asynchronous WebGPUDriver resource functions remain TODOs. Issue 9468 records screen-space refraction crashes on Adreno 710 OpenGL devices, with another report on some Adreno 740 phones; an August 2026 commenter said switching to Vulkan avoided the crash on one affected device. Our 6-second pytest result collected 0 documentation tests and cannot reduce either risk. Test the exact effect, device, driver, and backend combination before making Filament the rendering layer.