Preparing Add-Ons for Publishing

On Add-On Store, you can only upload UPACKAGE files created using UNIGINE Editor.

The add-on package you are going to add should comply with the requirements listed below, otherwise it will be declined by UNIGINE moderators.

Naming Convention

Package Name

The package file is named automatically based on the data you enter when creating the add-on. Therefore you can upload a UPACKAGE file with any name.

Binary Name

Binary name should contain the <DeveloperName><PluginName> line and the following indications:

  • Plugin type: _plugin or _editorplugin
  • Precision: _double for double precision, nothing - for single precision
  • Development version: d for debug, nothing - for release

Binaries for Linux also have the lib  prefix.

Thus, the general name structure is as follows:

Windows: <DeveloperName><PluginName>_plugin_double_x64d.dll

Linux: lib<DeveloperName><PluginName>_plugin_double_x64d.so

Sample on either OS: <AddonName>_double_x64d.exe

Here are some examples:

For Windows

  • UnigineWeather_plugin_double_x64.dll  — release double precision plugin
  • NewtonApple_plugin_x64d.dll  — debug float precision plugin
  • MobiusStrip_editorplugin_double_x64d.dll  — debug double precision editor plugin

For Linux

  • libFerrariCarPaint_plugin_x64.so  — release float precision plugin
  • libBobMarleyGuitar_editorplugin_double_x64d.so  — debug double precision editor plugin

Samples

  • WeatherSample1_x64.exe  — release/development float precision application
  • WeatherSunshine2_double_x64.exe  — release double precision application
  • WeatherRain_x64d.exe — debug float precision application
  • Weather5_double_x64d.exe  — debug double precision application

Folder Structure

