R3D: a 3D extension library that keeps raylib a library

The design constraint that shapes everything

R3D is an extension library for raylib that expands its 3D capabilities, including rendering, lighting, kinematics, mesh utilities and related helpers, without turning raylib into a full engine. That last clause is the interesting constraint. The point of raylib is that you keep control of the frame loop, the scene graph and the asset handling, and a 3D layer that quietly takes those over has changed the nature of the thing you depend on. So R3D presents a C API with prefixed function names, and the examples show the shape of it clearly: you still call InitWindow and SetTargetFPS yourself, you still run the while loop and BeginDrawing, and R3D brackets the rendering with R3D_Begin and R3D_End. The library is C, licensed under the Zlib licence, and the current release line is v0.11.0 from 2026-08-10, after v0.10.0 in June and v0.9.1 in April.

Building it, and the vendored option

The requirements are three, and two of them can be handled for you. You need raylib 5.5 or newer, Assimp 6.0.2 or newer, both of which can be provided optionally as submodules, and Python 3.6 or newer, which is used to process shaders during compilation. The quick build clones with submodules and configures CMake to vendor both dependencies.

git clone --depth 1 --recurse-submodules https://github.com/Bigfoot71/r3d
cd r3d
mkdir build && cd build
cmake .. -DR3D_RAYLIB_VENDORED=ON -DR3D_ASSIMP_VENDORED=ON
cmake --build .

The two options in the configure step are what make the clone-and-build path work without you first installing raylib or Assimp yourself, and the fact that the clone needs the recurse-submodules flag is the visible hint that they arrive that way. If you would rather not go through this at all, the project points at r3dStarter, made by Jens Roth, as a ready-made starting point. To use the library rather than build it, the required specification on the hardware side is OpenGL 3.3 or newer with support for GL_ARB_texture_cube_map_array, which is the extension behind the cube map arrays the image-based lighting needs.

A first frame, and the shape of the API

The quick start program is short enough to read in full, and every line of it tells you where the boundary between raylib and R3D falls.

#include <r3d/r3d.h>
#include <raymath.h>

int main(void)
{
    InitWindow(800, 600, "R3D Example");
    SetTargetFPS(60);

    R3D_Init(800, 600);

    // Create scene objects
    R3D_Mesh mesh = R3D_GenMeshSphere(1.0f, 16, 32);
    R3D_Material material = R3D_GetDefaultMaterial();

    // Setup lighting
    R3D_Light light = R3D_CreateDirLight((Vector3) {-1, -1, -1}, WHITE, 1.0f);

The window belongs to raylib, the target frame rate belongs to raylib, and the mesh and material are R3D types with R3D prefixed functions. A directional light is created with a direction vector, a colour and an intensity, and the default material comes from the library rather than from a struct you fill in yourself. The camera is a plain raylib Camera3D with designated initialisers, which is a small but meaningful detail, because the camera type is raylib's own and the R3D_Begin call takes it.

    // Camera setup
    Camera3D camera = {
        .position = {3, 3, 3},
        .target = {0, 0, 0},
        .up = {0, 1, 0},
        .fovy = 60.0f,
        .projection = CAMERA_PERSPECTIVE
    };

    // Main loop
    while (!WindowShouldClose()) {
        UpdateCamera(&camera, CAMERA_ORBITAL);
        BeginDrawing();
          R3D_Begin(camera);
            R3D_PushLight(light);
            R3D_DrawMesh(mesh, material, Vector3Zero(), 1.0f);
          R3D_End();
        EndDrawing();
    }

    R3D_UnloadMesh(mesh);
    R3D_Close();
    CloseWindow();
    return 0;
}

The frame loop is still yours. The camera is updated with raylib's own UpdateCamera in orbital mode, the drawing is bracketed by raylib's BeginDrawing and EndDrawing, and R3D_Begin and R3D_End sit inside them with the camera passed in. A light is pushed for the scope of the draw call and the mesh is drawn with a material, a position and a scale. Teardown is explicit too, with the mesh unloaded, R3D closed and then the window closed, in that order.

