Three.js is a mature, production-grade JavaScript 3D library providing WebGL and WebGPU renderers, a comprehensive scene graph, and extensive tooling for 3D web applications. The codebase demonstrates exceptional architecture with a clean separation between core rendering (src/), the new node-based shader system TSL (Three.js Shading Language), and a vast ecosystem of addons in examples/jsm/. The library supports multiple renderers (WebGLRenderer, WebGPURenderer, CSS2DRenderer, CSS3DRenderer, SVGRenderer), a full animation system, physics integrations (Ammo, Rapier, Jolt), WebXR for AR/VR, and loaders for 30+ formats (GLTF, FBX, USD, OBJ, etc.). The TSL node system is a standout achievement - a compiler-like architecture that transpiles shader graphs to GLSL/WGSL with automatic differentiation, lighting models, and post-processing. The WebGPU backend shows deep GPU API expertise with pipeline management, bind groups, and descriptor reuse. Code quality is consistently high with strong typing patterns, comprehensive unit tests (200+ test files), and modern ES module architecture. The project is actively maintained with recent commits, semantic versioning, and CI/CD pipelines.
PixiJS is a mature 2D rendering library for the web (npm package pixi.js). Its production purpose is to let developers build interactive scenes, games, visualizations, and creative applications using an object-oriented scene graph and render them through WebGL, WebGPU, or Canvas backends. The core runtime is a modular TypeScript library, not a monolith: users construct Containers, Sprites, Graphics, Text, Meshes, and ParticleContainers, then a renderer collects renderables into instruction sets, batches draw calls through backend-specific adaptors and pipes, and manages GPU resources such as textures, buffers, uniform groups, and render targets via pooling and garbage-collected caches. The repository also includes an asset subsystem with loader parsers, a resolver, a cache, and format detection, plus an extension registry that allows custom systems, loaders, pipes, filters, and backend adaptors to be registered cleanly. Primary entry points are src/index.ts, the Application class with initialization and plugins (ResizePlugin, TickerPlugin, CullerPlugin), autoDetectRenderer, and the Assets API. The library depends on browser platform capabilities (Canvas 2D, WebGL/WebGPU, OffscreenCanvas, Web Workers, fetch) and small npm packages; compressed-texture support shells out to Basis/KTX transcoders. Data flows are asset ingestion (fetch/parse/cache) and GPU command generation; there is no server-side pipeline or ETL component. The codebase shows strong engineering practice: typed extension points, backend abstraction layers, performance-conscious allocation management, dual GLSL/WGSL shader support, and an extensive test suite including snapshot-based visual regression tests across WebGL1, WebGL2, WebGPU, and Canvas. Some deprecation shims and experimental features exist, but the project is actively maintained with recent commits, release automation, and active issue triage.
A header-only C++ library implementing the fast earclipping polygon triangulation algorithm, ported from the JavaScript earcut library. It provides a simple API (`mapbox::earcut`) that takes a polygon (with holes) and returns triangle indices, with an optional Delaunay refinement post-pass (`mapbox::refine`). The library is heavily optimized for real-time triangulation of vector tile geometries, using z-order curve hashing, custom memory allocation (object pool), and a block bounding-box index for efficient hole bridging. It targets C++14 for the public header and C++17 for tests/benchmarks. The repository also includes comprehensive test fixtures loaded at runtime from the upstream JS repository, benchmarks comparing against libtess2, and an interactive OpenGL visualizer.
Dear ImGui is a production-grade, immediate-mode graphical user interface library for C++. It provides a self-contained core engine (rendering, widgets, tables, fonts, input handling) and a large ecosystem of platform and renderer backends (GLFW, SDL2/3, Win32, Vulkan, DirectX, Metal, OpenGL, WebGPU, etc.) that enable integration into any application with minimal overhead. The architecture is a library with pluggable backends: user code calls ImGui::NewFrame() to build UI, then ImGui::Render() produces draw data consumed by the chosen renderer backend. The repository includes dozens of example applications demonstrating integration with various windowing systems and graphics APIs, as well as utilities like font embedding tools, FreeType rasterizer integration, and a headless backend for testing. It is not a data research project; it is a software library for building tools, debug UIs, and in-game overlays.
Bevy is a modular game engine built in Rust with an Entity Component System (ECS) at its core. It provides a complete 2D and 3D feature set including rendering, asset loading, audio, UI, animation, and physics systems. The engine uses a plugin-based architecture for extensibility and features a robust reflection system for runtime type inspection and serialization. Bevy emphasizes data-oriented design, productivity, and cross-platform support (desktop, web, mobile).
F3D is a fast, minimalist 3D viewer and rendering library (libf3d) built on VTK, providing both a desktop application and a reusable C++ library with bindings for C, Python, Java, and WebAssembly. It loads and interactively visualizes dozens of 3D file formats (glTF, USD, STEP, STL, OBJ, FBX, etc.) through a plugin architecture. The application offers a rich CLI, interactive console, configurable rendering options, animations, and scientific visualization features like volume rendering, scalar coloring, and point clouds. The library exposes a clean public API (engine, scene, window, camera, interactor, options) that can be embedded in other applications or used for offscreen rendering. The codebase demonstrates strong engineering: modular plugin system, extensive test suite (including pixel comparison and event recording), cross-platform support, and thorough documentation. Its architecture separates concerns cleanly between application layer, library, VTK extensions, and plugins, making individual components potentially reusable in other VTK-based projects.
Genesis is a universal physics engine designed for robotics and physical AI simulation. It provides a unified multi-physics framework supporting rigid-body dynamics, finite element method (FEM), material point method (MPM), position-based dynamics (PBD), smoothed particle hydrodynamics (SPH), and incremental potential contact (IPC) coupling. The engine is GPU-accelerated via a custom compiler (Quadrants, forked from Taichi) and scales from single-CPU laptops to multi-GPU datacenters. It features differentiable simulation with gradient tape and manual backward passes, enabling end-to-end optimization through physics. The architecture follows a scene-entity-solver pattern with pydantic-based options for configuration, a plugin-based sensor system (cameras, IMU, tactile, lidar, etc.), and multiple rendering backends (rasterizer, raytracer, batch renderer). Robotics-specific features include URDF/MJCF/USD asset import, inverse kinematics, PD control, and reinforcement learning integration via rsl-rl. The codebase is well-structured with extensive tests, CI/CD pipelines, and a large set of examples covering manipulation, locomotion, deformables, fluids, and coupling scenarios. While the engine is primarily an application library, it also serves as a research platform for differentiable physics and novel simulation techniques.
NVRHI is a C++ hardware abstraction layer for real-time GPU programming. It exposes a single vendor-neutral RHI API (defined in include/nvrhi/nvrhi.h) and implements it through D3D11, D3D12, and Vulkan backends. Applications interact with interfaces such as IDevice, ICommandList, IBuffer, ITexture, and pipeline objects, while each backend translates those calls into native graphics API operations. The library is not an application or service; its primary entry points are device factory functions like nvrhi::d3d12::createDevice, nvrhi::d3d11::createDevice, and nvrhi::vulkan::createDevice, plus an optional validation layer created through nvrhi::validation::createValidationLayer.
Fyrox is a large, mature Rust game engine delivered as a multi-crate workspace, plus a full visual scene editor (fyroxed) and a project manager. The codebase implements a complete runtime stack: 3D/2D rendering through OpenGL or wgpu backends, a scene graph with dynamic node types, physics integration via Rapier, an animation system with ABSM state machines, a sound engine with HRTF and DSP effects, a custom UI toolkit, and an async resource loading framework. The editor is built on the engine's own UI and uses plugin architecture, command-based undo/redo, inspector property editors, gizmos, tilemap tools, and asset browsers. Entry points include the public `fyrox` facade crate, `editor-standalone/src/main.rs` for the editor binary, `project-manager/src/main.rs` for project management, and example applications in `examples/` and `fyrox-sound/examples/`. Architecturally, the engine is a library plus a desktop application rather than a service. It relies heavily on a custom reflection and serialization stack (`Reflect`, `Visit`, type UUIDs, builder patterns) that powers scene persistence, asset hot-reloading, and editor inspectors. The primary data flow is asset-to-scene: resource loaders read files (FBX, glTF, RGS, RON, audio, textures), construct typed resources through UUID-driven constructor containers, and insert them into the scene graph; the renderer then converts scene nodes into GPU data via deferred rendering, caches, and visibility/occlusion systems. Plugin/script hot-reload is supported for dynamic loading of game code. External dependencies include winit for windowing, Rapier for physics, nalgebra for math, wgpu/OpenGL for graphics, and OS audio backends. The codebase is generally well-engineered, with clear subsystem boundaries, reusable builder APIs, and an unusually deep custom infrastructure for an open-source engine. However, it carries notable maintenance risk: two graphics backends must stay in sync, parts of the editor are tightly coupled to engine internals, several modules contain unsafe transmutes or deliberate leaks, and the custom derive macros and serialization format require careful versioning. Dependency drift exists, including old `syn`/`darling` versions in `fyrox-core-derive` and unresolved backend feature gaps such as missing wgpu occlusion queries. Overall this is a strong, active codebase with several genuinely reusable components, but not an exceptionally polished one.
Two.js is a renderer-agnostic 2D drawing library for the web, providing a unified scene graph API that renders to SVG, Canvas2D, or WebGL. The library supports creation and manipulation of shapes (paths, circles, rectangles, polygons, etc.), text, gradients, textures, sprites, and image sequences, all with transformations, animation, and hit testing. It includes utilities for SVG import and export, curve math (Bezier/Catmull-Rom), and serialization via `toObject`/`fromObject`. The architecture is modular: a core `Two` class manages the scene and animation loop, with a hierarchy of elements (Element → Shape → Path/Text/Points), a Group container for scene graph nesting, and separate renderer implementations for each target. Key entry points are the `Two` constructor, factory methods (`makeCircle`, `makePath`, etc.), `update()`, `play()`, and `pause()`. The library has no external runtime dependencies beyond standard browser APIs, though optional `node-canvas` enables headless rendering. Notably, the codebase demonstrates high craftsmanship with a flag-based dirty tracking system for efficient updates, an event system with cross-object observation, and a collection pattern with mutation events. However, it shows maintenance drift through some outdated development dependencies (e.g., `babel-eslint`, `underscore`) and manually maintained TypeScript declarations that may lag behind the source.
This repository, NVlabs/tiny-cuda-nn, is a high-performance C++/CUDA library and PyTorch extension for training and querying neural networks with a focus on extreme GPU efficiency. It provides a modular, JSON-configurable framework of specialized components: input encodings (multiresolution hash grids, spherical harmonics, frequency, etc.), network architectures (fully fused MLP using Tensor Cores, CUTLASS-based MLP), loss functions, and optimizers (Adam, Shampoo, Novograd, etc.). The library supports runtime JIT compilation to fuse forward, backward, and loss kernels into single CUDA kernels, yielding up to 5x speedups. It is the engine behind NVIDIA's Instant Neural Graphics Primitives (Instant NGP) and is widely used in NeRF and neural rendering research. The codebase is production‑quality, with extensive use of templates, GPU memory arenas, CUDA graphs, multi‑stream parallelism, and comprehensive CI across many CUDA versions and GPU architectures. Although primarily a library, it includes sample applications and benchmarks that demonstrate its use in image overfitting and throughput measurement. PyTorch bindings via pybind11 make it accessible for Python‑based research workflows.
ppy/osu-framework is a high-performance, cross-platform game framework written in C#, primarily designed to power the rhythm game osu! but offering general-purpose 2D game development capabilities. The codebase provides a comprehensive suite of subsystems including a hardware-accelerated rendering pipeline (OpenGL/Veldrid), a sophisticated input handling system (mouse, keyboard, touch, tablet, joystick, MIDI), an audio engine built on BASS and FFmpeg, a rich animation and layout system, and a full-featured UI toolkit with containers, text rendering, and interactive controls. It employs Roslyn source generators to eliminate runtime reflection for dependency injection and input dispatch. The architecture is modular, heavily test-driven (thousands of unit and visual tests), and supports Windows, macOS, Linux, iOS, and Android through platform-specific host implementations. Despite its strong engineering, the codebase shows signs of ongoing migration to SDL3, dual rendering backends, and reliance on unmanaged native libraries that require periodic updates.
Tetra3D is a pure-Go 3D game engine and rendering library built on top of Ebiten (a 2D game library). It provides a full scene graph with nodes, models, cameras, lights, materials, and animations, along with collision detection, particle systems, text rendering, and pathfinding grids. The architecture is a library with a rich set of examples demonstrating each feature. Key entry points include the tetra3d package root, Camera.RenderScene() for rendering, and gltf.LoadGLTF() for asset loading. Data flows involve loading GLTF/GLB files (with custom Blender exporter metadata), constructing a scene graph, and rendering per frame with support for lighting, shadows, and transparency. External dependencies are Ebiten for rendering/input, qmuntal/gltf for GLTF parsing, tanema/gween for tweening, and golang.org/x/image for font rendering. The codebase includes SIMD-optimized matrix math, a comprehensive vector library, and a Blender addon for exporting scenes with engine-specific properties.
This repository is a large, modular C++ game engine with a fully integrated editor. The engine core provides a world/component architecture, reflection-driven serialization, resource management, a task system, and a render abstraction layer with DirectX 11 and Vulkan backends. Runtime features are delivered as plugins: Jolt physics, FMOD/MiniAudio audio, RmlUi UI, particle effects, animation graphs, AI navigation, procedural generation, terrain, and OpenXR support. The editor is a Qt-based multi-process application: a host editor process communicates with a separate engine process over IPC, mirroring document objects into a live world for preview and manipulation. Asset managers turn imported files such as meshes, textures, skeletons, animation clips, sound events, and UI documents into versioned engine resources. Sample game applications and extensive unit tests demonstrate the runtime API and provide a working baseline for engine consumers. The codebase is production-oriented rather than research-oriented: there are no notebooks, data pipelines, or ML artifacts. Instead, it is an application and framework monorepo with strong engineering discipline visible in its consistent component/manager patterns, plugin registration conventions, and resource lifecycle management. The custom RTTI/reflection system underpins serialization, editor property grids, undo/redo, and scripting, making the engine highly data-driven. However, the code is macro-heavy and some areas, especially editor plugins, repeat near-identical boilerplate patterns across many asset types. The project is actively maintained, with recent commits, CI workflows, and a large third-party dependency set that is mostly bundled in-tree; some bundled libraries and platform-specific paths show moderate drift but not abandonment.
OGRE (Object-Oriented Graphics Rendering Engine) is a mature, production-grade 3D rendering engine written in C++ with extensive cross-platform support. The codebase implements a modular plugin architecture with render system backends for Direct3D 9/11, OpenGL (legacy, 3+, ES2), Metal, Vulkan, and a software Tiny renderer. Core modules include scene management, material/shaders, resource handling, animation, particle systems, and compositor framework. Optional components provide real-time shader generation (RTShaderSystem), automatic mesh LOD generation, terrain rendering, volume rendering, world paging, and a 2D overlay system. The repository also includes Python bindings, sample applications, fuzz testing, and content pipeline tools (exporters for Maya, Milkshape, Wings3D). The architecture follows design patterns such as Singleton managers, Factory-based extensibility, and a work queue for background loading. Despite its age and size, the engine remains actively maintained with recent commits, CI/CD pipelines, and support for modern graphics APIs. Notable technical debt includes legacy render backends, deprecated APIs, and some tightly coupled subsystems.
Inja is a header-only C++ template engine that renders Jinja2-like templates using JSON data. It provides a full-featured templating language including variables, loops, conditionals, template inheritance, includes, custom callbacks, whitespace control, and HTML autoescape. The library is built on top of nlohmann/json and requires C++17. It is distributed as a single-include header or via package managers. The architecture is clean: an Environment class orchestrates parsing (lexer + parser into AST) and rendering (evaluator with built-in and user-defined functions). Extensive unit tests and benchmarks ensure correctness and performance. The library is actively maintained with CI across multiple compilers and platforms.
NeoForge is the official successor to Minecraft Forge, providing a comprehensive modding framework and API for Minecraft. It extends vanilla Minecraft through a patching system (coremods/ASM) and a rich event-driven architecture, allowing mods to hook into gameplay, rendering, networking, registries, capabilities (data attachments), and resource transfer. The repository includes the mod loader itself (client and server), a Gradle-based build system (buildSrc) for producing the framework and installer, and an extensive test framework (testframework/) with both unit and in-game game tests. The codebase is well-structured with clear client/server source splits, extensive use of codecs and data-driven JSON, and a modern transactional resource API for energy, fluids, and items. It is actively maintained with large community adoption.
Figura is a Minecraft mod (client-side with optional server-side backend) that allows players to fully customize their avatar's appearance, animations, sounds, particles, and behavior using Lua scripting. The architecture is a multi-loader (Fabric, Forge, Quilt, NeoForge) client mod with a server-side plugin (Spigot) for avatar storage, permissions, and networking. The client-side core includes a Lua runtime (LuaJ) with a sandboxed API exposing over 30 modules (e.g., models, textures, sounds, events, keybinds, action wheel, networking, math). Avatars are defined by Blockbench models, Lua scripts, textures, and sounds, all packaged into NBT files. The rendering pipeline hooks into Minecraft's vanilla rendering via extensive mixins to replace player models, modify armor, cape, elytra, and nameplates. The server-side backend (Figura Server Bridge) provides avatar upload/download, user data, pings, and permission management via WebSocket or custom Minecraft packets. Key entry points include the `Avatar` class (lifecycle), `FiguraLuaRuntime` (script execution), `AvatarRenderer` (rendering), `PermissionManager` (access control), and `NetworkStuff` (backend communication). External dependencies include LuaJ, Gson, nv-websocket-client, and Minecraft's own libraries.
Yave is a C++20 Vulkan-based real-time graphics engine paired with a custom ImGui-driven editor and a self-contained core utility library named `y`. The repository is structured as three layers: `y` provides reusable containers, math, concurrency, IO, serialization, and a test framework; `yave` implements the engine itself (Vulkan device/window management, frame graph, render passes, ECS, asset pipeline, physics, animation, and scripting); and `editor` is a full 3D scene editor application with workspaces, widgets, gizmos, importers, thumbnails, and undo/redo. The renderer supports deferred PBR, cascaded shadow maps, TAA, bloom, SSAO/RTAO, RTGI, atmosphere scattering, and tone mapping, and it runs through a declarative frame graph with automatic resource pooling and barrier insertion. The editor is not a separate toy: it provides asset browsing, glTF/image import, material editing, scene outliner, inspector, file system views, performance metrics, GPU profiling, and RenderDoc integration. The engine uses a modern ECS with component groups, async asset pointers, and a serialization framework that supports schema evolution. The `y` library is particularly notable for its clean, high-performance primitives: SSO strings, flat hash maps with SIMD probing, sparse component sets, dependency-aware job system, and a forward/backward-compatible binary serialization layer. Externally, it depends on Vulkan, VMA, Volk, Dear ImGui, JoltPhysics, LuaJIT, tinygltf, stb, Tracy, and spirv_reflect, mostly vendored. While the project is described by its author as a learning/pet engine, the code is generally well-structured and professionally organized. However, it is a single-author codebase with many `Y_TODO` markers, some stubbed platform paths, global device singletons, and an explicit compiler-dependent serialization format. Tests exist mainly for the `y` core containers and math, not for the engine or editor. The repository is active and uses current C++/Vulkan practices, but should be treated as an evolving research-quality engine, not a stable library.
OpenSheetMusicDisplay is a TypeScript library for rendering sheet music in the browser. It parses MusicXML files (including compressed .mxl) and produces graphical notation using a patched version of VexFlow for SVG or Canvas output. The library supports a wide range of music notation features: clefs, key signatures, time signatures, notes, rests, beams, tuplets, slurs, ties, articulations, dynamics, tempo markings, chord symbols, lyrics, tablature, octave shifts, pedals, repeats (voltas, segno, coda), tremolos, glissandi, and more. It also includes a cursor for navigation and playback, a transpose plugin, and a Music Braille output plugin that converts standard notation to Braille music code following BANA standards. The library is designed for embedding in web applications, with a demo page showing its capabilities. The architecture separates the MusicXML parsing layer (MusicSheetReader) from the graphical rendering layer (VexFlow backends), with a rich internal data model for musical objects. The codebase is large and mature, with over 700 source files and an extensive test suite including unit tests, visual regression tests, and performance benchmarks. However, it has some technical debt: large monolithic classes (e.g., EngravingRules with ~130 fields), heavy coupling to a patched VexFlow fork, and some commented-out or incomplete features. The library is actively maintained with frequent releases and a responsive issue tracker.