RenderPipeline: deferred rendering and PBR for the Panda3D engine

What the pipeline is for

RenderPipeline is a deferred realtime rendering pipeline with physically based shading for the Panda3D game engine, and the README is direct about what it adds to an engine that does not otherwise have it.

The README's core feature list has five entries. Physically based shading, so that materials respond to light the way physical surfaces do rather than the way a fixed formula says they should. Deferred rendering, which means the geometry pass writes to buffers and the lighting is computed afterwards, which is what makes many lights affordable. An advanced post-processing effects framework. And a plugin system, so the effect stack is extensible rather than hard-coded.

There is also a time of day system, and the screenshots make it clear what that means in practice. There is a forest scene, a material demo, a screen space reflections shot, a car rendering, a plugin and time of day editor, and a terrain and volumetric clouds shot. The editor screenshot is the one worth pausing on, because a time of day system usually means a directional light that moves, a sky model that changes with it, and a set of parameters the artist can adjust, and having a UI for those parameters is what separates a lighting rig from a lighting tool.

The project is written in Python with GLSL for the shaders, and the topics attached to it are deferred-rendering, glsl, opengl, and panda3d-game-engine. The licence is a custom one that GitHub cannot classify, and the setup.py carries the MIT licence text with a 2014 to 2016 copyright, so the LICENSE.txt file in the repository is what governs.

The last push to the repository was on 2026-07-19, and the published releases are v2.0-pre, v1.0-release, and v1.0, all dated 2016-01-16.

The requirements, and the hardware line that will stop you

The requirements section is short and one line in it is effectively a compatibility statement.

You need an OpenGL 4.3 capable GPU and drivers. You need a Panda3D development build, not a release. And 1 GB of graphics memory is recommended, with the note that it can run with less depending on the enabled plugins and the resolution.

The development build requirement is not a detail. The README asks for a development build rather than a release, and the pipeline depends on engine code that a development build can change under you. That is a cost of the approach and it is worth knowing before you start.

The OpenGL 4.3 requirement is where the project draws a hard line, and it does so explicitly. The README states that the drivers for Intel HD Graphics on Linux are not capable of all 4.3 features, so the pipeline is not able to run there. That is a specific piece of information, because Intel integrated graphics is exactly the hardware a lot of people have, and the failure would otherwise be a confusing rendering bug rather than a clear refusal to start.

The C++ modules are an optional extra, and the documentation points at a wiki page for building them, which lists their own requirements. So the C++ path is separable, and the pure Python and GLSL path is the one with the documented requirements above.

The project also links to two reference pages outside the repository, a feature list in the wiki and a Trello board for the roadmap, which is how the author tracks what he intends to implement.

The directory layout, and what each part is

The top level entries describe the architecture more clearly than the README does, because the names divide the system along the lines the renderer actually has.

There is rpcore/, which is the pipeline core, and rplibs/, which is the bundled third-party libraries. The vendoring is visible in the setup.py, which imports input from rplibs.six.moves and initialises colour output from rplibs.colorama. So six and colorama are vendored rather than declared as dependencies, which is the pattern of a project that has to run on whatever Python the user has, including old ones.

There is rpplugins/, which is the plugin system, and effects/, which is the effect implementations. There is toolkit/, which is the editor tooling, and the two top level scripts start_daytime_editor.py and start_plugin_configurator.py, which are the two editors seen in the screenshots.

There is data/, which holds the assets, and config/, which holds the configuration. The samples/ directory has its own README and a download_samples.py script, so the sample content is fetched rather than committed, which keeps the repository small when the assets are large.

The __init__.py at the top level and the setup.py together make it a Python package, and the .flake8, .pylintrc, and .travis.yml are the linting and CI setup for a project whose code is Python but whose output is a GPU pipeline.

The naming convention here is the informative part. In a typical renderer the equivalent directories would be called something like shaders, core, and plugins, and the fact that this one uses rp-prefixed names and an rplibs for vendored code suggests a project designed to be installed into a Panda3D application as a package, with the prefix keeping it from colliding with the host project's own modules.

Deferred rendering, and what it changes about a project

It is worth being clear about what adopting this pipeline actually commits you to, because deferred rendering is not a drop-in material system.

In a forward renderer, each object is shaded as it is drawn, and the shader is given the lights it is affected by. That is simple and it has a known limit: the cost of shading an object scales with the number of lights hitting it, and a scene with many dynamic lights gets expensive quickly.

In a deferred renderer, the geometry pass writes position, normal, and material properties into buffers, and a separate lighting pass then computes the final colour for every pixel using all the lights at once. The benefit is that many lights become affordable and the post-processing stage gets a set of screen-space buffers to work with, which is what the screen space reflections and the effect framework need.

The cost is that you cannot do transparency or multi-layer geometry in the deferred pass, so those have to be handled in a forward pass afterwards, and the memory cost is real, which is where the 1 GB graphics memory recommendation comes from.

For a Panda3D project specifically, the important part is the shader and material model. The pipeline implements physically based shading, so the material authoring model is different from Panda3D's built-in one. An existing project with its own material setup would be rewriting how its surfaces look, not swapping a rendering backend.

The plugin system, and where the real documentation lives

The README is a short document, and it says so. The wiki is where the substance is, with a WIKI link and a separate Getting Started page, and the feature list and the roadmap are both hosted off the repository. That is a normal shape for a project whose documentation is a wiki rather than a docs directory.

The plugin system is one of the core features, and the two top level scripts are its user interface. start_plugin_configurator.py is the plugin editor and start_daytime_editor.py is the time of day editor, and the screenshot of the plugin and time of day editor shows them side by side, which is the point of a configurator rather than a config file.

For a project of this kind, a plugin system is not a convenience, it is a necessity. The effect stack in a deferred pipeline is where the visual character of a game comes from, and every engine has a slightly different opinion about how that stack is configured. Making it a plugin system means the pipeline can be adapted to the host project's conventions rather than requiring the host project to adopt the pipeline's.

The samples directory is worth mentioning too, because the download_samples.py script and the separate README suggest the sample content is a curated set that changes over time, with a manifest rather than a fixed collection.

One detail about the project is worth flagging for anyone assessing maintenance: the tagged releases are all from 2016, and the v1.0, v1.0-release, and v2.0-pre tags were published on the same day, which is the signature of a maintainer tagging a batch of work at a point in time rather than following a release cadence. The last push in July 2026 shows the code is still being touched.

Editorial conclusion

Adopt RenderPipeline if you are building a Panda3D project that needs modern lighting and post-processing and you have the OpenGL 4.3 hardware to run it. Do not adopt it if you need a maintained tool, since the tagged releases stop in 2016 and the wiki is where the real documentation lives. Verify first that your GPU and drivers reach OpenGL 4.3, because Intel HD Graphics on Linux is explicitly called out as not capable of all of the 4.3 features.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. tobspr/RenderPipeline on GitHub