The renderer and the material system

The rendering model is described as a hybrid renderer, a deferred pipeline with forward rendering for transparency. That combination is the pragmatic one rather than the pure one, and the reason is that transparent surfaces do not sort correctly in a deferred pipeline, so they are drawn in a forward pass instead. The material system is described as complete PBR, with Burley and Schlick GGX as the named models, which tells you the specular response is not a hacked approximation. On top of that sits custom shader support in three categories, surface shaders for materials and decals, sky shaders and screen shaders, so the extension points are separated by the stage of the pipeline they act on. The example directory reflects that split, with separate files for pbr, decal, skybox, shader, sun, lights, probe and bloom, which is a good way to see what is meant by each of those terms.

Lighting, reflections and the post-processing stack

Dynamic lighting covers directional, spot and omni lights with soft shadows, and the examples directory has a file for each of those, plus sun.c for the directional case in a fuller scene and multiview.c. Image-based lighting supports environment IBL and reflection probes, with probe.c as its example and a sponza.c example that presumably loads the well known test scene. The post-processing list is long enough to define the project's ambition on the graphics side: SSAO, SSGI, SSR, depth of field, bloom, fog and tonemapping, with dof.c, bloom.c and the others in the examples directory. The performance side of the feature list is also graphics-facing rather than engine-facing, with built-in frustum culling and instanced rendering, and instanced.c as the example.

Kinematics, meshes and model loading

The non-rendering half of the library is smaller but still there. Kinematics support is described as a basic kinematic system with capsule and mesh-based colliders, and kinematics.c is its example. Mesh utilities cover mesh generation, manipulation and helper utilities, which in practice means the procedural mesh generators that show up in the quick start, since R3D_GenMeshSphere is called there to make a sphere without an asset file. Model loading is Assimp integration with animations and mesh generation, and the example directory carries animation.c and animtree.c for the animation side, which is a separate concern from the loader itself. The top level of the repository also holds an assets/ directory, a shaders/ directory and a docs/ directory, alongside src/, include/, cmake/, scripts/, external/ and a CMakePresets.json.

Bindings, and the warning above all of it

Three language bindings are listed, all tracking the same R3D version of 0.11.0. r3d-cs is a C# binding under the Zlib licence, ray4laz_r3d is a FreePascal one under MIT, and r3d-odin is an Odin binding under Zlib. The project invites a pull request for any binding not in the list, which is a reasonable way to keep the table honest. And above all of this sits a warning worth reading before anything else in the readme. It is recommended to use the pre-release tags, and while you can use the master branch, unexpected API breaking changes may occur until the first official release is published. That single note reframes the whole project, because it says the API you write against today may change without a major version bump. For a library whose value is that it stays out of your way, that is the one thing to plan around, which is why the recommendation is to pin a tag rather than track a branch.

Editorial conclusion

R3D fits a raylib user who has outgrown the immediate mode 3D helpers and needs shadows, PBR materials, reflections and post-processing without leaving the C API they already know, and it fits anyone who wants raylib as a layer under their own renderer rather than a framework on top of it. It does not fit a project that needs to stay on the master branch of the stable API, because the project warns that unexpected API breaking changes may occur until the first official release, and the recommended route is the pre-release tags. It also does not fit a machine below OpenGL 3.3 or one without GL_ARB_texture_cube_map_array, and it does not fit a team that wants a managed language, since the library is C with the shader processing step done in Python. Before you build, note the three requirements, raylib 5.5 or newer, Assimp 6.0.2 or newer and Python 3.6 or newer, and read the ROADMAP and GUIDELINES files that sit at the top of the repository, since they tell you where the project is heading.

Frequently asked questions

Official sources

1. Bigfoot71/r3d on GitHub
2. Issues
3. License: Zlib
4. README
5. Releases