This page describes Native Code Plugins for desktop platforms (Windows/Mac OS X/Linux). Note that plugins are intentionally disabled in webplayers for security reasons.
On Mac OSX, plugins are deployed as bundles. You can create the bundle project with XCode by selecting and then selecting -> (in XCode 3) or -> -> (in XCode 4)
If you are using C++ (.cpp) or Objective-C (.mm) to implement the plugin then you must ensure the functions are declared with C linkage to avoid name mangling issues.
extern "C" {
float FooPluginFunction ();
}
Plugins on Windows are DLL files with exported functions. Practically any language or development environment that can create DLL files can be used to create plugins.
As with Mac OSX, you should declare any C++ functions with C linkage to avoid name mangling issues.
Plugins on Linux are .so files with exported functions. These libraries are typically written in C or C++, but any language can be used.
As with the other platforms, you should declare any C++ functions with C linkage in order to avoid name mangling issues.
The issue of needing 32-bit and/or 64-bit plugins is handled differently depending on the platform.
On Windows and Linux, plugins can be managed manually (e.g, before building a 64-bit player, you copy the 64-bit library into the Assets/Plugins folder, and before building a 32-bit player, you copy the 32-bit library into the Assets/Plugins folder) OR you can place the 32-bit version of the plugin in Assets/Plugins/x86 and the 64-bit version of the plugin in Assets/Plugins/x86_64. By default the editor will look in the architecture-specific sub-directory first, and if that directory does not exist, it will copy plugins from the root Assets/Plugins folder instead.
Note that for the Universal Linux build, you are required to use the architecture-specific sub-directories (when building a Universal Linux build, the Editor will not copy any plugins from the root Assets/Plugins folder).
For Mac OS X, you should build your plugin as a universal binary that contains both 32-bit and 64-bit architectures.
Once built, the bundle should be placed in the folder (or the appropriate architecture-specific sub-directory) in the Unity project. Unity will then find it by name when you define a function like this in the C# script:-
[DllImport ("PluginName")]
private static extern float FooPluginFunction ();
Please note that PluginName should not include the library prefix nor file extension. For example, the actual name of the plugin file would be PluginName.dll on Windows and libPluginName.so on Linux.
Be aware that whenever you change code in the Plugin you will need to recompile scripts in your project or else the plugin will not have the latest compiled code.
For cross platform plugins you must include the .bundle (for Mac), .dll (for Windows), and .so (for Linux) files in the Plugins folder.
No further work is then required on your side - Unity automatically picks the right plugin for the target platform and includes it with the player.
This plugin project implements only some very basic operations (print a number, print a string, add two floats, add two integers). This example may be helpful if this is your first Unity plugin.
The project can be found here and includes Windows, Mac, and Linux project files.
An example multiplatform plugin that works with multithreaded rendering in Unity can be found on the Native Plugin Interface page.
A complete example of the Plugin interface can be found here.
This is a complete Midi plugin for OS X which uses Apple's CoreMidi API. It provides a simple C API and a C# class to access it from Unity. The C# class contains a high level API, with easy access to NoteOn and NoteOff events and their velocity.
An example of how to assign image data to a texture directly in OpenGL (note that this will only work when Unity is using an OpenGL renderer). This example includes both XCode and Visual Studio project files. The plugin, along with an accompanying Unity project, can be found here.
Page last updated: 2013-02-04