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.
React Three Fiber (R3F) is a React renderer for three.js, enabling declarative construction of 3D scenes using JSX. It provides a `<Canvas>` component that bootstraps a WebGL renderer, a custom React reconciler that bridges React's component lifecycle with three.js objects, and a rich set of hooks (`useFrame`, `useThree`, `useLoader`) for imperative control. The architecture follows a monorepo pattern with three packages: the core fiber library (web and React Native), a test renderer for unit testing 3D components, and an ESLint plugin enforcing performance rules. The core library abstracts WebGL details, handles pointer events with raycasting, manages the render loop, and supports advanced features like portals, Suspense for async assets, and context bridging. It is a foundational tool for building interactive 3D applications in the browser or on mobile via Expo. The codebase demonstrates high craftsmanship with clean abstractions, extensive test coverage, and a modular design that separates concerns across reconciler, event system, state management, and rendering utilities.
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.
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.
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.
MethaneKit is a cross-platform graphics rendering framework that provides abstractions over DirectX 12, Vulkan, and Metal APIs. It features a layered architecture with platform-independent interfaces (RHI), platform-specific implementations, an application framework, UI components, and mathematical utilities. The framework includes tutorial applications demonstrating various graphics techniques from basic triangle rendering to compute shaders and parallel rendering. Key systems include resource management, command submission, pipeline state handling, and synchronization primitives. The codebase demonstrates modern C++ practices with extensive use of templates, PIMPL idiom, and interface-based design.
DockYard/elixir-mail is an Elixir library for building, parsing, and rendering email messages according to RFC 2822 and related MIME standards. It provides a composable API to create simple and multipart email messages, handle various transfer encodings (Base64, Quoted-Printable, 7bit, 8bit, binary), and parse incoming email into structured data. The library is structured around a core `Mail.Message` struct with separate modules for encoding, parsing, rendering, and MIME type lookup. It does not require any external runtime dependencies beyond the Erlang/OTP standard library.
OpenMoonRay is an open-source, production-grade path-tracing renderer developed by DreamWorks Animation and hosted under the Academy Software Foundation (ASWF). It is designed for feature film and VFX pipelines, supporting CPU and hybrid GPU (XPU) rendering, physically based materials, and integration with USD-based digital content creation tools via a Hydra render delegate. The system is composed of approximately 20 interconnected submodules covering core rendering, scene representation (RDL2), shaders (Moonshine), distributed computation (Arras), denoising, and more. Key entry points include the `moonray` CLI, `hd_render` for Hydra, `arras_render` for distributed rendering, and a Qt-based GUI (`moonray_gui`). The architecture is modular: the root repository orchestrates builds, provides test data, and houses build scripts and CI configurations, while the actual rendering logic resides in submodules. External dependencies include USD, OpenVDB, Embree, OpenImageDenoise, MaterialX, and Qt5, many of which require local patches for compatibility. The project is actively maintained with regular TSC meetings, CI workflows for Linux and macOS, and a growing open-source community.