B3D Framework is a C++17 engine core with an ECS, fibers and one GPU backend done

What the framework claims to be, and how it describes its own state

B3D Framework is described as a C++17 library intended as a foundation for high-performance game engines, games and other real-time graphical applications. The target is stated as zero-compromise performance capable of running large open-world projects, paired with a clean API and a modular internal architecture meant to be easy to understand, modify and extend.

The project is explicit about its maturity. The README says the framework is still in active development but can already serve as a solid foundation for custom game engines. That is a more precise claim than most, and it is paired with a written-down work list rather than a vague promise.

The top level layout matches a full engine rather than a rendering library. `Source/` holds the code, `Platform/` the platform layer, `Dependencies/` third party code, `Data/` engine data, `Examples/` the sample applications, `Scripts/` build and tooling scripts, `Tools/` editor-side tooling, and `Documentation/` the written documentation including the GitHub-facing feature list, release notes and compiling guide. `CMakeLists.txt` is the build entry point and `main.cpp` sits at the root. There are `.gitmodules`, so some dependencies are checked out as submodules, and both `AGENTS.md` and `CLAUDE.md` sit in the root alongside an `.editorconfig`, which suggests the project has been developed with coding agent tooling in the loop.

The licence is MIT, with the terms in `LICENSE.md`.

The ECS, fiber scheduling and cache-aware layouts

The performance claims are grouped into three named items, and they are worth separating because they imply different amounts of work on your side.

The first is an entity component system that scales to massive object counts. The topic tags confirm the ECS orientation with `ecs` and `game-engine-framework`. An ECS changes how you structure game code, since behaviour lives in systems operating on components rather than in an object hierarchy, so adopting this is a design commitment rather than a drop-in.

The second is fiber-based task scheduling across all systems. That is the more distinctive claim. Instead of a fixed job system with an explicit queue per frame, work is expressed as coroutines that can suspend at an await point, which lets a system's code read as sequential logic while the scheduler decides what runs when. For a renderer this removes a lot of manual dependency tracking between passes, since a pass can simply wait for the one it needs.

The third is cache-aware data layouts, which is what makes the first item hold at scale. Once object count is large enough, memory access patterns rather than instruction count decide the frame time.

None of this is quantified in the README. There is no object count, no frame time figure and no comparison against another ECS, so the claims are architectural and you would have to read the documentation and measure on your own scene.

A hybrid tiled deferred renderer, and one backend that exists

The rendering side is described as physically based shading with a hybrid tiled deferred and clustered forward renderer and a Vulkan backend. The hybrid part is the interesting design choice: tiled deferred keeps shading in deferred form with light culling done against screen tiles, which suits many small lights, while the clustered forward path handles cases deferred shading handles badly such as transparents and MSAA. Using both means the renderer picks per draw rather than committing to one model.

The backend situation is the project's clearest limitation and the README is upfront about it. Vulkan is the one backend described as implemented. Direct3D 12 and Metal are listed under currently being worked on, alongside push constants, bindless resources, reserved resources, a frame graph and memory aliasing as backend enhancements.

So today the framework targets Windows with Vulkan, and the other two paths are work in progress. For anyone whose shipping target is macOS or a console, that is decisive and no amount of framework quality changes it.

The next renderer work is listed in detail and tells you how much of the current renderer is transitional: all shaders modernized with a new BSL 2.0 shader language, large coordinate support, view-relative rendering, reverse Z, occlusion culling, instanced rendering, GPU scene structures, virtualized geometry, mesh simplification and LODs. Reverse Z and view-relative rendering are depth precision and numerical stability work, which is the kind of change that alters shaders and material setups rather than just improving them.

Beyond rendering: UI, C# scripting, physics, audio and asset import

The feature line describes the framework as feature rich and lists an integrated UI system, C# scripting, physics, animation, audio and asset import for all popular formats. That list is the reason to treat B3D as an engine rather than a renderer, and it is also the reason its adoption cost is higher.

C# scripting means a managed runtime and a hosting boundary between the C++ engine and the game logic, plus whatever deployment story that implies on each platform. A framework that also owns physics, animation and audio owns the update order between all of them, which removes decisions you might otherwise want to make yourself.

Asset import for popular formats is similarly double-edged. It removes a build step you would otherwise maintain, and it puts a proprietary intermediate format between your art pipeline and the engine.

Further out, the list includes a rebuilt Banshee 3D editor, real-time global illumination, high level networking, and Recast and Detour nav-mesh integration. That ordering identifies the editor as a future rebuild.

The authoritative detail is not in the README. The project points at `Documentation/GitHub/features.md` for a detailed list of currently available features and `Documentation/GitHub/ReleaseNotes.md` for what changed in each release. Both are in the repository, so the claims above can be checked rather than taken on trust.

Getting started without version tags

There is no install command to copy, and the project does not pretend otherwise. Getting started consists of three pointers.

Documentation is at docs.banshee3d.io, with a Manuals section for learning the framework from the ground up and an API reference for looking up a particular class or method. Building from source is documented in `Documentation/GitHub/compiling.md`, which is the file to follow given that the build entry point is a `CMakeLists.txt` at the root. Working examples live in a separate repository, GameFoundry/B3DFrameworkExamples, described as well documented and suitable for learning the framework by reading and tinkering.

The lack of GitHub releases is the part that matters for adoption. There is no tag series to pin, so the way to know what changed is `Documentation/GitHub/ReleaseNotes.md` in the tree, which means you are tracking a moving branch and reading a changelog file rather than comparing tags.

The last push to the repository was on 2026-10-16, so development is current. The trade is that current also means the platform list in the README will change, and the Direct3D 12 and Metal backends named as in progress may appear without a version bump you can pin to.

Editorial conclusion

Engine developers already targeting Vulkan who want an ECS with fiber based scheduling and a modernised renderer should read the feature list and release notes before committing, because the framework covers far more than rendering and the readme says it is still in active development. Anyone needing Windows on Direct3D 12, macOS, Linux or PlayStation 5 today is looking at a port that the project lists as in development. Before evaluating it, build it with CMake following Documentation/GitHub/compiling.md and read ReleaseNotes.md, since there are no tagged GitHub releases to version against.

Frequently asked questions

Official sources

1. GameFoundry/B3DFramework on GitHub
2. Issues
3. License: MIT
4. README