The add-on can contain binaries, source files, content files, or their combination. Therefore, files inside the package should be located in the following folders depending on their type:
  • bin/plugins/<DeveloperName>/<PluginName>/
    → plugins and editor plugins binaries
  • bin/<DeveloperNameAddonName>/
    → add-on samples and launchers to launch these samples
  • data/plugins/<DeveloperName>/<PluginName>/
    → plugin-related content files
  • data/<DeveloperNameAddonName>/
    → content files and C# components
  • include/plugins/<DeveloperName>/<PluginName>/
    → files required to compile a user application (required mostly for plugins using the third party libraries; editor plugins don't require any includes)
  • lib/plugins/<DeveloperName>/<PluginName>/
    → third-party libraries for linking with the user application
  • lib/<DeveloperNameAddonName>/
    → third-party libraries for the addon development.
  • source/plugins/<DeveloperName>/<PluginName>/
    → asset source files (logic, plugins, configs)
  • source/<DeveloperNameAddonName>/ → source files for samples
  • docs/plugins/<DeveloperName>/<PluginName>/
    → readme, license and any other plugin-related info files
  • docs/<DeveloperNameAddonName>/
    → readme, license and any other info files related to running the sample or using the content files

This would help customers easily find the added package assets inside their project.

The above folder structure represents an exhaustive set of folders. Add only the folders that are necessary for your package.

The best practice is to create the corresponding folder at the development stage and collect all required files there.

Plugin Compilation Recommendations

  • The plugin can only be written in C++.
  • The application logic can use C# components.
  • For compatibility and stable performance of UNIGINE Editor, the editor plugin should be built with Qt 5.12.3 (otherwise it will crash).
  • Any *.lib files required for plugins should be added to bin/plugins/<DeveloperName>/<PluginName>/.
  • Debug plugins and any binaries should be compiled as release ones containing debug info with debug information and optimization as in debug binaries.

On Windows:

  • Specify the compiler flag /MD .
  • The minimum system requirement is MSVC2015, we recommend complying with it. However, if your package has any limitations, provide the information on the compiler version required for the user's application in the package documentation.

On Linux:

  • Specify the compiler flag -fPIC  and optimization options -O3 for Release and Development.
  • Debug binaries are compiled with the flags -O2  and RelWithDebugInfo

Preparing Content

If your add-on only contains 3D models, textures, materials, nodes, C# components or anything else that refers to assets, these files should be located in the project data/<DeveloperNameAddonName>/ folder.

The content used by the plugin should be located in the project data/plugins/<DeveloperName>/<PluginName>/ folder.

The UPACKAGE file to be uploaded as an add-on is created from this folder as described here.

Preparing Binaries

  • Build the binaries for:

    • Release version
    • Debug version
    • Required precision — float/double/both
    • Required platform — Windows/Linux
  • Check that binaries are named according to the naming convention.

  • Place libraries, their dependencies, and pdb for debugging to the corresponding subfolder in the bin/ folder:

    • binaries for the plugin: bin/plugins/<DeveloperName>/<PluginName>/
    • binaries and launchers for samples: bin/<DeveloperNameAddonName>/

Preparing Source Code

C# components are stored in the data/ folder.

Source code files should be located in the corresponding folders.

For example, the plugin-related files should be in the following folders:

  • All source files required for the assembly: source/plugins/<DeveloperName>/<PluginName>/
  • Includes (if any): include/plugins/<DeveloperName>/<PluginName>/
  • Any *.lib files (mostly third-party libraries):   lib/plugins/<DeveloperName>/<PluginName>/
  • README.md :   docs/plugins/<DeveloperName>/<PluginName>/. The readme file should contain the information on how to use the project.

The sample-related files should be stored in the corresponding <DeveloperNameAddonName>/ folders:

  • Source files:
    source/<DeveloperNameAddonName>/
  • Readme files:
    docs/<DeveloperNameAddonName>/

Other files (if any) are located similarly in the corresponding folders.

Preparing a complex package (contains code, binaries, and content)

The complex package containing various types of files must follow the folder layout.

Creating the Package

The add-on is provided as a *.upackage file created via UNIGINE Editor as follows.

  1. In the Asset Browser, right-click on a folder that is going to be a part of your package and select Export As Package in the context menu.

    The Export Package option is also available via the Packages menu in UNIGINE Editor:

    The Export Package window will open:

  2. Select all files that you are going to provide as a package. Make sure that the Include Dependencies option is enabled.
  3. If you need to add more than one folder, click the Add Files From Asset Browser button.
  4. For adding any files upstream the data/ folder (i.e. files from the bin/ , include/ , lib/ , source/ , and docs/ folders) use the Add External Files button.
  5. Upon selecting all files required for your add-on, click Export Package.
  6. Set the package file name and storage path and click Save.

Content Requirements

  • Add-Ons must not enable the delivery of services.
  • Add-Ons must not be inaccurate, fraudulent, false, misleading, or deceptive; harmful, obscene, pornographic, defamatory, vulgar, or offensive; racist, violent, harassing, or otherwise objectionable to UNIGINE or End Users; promoting illegal or harmful activities or substances.
  • Add-Ons must not violate intellectual property rights or any other rights of any third party.
  • Add-Ons must not violate, or encourage any conduct that would violate, any applicable law or regulation or would give rise to liability of any kind; or be subject to injunction.
  • Add-Ons must not be distributed by Provider improperly.
  • Add-Ons must not create liability for UNIGINE.
  • Add-Ons must not have a virus or be malware, spyware or have an adverse impact on UNIGINE.
  • Any images, text and materials that are intended to market the add-on that Provider has uploaded to Add-On Store must comply with the requirements of the User Agreement. Such materials must be truthful, accurate and must not misrepresent the Add-On, for example — without limitation — by way of screenshots that do not match the content of the Add-On.

FAQ

Question:  What can be uploaded to the Add-On Store?

Answer:  In short, anything that can help users make their project on UNIGINE. More specifically:

  • Editor plugin
  • Engine plugin
  • Auxiliary libraries integrated into the user's project (or with an integration example)
  • Various 3D models configured for UNIGINE (*.node)
  • Preconfigured UNIGINE materials
Question: Can I make a 3D model on 2.17  and specify that it is compatible with 2.18 ?

Answer: Content can be automatically migrated in UnigineEditor, but we recommend updating the content packages for every major SDK version. This will allow improving the add-on appearance using the new engine functionality.

Question: Can I make an add-on on 2.17  and specify that it is compatible with 2.16 ?

Answer: There is no backward migration. You can only upgrade an add-on to a higher SDK version.

Question:  Which SDK version should I use to create the graphic content that is compatible with all possible versions?

Answer: It is impossible to have an add-on compatible with all versions. The add-on should have at least the same major version.

Question: How should I add an engine plugin or an editor plugin with different precisions?

Answer: A common practice in UNIGINE is to use the corresponding postfix in the name of the executable file. The name can be set at the build stage, for example DeveloperNamePluginName.dll for float precision and DeveloperNamePluginName_double.dll for double precision.

Question: I am an artist. How should I prepare the art content add-on?

Answer: Check this section.

Question: Can I create an add-on that contains a plugin and art content?

Answer: Yes, the creation process is described here.

Question: I have a library/framework for game logic/physics. Do I have to make an engine plugin to use this library in the user app?

Answer: This is up to you to decide how you are going to provide your add-on to users.

Question: How long will my add-on versions be stored on the Add-On Store?

Answer: At the moment this period is not limited, any changes will be delivered as a part of changes in the User Agreement.

Question: Where should I add legal information (3-party libraries, disclaimers, etc.)?

Answer: In the add-on description and/or in the docs/plugins/DeveloperName/PluginName/  folder inside the package.

Question: Can I upload sources of the engine plugin or editor plugin?

Answer:  Yes, if there is no copyright infringement.

Question: How can I provide a demo/trial version of the add-on to the end user?

Answer:  At the moment there is no built-in function. As a workaround, you can publish two different add-ons: one is a free demo version and another is a paid full-functioning add-on (for example “Add-On Name (Demo)” and “Add-On Name”).

Question: How can I receive the user feedback?

Answer: Currently the feedback option is unavailable, but we are working on it.

Question: Can I create an add-on from a free third-party item and sell it?

Answer: Yes, if there is no license violation. If a third-party license does not allow selling but allows distributing it for free, then you can upload the add-on to the Add-On Store for free with examples of integration into a custom application.

Question: Is there any charge for the storage of uploaded add-ons?

Answer: At the moment there's no charging. Any changes will be delivered as a part of changes in the User Agreement.
What's on This Page:

Page Top