$ show FyroxEngine/Fyrox
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.
The LLM identified 5 files worth highlighting for reuse:
Provides safe simultaneous mutable and immutable access to different entries in a pool using ref-counted interior pointers and manually enforced borrow rules. This is a non-trivial Rust safety abstraction that could be extracted into a standalone generational arena/sparse collection crate; it demonstrates advanced unsafe-code discipline and is backed by tests.
A runtime reflection system with field metadata, inherited properties, and collection support, driven by derive macros. It is the foundation for the editor's inspector and for serialization across the engine. The trait design and macro expansion are self-contained enough to serve as a reference implementation or reusable reflection layer for other Rust projects needing runtime type introspection without dynamic typing.
A high-quality octree implementation supporting sphere, AABB, ray, and point queries over triangles, with exhaustive unit tests that assert exact query results. It is a standalone spatial acceleration structure that can be lifted directly into other 3D/graphics/robotics projects, showcasing careful data-structure engineering and clear query APIs.
An extensible property-editor framework built around the `PropertyEditorDefinition` trait, with ready-made editors for numerics, vectors, colors, curves, strings, UUIDs, collections, and more. The trait-based registration and message translation pattern is reusable for building generic inspector UIs in any Rust GUI application and avoids boilerplate by decoupling value types from widget construction.
Implements a set of reusable audio DSP building blocks including one-pole filters, biquad filters, comb filters, and all-pass filters. The code cleanly separates filter algorithms from the sound engine and is immediately adaptable to other audio applications or plugin systems; it demonstrates solid signal-processing fundamentals with a compact, testable API.