# NativeRenderingPlugin shows how Unity calls a C++ rendering plugin > A Unity sample that implements a native plugin interface in C++ across D3D11, D3D12, Vulkan, Metal and OpenGL, drawing a triangle and editing Unity textures and meshes in place. It is teaching code, not a framework, and it says so. **Unity-Technologies/NativeRenderingPlugin** — C++ Rendering Plugin example for Unity - Repository: https://github.com/Unity-Technologies/NativeRenderingPlugin - Website: https://docs.unity3d.com/Manual/NativePluginInterface.html - Stars: 950 · Forks: 189 - Language: C - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/unity-technologies-nativerenderingplugin ## A sample, and the README admits it NativeRenderingPlugin is a C++ rendering plugin example for Unity, and the project is unusually honest about its scope. The README says the plugin itself does very few things, and then lists them. What it demonstrates is the plumbing. How to initialize the graphics API, and how calls from Unity into the plugin are made. The mechanism is Unity's native plugin interface, the documented C entry point that lets managed code call into a shared library, and the sample implements that interface against several graphics APIs. That makes it a teaching artefact for a specific audience. If you are a graphics engineer who has been asked to move a rendering path out of Unity and into native code, or a tools engineer who needs to know what Unity passes across the boundary and how to get hold of it, the sample answers those questions with working code rather than with prose. It is not a rendering framework. There is no abstraction layer to build on, no scene graph, no shading model, and no promise that the API surface will stay stable. The project is hosted by Unity Technologies, which tells you who maintains it, and the licence is MIT/X11, the same terms as most Unity samples. The repository itself is small. The top level contains a LICENSE, a README, the PluginSource/ directory and the UnityProject/ directory, and there are no GitHub releases, so the state of the code is whatever the default branch holds. ## Three demonstrations, each one a different Unity to native handoff The sample covers three scenarios, and each one exercises a different part of the interface. The first is the plumbing itself, and it is what a reader should study first. Initializing the graphics API from native code and being called from Unity is where most of the mistakes happen, because the graphics API has to be brought up on the right thread with the right device, and Unity has its own device it does not share. The second is the smallest complete render, a single coloured rotating triangle in the middle of the screen. The point of the triangle is not the triangle. For each backend API it shows the bare basics of setting up vertex data, setting up some shaders or render states, and issuing a draw call. A triangle is the right size of problem because anything else would hide the interesting part. The third and most instructive demonstration is the one that touches Unity's own data. Unity passes a texture into the plugin and the code changes its pixels every frame with an animated plasma pattern, which shows how to work with Texture.GetNativeTexturePtr. In the same spirit, Unity passes a vertex buffer into the plugin and the code changes the vertices each frame with an animated heightfield pattern, which shows how to work with Mesh.GetNativeVertexBufferPtr. Both of those are the mechanism worth stealing. The plugin is not writing into a copy of the asset; it is handed a pointer to the memory Unity already owns and edits it in place, per frame, and Unity sees the result. That is the part that is hard to discover on your own, and it is why the sample edits pixels and vertices rather than only drawing a triangle of its own. ## RenderingPlugin.cpp and the RenderAPI files The code is organised so that the platform specific parts are easy to find, which is the correct shape for a sample that has to cover this many backends. The source directory holds RenderingPlugin.cpp, which the README names as the main logic, alongside the RenderAPI files, which contain the rendering implementations for different APIs. The split is the important detail. Everything that has to differ between graphics APIs lives in the RenderAPI layer, and the main file holds the logic that does not: initialisation, the frame loop, and the parts of the interface Unity talks to. That means adding a backend is a matter of writing a new RenderAPI implementation, and reading the sample as a whole tells you how much work a backend actually is. A backend has to set up vertex data, shaders and render states, and be able to issue a draw call against whatever device Unity gave the plugin. The one thing the sample does not do is abstract over the differences. There is no common interface that a custom backend implements, because the README describes the RenderAPI files as separate implementations rather than as plugins of one interface. If you are planning to support several graphics APIs yourself, expect to write and maintain that layer yourself, and expect to consult each API's own documentation for the details the sample deliberately leaves out. ## Platform coverage, and the two defines you have to edit by hand The list of supported platforms and graphics APIs is long, and the two Windows entries that are not compiled in by default are the first thing to look at. Windows covers D3D11, D3D12, OpenGL and Vulkan, with the note that Vulkan and DX12 are not compiled in by default. Enabling Vulkan means editing the value of a define under the UNITY_WIN clause in PlatformBase.h, changing the 0 to a 1, and having the Vulkan SDK installed. Enabling DX12 is the same edit against the D3D12 define, and it additionally requires extra header files, which the README points at either the DirectX-Headers repository on GitHub or the Microsoft.Direct3D.D3D12 nuget package at version 1.4.10. The other platforms are listed with their APIs: macOS on Metal and OpenGL, Linux on OpenGL and Vulkan, Windows Store, also known as UWP, on D3D11 and D3D12, WebGL on OpenGL ES, Android on OpenGL ES and Vulkan, iOS and tvOS on Metal, EmbeddedLinux on OpenGL, OpenGL ES and Vulkan, and QNX on OpenGL ES. The macOS project notes that Xcode 10.3 on macOS 10.14 was tested, and that the iOS Simulator is supported if you use unity 2020+ and Xcode 11+. There is a catch-all line at the end saying that more platforms might be coming soon but the project files have not been added yet. Read that as a scope statement rather than a promise. The two defines are the whole configuration story for Windows, and they are worth looking at before anything else if your target is Vulkan or DirectX 12, because a sample that ships with the backend disabled will look broken rather than unconfigured. The two switches live in PlatformBase.h under the UNITY_WIN clause: ```c #define SUPPORT_VULKAN 0 #define SUPPORT_D3D12 0 ``` Change the 0 to a 1 for the backend you need, rebuild the plugin for the platform you are targeting, and the corresponding RenderAPI implementation becomes reachable. ## The IDE project files, including the awkward platforms PluginSource contains the source and the IDE project files, and the project file list is organised by target rather than by IDE, which is what you would expect once a sample has to build on four operating systems. For Windows there are two Visual Studio 2022 projects: a regular Windows plugin and a separate one for the Windows Store, or UWP, plugin. For Apple platforms there is an Xcode project file for the macOS plugin. For Linux there is a Makefile, and there is a dedicated EmbeddedLinux directory that contains Windows .bat files to build the plugin for different architectures, which is an unusual choice and one that tells you the author built the embedded target from a Windows machine. The QNX directory holds a Makefile for Linux, and the README is specific about its requirement: QNX has to be installed and the environment variables have to be set. That is a fair summary of what cross compiling to a QNX target costs. The Unity side is deliberately minimal. UnityProject holds the Unity project, with 2023.1.15f1 recorded as the tested editor version, and it contains a single scene that holds the plugin sample scene. One scene is the right amount of scene for a sample, since it removes any question about what needs configuring before the sample runs. The whole layout is therefore navigable in a few minutes. PluginSource/source for the logic, PluginSource/projects for the build system, UnityProject for the scene that drives it, and PlatformBase.h for the two Windows switches. ## Unity version support, licence terms and the state of the tree The version story is short and worth repeating exactly. For Unity 2023.1 and newer, use the tip of the default branch. The default branch of the repository is master, and there are no GitHub releases, so there is no tagged version to pin to and no changelog to check against. The last push was on 2026-08-10 and the repository is not archived, so the code is there to read, but the absence of releases means there is no support commitment attached to a version. If you need a stable point, note the version of the sample you start from, since the tip can change under you. The licence question is settled. The README states that just like with most other samples, the licence is MIT/X11, and the repository carries a LICENSE file. In practical terms, you can read the code, adapt it and ship it inside a project, including a commercial one, and the only obligation is to keep the notice. This is a description of the terms as written, not advice on how to apply them. One limitation belongs in any evaluation of this project. The sample covers a narrow slice of the native plugin interface: initialisation, a draw call, and direct edits to texture and mesh memory. It does not cover threads, asynchronous GPU work, resource lifetimes across a frame boundary, or how the plugin behaves during a device loss, and the README does not mention any of those. Anyone planning to build a real native rendering path on top of this will be leaving the sample behind quickly, which is a fine outcome as long as you expected that from the start. ## Conclusion NativeRenderingPlugin is worth reading when you need to move rendering work out of Unity and into your own native code, because it shows the whole chain, from Unity handing over a native texture pointer to the plugin issuing a draw call on a chosen graphics API. It is the wrong starting point if you want a maintained engine abstraction, since the project is an example whose own README describes it as doing very few things, with platform support that has to be switched on by hand. Verify the two things that will bite you first: the Unity version in your editor against the 2023.1 or newer requirement, and whether the backend you need is actually compiled in, since Vulkan and D3D12 on Windows ship disabled until you edit the defines in PlatformBase.h. ## FAQ ### Which Unity versions does the NativeRenderingPlugin sample support? For Unity 2023.1 and newer, the README says to use the tip of the default branch, which is master. The included Unity project was tested with editor version 2023.1.15f1. ### How do I enable Vulkan or DirectX 12 on Windows? Both are disabled by default. Edit the define under the UNITY_WIN clause in PlatformBase.h, changing `#define SUPPORT_VULKAN 0` or `#define SUPPORT_D3D12 0` to 1. Vulkan needs the Vulkan SDK, and D3D12 additionally needs the extra header files from DirectX-Headers or the Microsoft.Direct3D.D3D12 nuget package. ### Does the sample run on the iOS Simulator? Metal is the API used for iOS and tvOS, and the README states the Simulator is supported if you use unity 2020+ and Xcode 11+. ### What licence is the NativeRenderingPlugin sample under? The README states that, like most other samples, the licence is MIT/X11, and the repository includes a LICENSE file. ## Sources - [Issues](https://github.com/Unity-Technologies/NativeRenderingPlugin/issues) - [License: MIT](https://github.com/Unity-Technologies/NativeRenderingPlugin/blob/master/LICENSE) - [Project website](https://docs.unity3d.com/Manual/NativePluginInterface.html) - [README](https://github.com/Unity-Technologies/NativeRenderingPlugin/blob/master/README.md) - [Unity-Technologies/NativeRenderingPlugin on GitHub](https://github.com/Unity-Technologies/NativeRenderingPlugin) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/unity-technologies-nativerenderingplugin