# pmtech: a data-oriented C++ engine where the renderer is a script, not a fixed pipeline > pmtech is a lightweight, data-oriented game engine in C++ that runs on Windows, macOS, Linux, iOS, Android and WebAssembly across Direct3D11, OpenGL, OpenGL ES, WebGL 2, Metal and Vulkan. Its distinguishing feature is Pmfx, a scriptable renderer, shader, compute and post-processing system, plus live reloading of C++, shaders and render pipelines. It has no GitHub releases, and the last push was on 2026-07-09. **polymonster/pmtech** — Lightweight, multi-platform, data-oriented game engine. - Repository: https://github.com/polymonster/pmtech - Stars: 926 · Forks: 55 - Language: C++ - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/polymonster-pmtech ## Data-oriented means cache friendly, not just an ECS label pmtech describes itself as a lightweight, multi-platform, data-oriented game engine, and the first thing worth unpacking is what data-oriented means here, because the term is used loosely. The README is specific: the design goal is an instruction and data cache friendly layout for optimal performance. That phrasing points at the memory hierarchy rather than at a scene graph convention. A cache friendly data layout is what lets thousands of entities be iterated over without chasing pointers, and it is the reason the engine can claim an example with 64k data-oriented entities rendered with multiple shadow maps and texture arrays. The feature list makes three claims about weight and structure. The engine is lightweight, with minimalistic, simple APIs and shallow call stacks. It is multithreaded, with async render, physics, audio and the entity component system. And it works at a low level of abstraction, providing input, gamepad, timers, threads, window, operating system and file system services directly. That third point is the design decision that shapes everything else. This is an engine that does not hide the platform behind a comfortable layer. If you are coming from an engine that ships a scene format, a shading system and an editor, the absence of those things is the first adjustment. What you get instead is the machinery, and the wiki is where the conventions live. The primary language is C++, and the repository layout shows a `core/` directory, `examples/`, `tools/`, `third_party/` and `assets/`, which is the shape of a framework with its own asset pipeline and its own tooling rather than a thin library you link against. ## Six graphics backends and four shader languages The platform and rendering support lists are where this project distinguishes itself from a hobby engine. Operating systems covered are Windows on x64, macOS, iOS, Linux on x64, WebAssembly and Android. Compilers listed as supported are vs2017 and later, Clang 6 and later, Apple LLVM 9 and later, Gcc 7 and later, and emcc 2.0 for the WebAssembly path. Rendering backends are Direct3D11, OpenGL 3.1 and later, OpenGL ES 3 and later, WebGL 2.0, Metal and Vulkan. Shader languages are HLSL Shader Model 3.0 and later, GLSL 330 and later, Metal and SPIR-V. The pairing of backend and shader language in one list is significant. Supporting Vulkan means writing SPIR-V, supporting Metal means writing Metal Shaders, and supporting WebGL 2.0 means writing GLSL that a browser will accept. An engine that claims all of these is either abstracting shaders behind an intermediate representation or maintaining parallel shader paths. The README does not say which, and it points to the Pmfx wiki page rather than explaining the shader compilation model. What can be said is that the breadth is real rather than aspirational, because there are live WebGL and WebAssembly samples linked from the README that anyone can open in a browser. A renderer that only runs on one backend cannot be demonstrated that way. The combination of a wide backend list and a scriptable renderer is the interesting part. A fixed pipeline engine would need a different implementation path per backend, and the scriptable approach is what makes a single render graph description portable across Direct3D11, Metal and Vulkan. ## Pmfx, where the render pipeline is written rather than configured Pmfx is described as a scriptable renderer, shader, compute and post-processing system, and it is the feature that most changes how you work with the engine. A conventional engine exposes rendering through configuration and a fixed set of passes. A scriptable renderer exposes the passes themselves. The consequence is that the rendering techniques in the README are not plugins or settings, they are programs written against the engine's rendering API. The examples show the range. There is a scriptable renderer demo that runs 100 lights using forward, deferred or Z-prepass rendering. There is a scriptable post-processing example with ray marched Menger sponges, depth of field and bloom. There is a global illumination example with temporal anti-aliasing, area lights, subsurface scattering, signed distance field shadows and stencil shadow volumes. There is vertex stream out with instanced skinning, PBR, Oren Nayar and Cook Torrence. The shadow techniques alone span directional, spot and point light shadow maps, plus signed distance field shadows and stencil shadow volumes. Global illumination, area lights and subsurface scattering in the same engine, with the same API, is the point of the scriptable design. Pmfx also covers compute and post-processing, which means the same system covers more than the main render pass. The wiki page is the reference. The honest caveat is that this is where the documentation is thinnest in the README itself. It names the system, links the wiki, and shows pictures. If the wiki does not give you a clear mental model of how a render graph is described and when it is recompiled, the feature list is harder to act on than it looks. ## Live reloading of C++, shaders and render pipelines The README lists live-reloading among the features and links a video for it: dynamically reload C++, shaders and render pipelines. This is a bigger claim than the usual hot reload. Most engines reload shaders, and a few reload interpreted script. Reloading C++ means recompiling translation units while the process keeps running, and doing it for render pipelines means the graph itself can change without a restart. For a graphics programmer iterating on lighting or a shader, that removes the edit, rebuild, relaunch cycle that dominates the day. The feature list also mentions an entity component system and a root motion animation system, linked to the ECS source directory. The root motion part is what the example game is built around: Dr. Scientist is described as a demo game using pmtech, with root motion animation and a kinematic physics character controller. ECS is where the data-oriented claim becomes concrete. A component-oriented design with data-oriented storage is what makes the 64k entity example plausible, because iterating components linearly is what keeps the caches warm. There is also a build pipeline component covering project generation, compilation, asset building and packaging, and a tools component covering a graphical editor, a mesh optimiser and a volume texture and SDF generator. A graphical editor alongside a scriptable renderer is an unusual combination, and the mesh optimiser and SDF generator are the kind of small utilities that usually decide whether an engine is usable in practice. ## Getting started means the wiki, and the build scripts live in the repo The README is candid that it is not where you start. It says to take a look at the Building instructions to get started, and that all features in pmtech are demonstrated and unit tested through the examples. That second point is the practical answer for most people. The examples are the documentation. There are 40+ samples and unit tests, and each of the feature demos in the README links directly to a source file in `examples/code/`, so the code that produces a given screenshot is one click away rather than hidden behind a build you have to reproduce first. The repository layout shows the build tooling. There is a `pmbuild` entry and a `pmbuild.cmd` entry at the root, which is the platform split for a Unix style script and a Windows batch file, and a `examples/premake5.lua` file, which points to Premake5 as the project generation tool. The `.ci/` directory holds the continuous integration configuration, matching the build and tests badges in the README, and there is a `.format-all.sh` script next to a `.clang-format` file, so the project enforces a formatting style across the codebase. The wiki pages referenced are Building, Examples, Pmfx, and the ECS source directory. A Discord server and a Trello board are linked in the README badges for ongoing work. The absence of installation steps is not an oversight but a consequence of the design. pmtech is a source engine: you clone it, you generate a project, you build it against your compiler and your chosen backend. There is no binary to download. ## What pmtech is not, and who will be frustrated There are several categories of user for whom this engine is the wrong choice, and being clear about them is more useful than a feature summary. The first is anyone who wants a finished editor and a content pipeline. pmtech has a graphical editor as one of its tools, but the emphasis is elsewhere, on the rendering and engine code. If your workflow is a designer opening a scene editor and clicking, this is not that. The second is anyone who wants a stable, versioned dependency. The repository has no GitHub releases at all, so there is nothing to pin. You take master, and master changes. For a hobby project or a rendering experiment that is fine, and for a commercial title with a QA process it is a serious friction point, because every other dependency in your build has a version and this one does not. The third is anyone who needs a documented, stable API. The engine wiki is the reference and it is maintained alongside the code, but the README itself points out that features are demonstrated through examples and unit tests, which is an admission that the examples are the primary teaching surface. That is fine for a strong C++ programmer who reads code, and it is a barrier for anyone who expects a written API contract. The fourth is a project that does not want to think about graphics at all. An engine with a scriptable renderer rewards engagement with the rendering code. If you want to load a model and move it around, there are many options that ask less of you. There is also a scope caveat on the platform support. The list is broad, but the depth behind each entry is not described. Metal and Vulkan and WebGL are all listed, yet the README does not say which features are complete on which backend. A project targeting a specific backend should read the examples for that backend before committing. ## MIT licensed, self published, and tracked on a Trello board The licence is MIT, stated in the README badge and in the `license.md` file at the repository root. For a game engine that people fork and modify, a permissive licence means you can take the core, change the renderer, and ship without a negotiation, which is a low barrier for commercial work and for engine forks. Maintenance is the more complicated picture, and it should be read carefully. The last push was on 2026-07-09, which is more than three months before the current date. The project is not archived, and there is no statement that development has stopped, but the recent release list is empty because the repository has no GitHub releases. There is nothing versioned to install and nothing to upgrade to. The CI badges show a build workflow and a tests workflow, both of which were running on the code as of the last push. The tests badge is the meaningful one for an engine, because the README states that features are unit tested through the examples, so the example suite is the regression net for the engine itself. The work tracking is public on Trello, and there is a Discord server for discussion. For a project without tagged releases, a public board is where you would find out whether a specific bug is known or scheduled. On the example game, Dr. Scientist is a separate repository at polymonster/dr_scientist, built on pmtech, and it demonstrates root motion animation with a kinematic physics character controller. It is the clearest evidence of what the engine can host, and reading it tells you more about the engine's idioms than the README does. ## Conclusion pmtech suits a C++ graphics programmer who wants to own the whole stack, from the entity component system up to the render graph, and who is prepared to read the wiki and the example sources before writing anything. It is the wrong choice for a team that needs a documented, stable engine with editor tooling and a support community, since pmtech publishes no tagged releases and points to a wiki for its build instructions, and it is the wrong choice for a browser project unless you are prepared to use the WebAssembly target. Verify three things before committing: that the platform and graphics backend you need appear in the supported lists, that you can follow the Building instructions in the wiki, since the README does not reproduce them, and that the absence of versioned releases matches your own release process, because you would be tracking master. ## FAQ ### Which platforms and graphics backends does pmtech support? Operating systems covered are Windows on x64, macOS, iOS, Linux on x64, WebAssembly and Android. Rendering backends are Direct3D11, OpenGL 3.1 and later, OpenGL ES 3 and later, WebGL 2.0, Metal and Vulkan, with HLSL Shader Model 3.0 and later, GLSL 330 and later, Metal and SPIR-V as shader languages. ### How do I build pmtech from source? The README points to the Building instructions in the wiki for the full procedure, and the repository contains a `pmbuild` script, a `pmbuild.cmd` batch file and an `examples/premake5.lua` file, indicating Premake5 for project generation. There is no prebuilt binary to download. ### What is Pmfx in pmtech? Pmfx is the scriptable renderer, shader, compute and post-processing system. The examples include a scriptable renderer with 100 lights using forward, deferred or Z-prepass rendering, and scriptable post-processing with ray marched Menger sponges, depth of field and bloom. ### Does pmtech have versioned releases? No. The repository has no GitHub releases, so there is nothing to pin or upgrade to, and you would track the master branch directly. The last push was on 2026-07-09. ### Can pmtech run in a browser? Yes, through the WebAssembly target, using the WebGL 2.0 rendering backend and emcc 2.0 or later as the compiler. The README links live WebGL and WebAssembly samples you can open in a browser. ### What licence is pmtech released under? MIT, stated in the README badge and in the license.md file at the repository root. The repository also carries a third_party directory and git submodules, which are separate licensing questions from the engine code itself. ## Sources - [Issues](https://github.com/polymonster/pmtech/issues) - [License: MIT](https://github.com/polymonster/pmtech/blob/master/LICENSE) - [polymonster/pmtech on GitHub](https://github.com/polymonster/pmtech) - [README](https://github.com/polymonster/pmtech/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/polymonster-pmtech