[DEPRECATED] Marketplace Submission Guidelines

[Ivey]

The most up-to-date guidelines are available here.

This is post contains general information about preparing your content for submission and Marketplace expectations.

General Marketplace Statements and Submission Process Submission Process
Statement of Intent
Statement of Quality
Statement of Professionalism
Statement of Maintaining Content
Content Types Accepted
Making Blueprint-Only Projects Plugin Friendly

Preparing Your Assets General Asset Requirements - All submissions must follow this guide
Weapons
Materials
FX
Environments

Code Projects

Code Plugins
Characters and Animations
Blueprints
Audio
ArchViz
2D

We’ll be updating this thread as necessary going forward and provide dates when things have changed.

[Ivey]

**Submission Process
**
The first step is to submit information and materials related to your content to be considered for distribution on the Marketplace. The submission process involves three significant steps before on the way to the content appearing for purchase on the Marketplace: initial acceptance, internal QA, and final selection by Epic.

**Initial Submission Requirements
**

• Contact Information (support email required)

• Content title (max 30 characters)

• Short description (max 100 characters)

• Long description (max 1500 characters)

• Tech details (max 1500 characters)

• 5 to 10 screenshots (< 1mb each)

• Pricing in USD (Free content submissions are limited to Plugins or at Epic’s request)

• URL of a video demonstrating the content

• URL of a website specific to the content

**Initial Acceptance
**Upon receiving your summary materials, Epic will review them based on a variety of criteria including quality, value, uniqueness, and suitability to the Unreal Engine community. If your submission meets this criteria, we will request your files to run our internal Quality Assurance tests on.

If discovers issues with your content, we will contact you with more information on how to proceed. If it passes our internal quality checks, we will provide you with the relevant information concerning release.

**Compliance Review
**Upon receiving your complete content package, Epic will verify that it is follows all guidelines and requirements outlined in this document, and test that content adheres to the submission guidelines as well as being functional in the required Unreal Engine versions. If any issues are found at this point, we will reach out to you with further instructions on how to proceed.

**Additional Distribution Requirements
**Please be prepared to provide the following required materials:

• Agreement to provide any Marketplace/blog/marketing or other updates as needed to promote your content.

• Platform Information (Windows, Mac, Linux, Playstation 4, Xbox One, Android, iOS, Oculus Rift, SteamVR / HTC Vive, Gear VR, HTML5)

• Intended Platforms: These are the platforms you believe your content will and are intended to function correctly on

• Tested Platforms: This should list all platforms you have actually tested your content on and verified is functioning correctly

• Supported Platforms: These are the platforms that you are offering support with (you will assist buyers with the implementation of your content)

• Package Type

• Asset Pack: This is the basic Marketplace asset and is intended to be injected into a buyer’s project.

• Will be assigned as “Add To Project” after it is downloaded

• Should not include Level Blueprints, mandatory Config files, or other assets that can not be easily added to other assets or migrated

• Complete Project: This is a stand-alone project or a framework that buyers will use as a foundation to build their projects off of.

• Will be assigned as “Create Project” after it is downloaded

• Additional information regarding Taxpayer ID, tax forms, and bank information may be required to receive payment for content sold on the Marketplace. Providing this information is one of the biggest causes of delay in publishing your content, so it would be a good idea to have all of this ready in advance.

• Images and media necessary for display and promotion of the content in the Marketplace are required.

• Images

• <submissionname>_Featured.png - 476x246 pixels

• <submissionname>_FeaturedNew.png - 476x246 pixels

• <submissionname>_Thumb.png - 476x246 pixels

• <submissionname>_Screenshot.png - 476x246 pixels

• Between 1 and 7 screenshots required

• One screenshot must be of the overview map

• Videos

• Featurette/Example

• Think of this as a commercial advertisement for your content

• Potential buyers should understand what your pack is and what it does within the first minute of watching

• Tutorials

• Required for blueprints

• Needs to show any steps required for use, implementation, and modification of assets

• Other means of showing your content can be included as links

• Examples may include Sketchfab for models or SoundCloud for music and sounds

[Ivey]

Statement of Intent

The Marketplace aims to provide high quality content for developers to use for commercial projects and as leading industry examples for those learning to develop on their own. Content on the Marketplace is selected for distribution through a combination of community feedback and Epic curation to ensure value and functionality. All assets submitted to the marketplace will be subject to review and may be declined for failure to meet any criteria outlined in this document.

[Ivey]

Statement of Quality

All content should integrate seamlessly with any Unreal Engine project without additional work and/or function as a standalone project. Assets must be consistent in scale, orientation, brightness and other attributes where appropriate.

Think of your project in terms of product development. Try to put yourself into the shoes of the developer using that product, and think of ways to save that developer time and effort. Providing easy-to-understand documentation, verifying your content is tested and works as described, and designing your content to be easy to use are all signs of quality that will help you stand out.

Your submission must be a “polished version”, meaning it doesn’t necessarily have to be a “final version” when you submit but it must meet all the requirements for approval as if it were the final version. In other words, if your project is not ready do not submit it.

To ensure a high level of quality and consistency, all content available on the Marketplace must meet these submission guidelines. If you feel that any exception to the guidelines applies to your assets please add a note along with your submission and if we disagree we will offer suggested modifications.

[Ivey]

Statement of Professionalism

Maintain a high level of professionalism. If you’re going to provide content to developers using the Marketplace, the most important thing you can do besides doing great work is to be approachable, responsive, and respectful toward others. Be proud of the work you do, and keep supporting your content and the people that use it.

When a developer makes a decision to purchase Marketplace content, they want to feel confident that the content is as advertised and that the creator will help them with any problems they might have with it. People usually trust people they like, and having a good reputation for being a professional on the forums and in email correspondence greatly improves confidence.

This can have a direct effect on your success.

[Ivey]

**Statement of Maintaining Content
**
Content creators submitting to the Marketplace are expected to keep their content up to date with each new major engine version (4.12, 4.11, 4.10, etc), and to fix errors that arise after their content has been published. If a content creator is unable or unwilling to fix serious errors with their content, Epic Games reserves the right to remove the content from the Marketplace until the required fixes are completed. For fixing compatibility with new engine versions, you have 30 days to update your content after the new version is released. This relates directly to the Statement of Professionalism above.

Content must be maintained for current version and the previous version that your content has been created in. For example: If your content was released during 4.8 and 4.10 is the current version, you must support versions 4.9 and 4.10. You may support versions prior to your release but it is not required.

[Ivey]

**Content Types Accepted
**
Currently the following types of content are accepted in the Marketplace:

• Sample games

• Asset packs

• Packs with 5 or more assets

• Characters, vehicles, or weapons with 1 or more rigged and animated asset

• Buildings or assets with modular pieces that can be repurposed

• Blueprints

• Code Plugins

• Fully detailed environments

• Music

• Sounds

• 2D assets

• Effects and Particle systems

[Ivey]

**Making Blueprint-Only Projects Plugin Friendly
**
At current time of writing, Plugin support on the Marketplace is in “Early Access” and as such there is a small workaround needed to make Plugins work correctly in Blueprint only projects.

To add Marketplace Plugins to your projects, you need to add C++ code into your project. In order to do this, you have to make sure that Visual 2015 (For Windows) or the latest version of Xcode (For Mac) is installed on your machine.

Setting up Visual 2015: Setting Up Visual Studio Development Environment for C++ Projects in Unreal Engine | Unreal Engine 5.1 Documentation

Once you have Visual or Xcode correctly installed, open the project you wish to install your plugin to.

• Once your project has been opened, go to “File” > “New C++ Class…”

&stc=1

• When asked which C++ class you want to add, you can simply select “None”.

&stc=1

• When you’re ready to continue, select “Next” and you’ll be asked to name this C++ file. You can either keep the name as the default MyClass or change the name to something more recognisable.
• Once you’ve decided on the name, go ahead and select “Create Class”.

&stc=1

• Your files are now being generated. Once they have completed, you will either be sent to your IDE (Code editor) with the newly generated files opened or a prompt will show up letting you know your files have been generated.
• If the prompt comes up but you code doesn’t, you can access the file we need to alter by going to your project folder (The same one with your .uproject) and opening the YOURPROJECTNAME.sln file.

&stc=1

• At this point, please close your open Unreal Engine 4 project if it is still open.
• Install your Plugin into this project.

Once your plugin has been installed, we need to build our project files. In Visual , we can do this by looking at the “Solution Explorer”.

&stc=1

To build our project:

• Right-click the project name (The selection that has the two plus signs in a pink bordered-box preceding it)
• Select “Build” from the dropdown menu.

&stc=1

The project will now build. This process can take some time depending on a variety of factors such as computing power, project complexity .etc

Once the project build has completed, you can go ahead and close your IDE down and re-open your Unreal Engine 4 project.

If for some reason the project build fails, please post your errors to the Unreal Engine Answerhub: https://answers.unrealengine.com/

You may have a prompt the first time you load your project up with the new plugin that tells you that the .dll files were built with a different version of the engine.

&stc=1

When asked, simply select yes and the UnrealBuildTool will activate and make sure your plugin and project are ready for use.

&stc=1

You may experience an issue where the UnrealBuildTool stops because the project could not be compiled. If this happens, you need to rebuild the project in your IDE. If there are any underlying issues, your IDE will point you towards any issues in your project that needs to be fixed.

&stc=1

If this happens, please report any issues that crop up in your IDE to the Unreal Engine Answerhub, which you can access here: https://answers.unrealengine.com/

If there aren’t any issues and your project loads up… Congratulations! Your project is now ready to use with Marketplace plugins!

Don’t worry, once you’ve performed these steps for your project, you won’t have to do it again to add more plugins to your project.

As previously stated, as Marketplace plugins are in “Early Access”, if you run into any issues or errors, please post your questions, issues or answers to the Answerhubanswers.unrealengine.com/ At current time of writing, Plugin support on the Marketplace is in “Early Access” and as such there is a small workaround needed to make Plugins work correctly in Blueprint only projects.

To add Marketplace Plugins to your projects, you need to add C++ code into your project. In order to do this, you have to make sure that Visual 2015 (For Windows) or the latest version of Xcode (For Mac) is installed on your machine.

Setting up Visual 2015: Setting Up Visual Studio Development Environment for C++ Projects in Unreal Engine | Unreal Engine 5.1 Documentation

Once you have Visual or Xcode correctly installed, open the project you wish to install your plugin to.

• Once your project has been opened, go to “File” > “New C++ Class…”
• When asked which C++ class you want to add, you can simply select “None”.
• When you’re ready to continue, select “Next” and you’ll be asked to name this C++ file. You can either keep the name as the default MyClass or change the name to something more recognisable.
• Once you’ve decided on the name, go ahead and select “Create Class”.
• Your files are now being generated. Once they have completed, you will either be sent to your IDE (Code editor) with the newly generated files opened or a prompt will show up letting you know your files have been generated.
• If the prompt comes up but you code doesn’t, you can access the file we need to alter by going to your project folder (The same one with your .uproject) and opening the YOURPROJECTNAME.sln file.
• At this point, please close your open Unreal Engine 4 project if it is still open.
• Install your Plugin into this project.

Once your plugin has been installed, we need to build our project files. In Visual , we can do this by looking at the “Solution Explorer”.

To build our project:

• Right-click the project name (The selection that has the two plus signs in a pink bordered-box preceding it)
• Select “Build” from the dropdown menu.

The project will now build. This process can take some time depending on a variety of factors such as computing power, project complexity .etc

Once the project build has completed, you can go ahead and close your IDE down and re-open your Unreal Engine 4 project.

If for some reason the project build fails, please post your errors to the Unreal Engine Answerhub: https://answers.unrealengine.com/

You may have a prompt the first time you load your project up with the new plugin that tells you that the .dll files were built with a different version of the engine.

When asked, simply select yes and the UnrealBuildTool will activate and make sure your plugin and project are ready for use.

You may experience an issue where the UnrealBuildTool stops because the project could not be compiled. If this happens, you need to rebuild the project in your IDE. If there are any underlying issues, your IDE will point you towards any issues in your project that needs to be fixed.

If this happens, please report any issues that crop up in your IDE to the Unreal Engine Answerhub, which you can access here: https://answers.unrealengine.com/

If there aren’t any issues and your project loads up… Congratulations! Your project is now ready to use with Marketplace plugins!

Don’t worry, once you’ve performed these steps for your project, you won’t have to do it again to add more plugins to your project.

As previously stated, as Marketplace plugins are in “Early Access”, if you run into any issues or errors, please post your questions, issues or answers to the Answerhubanswers.unrealengine.com/

[Ivey]

**Preparing Your Assets: General Asset Requirements
**
Quality
All content should achieve a professional level of quality, regardless of artistic style. Deliver aesthetically pleasing colors, materials, and usable designs. Where possible, content should be built to be easily interchangeable with other assets and match existing content standards. All assets contained within content submission should be stylistically consistent where expected.

**Physically-Based Rendering Materials
**Whether or not the goal of your materials is to be photorealistic, it is required that your submission effectively uses UE4’s PBR materials. All PBR materials have some form of node attached to the Base Color, Roughness, and Metallic nodes. You may use a map or a numerical value (including zero) but it must have some form of input in order to be accepted for the Marketplace.

**Demonstration Level
**Content packages should include a demonstration level with the content logically placed, lit, and represented in its intended manner. This is where you will show off your assets the way you intend them to be used.

&stc=1

**Overview Map
**An overview map is a screenshot of all the contents of a submission on a grid in UE4, spaced out to show how many individual pieces there are, and their relative scale. This is an extremely useful visual aid for assets that are modular, because it makes it easier to understand how many pieces there are and how they can fit together.

People make purchasing decisions based on this. Providing an Overview Map is a requirement. These are the settings for creating a proper Overview Map:
⦁ Atmospheric Fog removed
⦁ Light Source set to 5.0 intensity
⦁ Skylight added
⦁ Reflection capture added
⦁ Cloud Opacity set to 0
⦁ Assets are evenly spaced out no z-fighting with the ground
⦁ BSP bases use the default grid, with MI_Template_BaseGray_03_Metal on the sides
⦁ BSP Bases have lightmap resolution set to 8
⦁ Press “Play” to make sure lighting has been built
⦁ All materials have textures
⦁ No default textures are shown on any assets

&stc=1

Functionality
All assets must be fully functional with current version and the previous version that your content has been created in. For example: If your content was released during 4.8 and 4.10 is the current version, you must be sure it works in versions 4.9 and 4.10.

**Asset Scale and Orientation
**Unreal Engine units are expressed in centimeters, with 2D editor viewports clearly displaying a scale legend. All content should adhere to these units. If content has directionality, it should be oriented with its front facing in the direction of the X-axis.

Plugins
⦁ Any plugins used in your project must be freely available on the UE Marketplace
⦁ All unused plugins must be disabled before sending your files

**Restricted Content
**⦁ You must have all rights to redistribute all components of the content.
⦁ The content must not use any trademarks/logos/brands that you do not own.
⦁ The content must not contain anything that may be deemed offensive.

**Public Domain Content
**We do permit the use of content that is available in the public domain and available for redistribution. This is meant primarily to help with presentation materials for Blueprints and code plugins, not a shortcut to quickly publish art content you didn’t create. We keep a close eye on exactly how public domain content is used. We have four conditions that must be met in order for us to accept public domain content:
⦁ Public domain content must have been modified so as to bring new value to the assets.
⦁ You must cite the source of the content.
⦁ You must include a link to the source content on the product page that includes the public domain usage information.
⦁ Epic will verify via that link that the content is in the public domain and redistributable.

**Video Demonstration Guidelines
**If you are submitting a Blueprint, animation, particle system, or any other content that would require animated examples, you MUST submit a video demonstrating how it is used. These submissions will be considered without a video. If you are submitting a different type of content, a video is optional, but it can be an excellent sales tool.

An effective approach to creating a video that we recommend is trying to keep the video between 90 - 120 seconds long. Open the video with examples of the finished product, then show your submission in the editor. Show the controls you provide, and look at some of the most interesting and visually meaningful configuration options your submission offers.

Although long tutorial videos are helpful and we do encourage them if you have a complex submission, creating a shorter “commercial” video for potential buyers is highly recommended.

Ease of use and the end product are what is most important, so if you can dazzle them with video of how it could work, then show them what knobs they can turn to use it, and try to keep it under two minutes, you’ll be in a very solid competitive position. The easier it is for the buyer to visualize “what is it? Now how can I do it?” the faster you’ll get them interested.

**Asset Naming
**When giving your submission a name, try to pick something that is descriptive without being generic. Do a quick search on the Marketplace to see if your submission might be confused with something else that’s already been published.

Due to how often they’ve been used already, we recommend against using words like “Simple,” “Super,” “Mega,” “Extreme,” “Ultimate,” “Photorealistic,” “AAA,” and similar. Try to avoid generic names that are too simple in describing the content. For example, “Blueprint Dialog System” or "Modular Building Set.”

We do not accept submissions with “Epic,” “Unreal,” or “UE4” in the title, that is reserved for Epic Games content only.

Individual asset names should adhere to the following guidelines:
⦁ Intuitive, unique, and less than 30 characters.
⦁ Clearly describes what the asset is and its intended use, and avoids confusion with other assets. For example, a rock mesh named SM_Landscaping_Patio_Rocks_01 is preferable to SM_Rocks_01.
⦁ Should not include your initials, project name, or other folder information.

**Folder Hierarchy
**When you open your project in UE4 the first folder needs to be named your project.
Example: “YourProject”

All of your project content should reside within this folder. The main file names in the project cannot have any underscores (“_”) and the names of the .uproject file have to match the main filename and the filename of the internal content folder.

So it should look like this on your hard drive:

YourProject (main project folder)
⦁ Config (folder)
⦁ Content (folder)
⦁ (subfolders)
⦁ YourProject.uproject (file)

Within your “Content” folder should be another folder named “YourProject”, and within that should be all of your project files and folders.

So in the Content folder it should look like this:
Content (folder)
⦁ YourProject (your project folder)
⦁ (all project folders here)

&stc=1

Within your “Content” folder should be another folder named “YourProject”, and within that should be all of your project files and folders.

So inside the Content folder, it should look like this:

Content (folder) - YourProject (your project folder) - (all project folders here)

Folder names should be plural where appropriate, and conform to existing folder structures for common asset type. For example, a project named YourProject would have the following folder structure:
\YourProject \Textures
\YourProject \Materials
\YourProject \Meshes
\YourProject \Blueprints
\YourProject \Particles\

Folder structure should be shallow where possible, and strive for brevity to stay within the path length limit of 115 characters. Refer to the free content showcases Effects Cave, Blueprint Office, or Realistic Rendering in the Marketplace as good examples of asset naming and project folder structure.

Epic Content

Epic content (including, but not limited to, Epic Branding, Feature Packs, Starter Content, Samples, Templates, etc…) may only be used to display your assets functionality. Asset requirements may not be substituted with Epic content. If considers the pack to misuse Epic content or contain a disproportionate amount, in relation to submission content, you may be asked to modify your pack. If your asset does contain Epic content, ensure that it is located in the [YourProject] folder within the Content folder of your project, along with the rest of your pack’s content. Any submissions that contain folders other than the [YourProject] folder within the Content folder will not be accepted and you will be asked to modify your pack.

You are required to ensure that the DefaultGame.ini included in your submission does not contain the following text:

[StartupActions]
bAddPacks=True
InsertPack=(PackSource="StarterContent.upack,PackName=“StarterContent”)

[Ivey]

Preparing Your Assets: Weapons

Please be sure to follow all steps and guidelines outlined in the UE Documentation for setting up your assets correctly.

**Content Folder Structure
**See General Asset Requirements for how to structure your folders.

**Overview Map
**All Assets packs must contain an overview map that lays out the content included in the package.

&stc=1

**Technical Specifications:
**⦁ Scaled to Epic skeleton (Yes/No)
⦁ Physically-Based Rendering (Yes/No)
⦁ Texture Sizes (please list resolutions for each texture)
⦁ Collision (Yes/No, and specify which type – custom, automatically generated, or per-poly?)
⦁ Vertex Count
⦁ LODs
⦁ Number of Meshes
⦁ Number of Materials and Material Instances
⦁ Number of Textures
⦁ Intended Platforms
⦁ Platforms Tested
⦁ Documentation Included (Yes/No)
⦁ Important/Additional Notes

**Package Delivery
**When you are finally ready to deliver your asset pack to us, please the Config,Content,and .Uproject files together and provide us with a download link.

&stc=1

**Static Mesh Requirements
**
**Point of Origin
**The origin of your mesh will be the location that your mesh scales and rotates from once imported into Unreal Engine. This is generally represented by the world origin in most modeling applications. Be sure to position your model relative to that spot before exporting it, especially for modular meshes.

For example if you’re creating a modular wall piece, a good place for the origin is on the edge or the corner of the mesh so it can snap easily into place. Conversely, a statue on a plinth might work better with the origin at the bottom center of the mesh so that it can be easily rotated and scaled.

**Grid Snapping
**All static mesh content should snap together nicely on the standard 10cm grid where possible to retain modularity. If meshes contain edges that are meant to be adjacent to other meshes then those edges should be easily snapped to some multiple of 10cm.

**Triangle Counts and Texture Sizes
**Always keep the target platform in mind for the content, and be efficient in your use of triangle counts and texture sizes. Fewer vertices mean faster rendering, and for content targeting mobile platforms it is important to keep both triangle count texture sizes reasonably small to maintain performance.

**Texture Density
**Assets should be UV mapped so that 1 texture tile covers 1m in the game world to maintain a consistent texture density. For example, if you build a wall 2m in length the texture you apply to it should tile twice along the length of the wall. Unique or more complex assets may break this guideline, but only where justified.

**UV Layouts
**Generally for static meshes you’ll need two sets of UV coordinates. The first set is your base set of coordinates where you map diffuse, normal, and other maps to the mesh. The second set is your light map coordinates which have special considerations such as all UV islands must fall within the 0-1 UV space. Also, no islands may overlap, otherwise errors will be introduced in your lighting results.
Blueprint Requirements

**Layout and Naming
**All Blueprints submitted should include a video demonstrating how they are used. No Blueprint submissions will be accepted without a video.

**Blueprint Structure
**All Blueprints must be neatly laid out and make reasonable use of Blueprint functions to organize the overall logic structure. Functions, variables, and events should all use names that reflect their intended purpose or use in the Blueprint.

**Commenting and Documentation
**Blueprints must be thoroughly commented with explanations of the function and operation of the Blueprints. In general more useful comments will explain the ‘why?’ rather than the ‘how?’, and any comments that merely provide labels should be avoided.

**Skeletal Mesh Requirements
**

**Animation Importing
**The Unreal Engine expects each animation to be imported from its own FBX file. For example, if you have a run, walk, and jump animation for your character you would have FBX files for each animation such as MyChar_walk.fbx, MyChar_Run.fbx, and MyChar_Jump.fbx.

**Rigging and the Epic Skeleton
**All humanoid characters in Unreal Engine are required to have configured rig using Rig’/Engine/EngineMeshes/Humanoid.Humanoid’ for Marketplace (Make sure you enable “Show Engine Content” option in the content browser), so that it can be converted any other humanoid characters. This will allow animations to be converted to other skeleton using the same configuration Rig. Meshes that are not humanoid in nature can be rigged as you please to any skeleton provided they are unique enough to not interchangeable with other content.

**Creating a character for the Unreal Engine Marketplace
**In order to ensure maximum compatibility with the animations Epic provides, both in the content samples and in the Marketplace, we provide a skeleton template file you can use to model your character to. This approach is how we at Epic approach modeling characters that share animations in games, such as Fortnite.

IMPORTANT UPDATE: The Epic Skeleton template below has been updated for 4.8 with new proportions. All new Marketplace content submissions using the Epic skeleton need to use this new skeleton. All existing Marketplace content using previous skeletons will need to retarget their animations to be compatible with future versions of the engine.

• Epic Skeleton Template

The SK_Mannequin.fbx file can be loaded into any 3d package that can import FBX files. You will want to model your character to the proportions and pose of this skeleton.

&stc=1

You may notice these joints in the hierarchy. These are the bones the engine uses as IK targets for the in-game IK. You’ll want to make sure that these joints stay in the skeleton hierarchy and that you also do not weight any part of your character to the IK joints.

We also provide two FBX animations for you to import onto your character to test the deformations. These are the same animations that ship with the Unreal Engine third person shooter template. If the animation changes your character in some unwanted way, it means that the skeleton has been modified and your character hasn’t been built to the template.

Here is a checklist of the major “Don’ts” for working with the skeleton:
⦁ Make sure to not change the joint orientations. It is imperative they remain the same. This also means to not rotate the joints to get the skeleton into a different pose.
⦁ Make sure to not skin weight your mesh to any of the IK joints.
⦁ Do not scale the skeleton

If you absolutely must move a joint, make sure that the joint isn’t move very far, and make sure the joint orientation does not change. If you’re using a program like Maya, which has an option in the move tool to automatically orient joints, you’ll want to make sure and turn that off!

&stc=1

Testing your character with the included animation files or even better, in the engine with Epic animation assets, is the best way to ensure your model will be plug and play with the rest of the assets.

**Creating a character for the Unreal Engine Marketplace (After 4.5)
**In order to ensure maximum compatibility, both in the content samples and in the marketplace, we provide an asset - Rig’/Engine/EngineMeshes/Humanoid.Humanoid’ - and your skeleton should set up using the rig.

To configure the rig, go to “Skeleton” tab and open “Retarget Manager”

&stc=1

In the middle section, you’ll be able to find “Set up Rig” section. You can select the rig provided above - Rig’/Engine/EngineMeshes/Humanoid.Humanoid’ – and configure each mapping bone. Make sure you enabled “Show Engine Content” in the view option of Content Browser.

&stc=1

The left column is the node name in the rig, and the right column is the bone name from the current skeleton that is mapped to the node. To see more detail of this animation retargeting please go here.

This data will be used when the buyer convert the animation for their skeleton. If you have missing nodes or if you don’t see the node you’re looking for, those won’t be converted, but it will make sure all other data is converted correctly.
One thing to note is that it is recommended to have neutral T-pose as reference pose. When retarget animation, we assume their reference pose is same. We call this “Retarget Base Pose.” By default, it is from reference pose. You can modify this at the bottom section in your “Retarget Manager” window. Retarget Base Pose will be saved per Skeletal Mesh.

**Material Requirements
**
**Physically-Based Rendering Materials
**Whether or not the goal of your materials is to be photorealistic, it is required that your submission effectively uses UE4’s PBR materials. All PBR materials must have some form of node attached to the Base Color, Roughness, and Metallic nodes. You may use a map or a numerical value (including zero) but it must have some form of input in order to be accepted for the Marketplace.

[Ivey]

**Preparing Your Assets: Materials
**
Please be sure to follow all steps and guidelines outlined in the UE Materials Documentation for setting up your assets correctly.

**Content Folder Structure
**See General Asset Requirements for how to structure your folders.

**Overview Map
**All Asset packs must contain an overview map that lays out the content included in the package.

&stc=1

**Technical Specifications:
**

• Number of Materials
• Do Materials derive from a Master Material with instances as variation (Yes/No)
• Number of Textures
• Texture Resolution (complete list)
• Intended Platforms
• Platforms Tested
• Documentation Included (Yes/No)
• Important/Additional Notes

Important note: Not every asset type will require all of these technical specifications, but please provide as much of this information as you can. This not only helps us review your content, but it will help potential paying customers understand what they’re getting.

It is a smart sales strategy to clearly communicate what you have to offer with as much information as possible. will request additional information if we decide the technical specifications are not detailed enough.

We will always be reasonable, but we still reserve the right to reject submissions that are unwilling to offer enough information when requested.

**Package Delivery
**When you are finally ready to deliver your asset pack to us, please the Config, Content,and .Uproject files together and provide us with a download link.

&stc=1

**Material Requirements
**
**Physically-Based Rendering Materials
**Whether or not the goal of your materials is to be photorealistic, it is required that your submission effectively uses UE4’s PBR materials. All PBR materials must have some form of node attached to the Base Color, Roughness, and Metallic nodes. You may use a map or a numerical value (including zero) but it must have some form of input in order to be accepted for the Marketplace.

[Ivey]

**Preparing Your Assets: FX
**
Please be sure to follow all steps and guidelines outlined in the UE Documentation for setting up your assets correctly.

**Content Folder Structure
**See General Asset Requirements for how to structure your folders.

**Overview Map
**All asset packs must contain an overview map that lays out the content included in the package.

&stc=1

**Technical Specifications:
**

• List of every effect
• Type of Emitters (CPU, GPU, and/or mesh emitters?)
• Number of Effects
• Number of Textures
• Number of Materials
• Number of Blueprints
• Number of Meshes
• Intended Platforms
• Platforms Tested
• Documentation Included (Yes/No)
• Important/Additional Notes

Important note: Not every asset type will require all of these technical specifications, but please provide as much of this information as you can. This not only helps us review your content, but it will help potential paying customers understand what they’re getting.

It is a smart sales strategy to clearly communicate what you have to offer with as much information as possible. will request additional information if we decide the technical specifications are not detailed enough.

We will always be reasonable, but we still reserve the right to reject submissions that are unwilling to offer enough information when requested.

**Demonstration Video
**All FX submitted should include a video demonstrating how they are used. No FX submissions will be accepted without a video.

**Package Delivery
**When you are finally ready to deliver your asset pack to us, please the Config, Content,and .Uproject files together and provide us with a download link.

&stc=1

**Material Requirements
**
**Physically-Based Rendering Materials
**Whether or not the goal of your materials is to be photorealistic, it is required that your submission effectively uses UE4’s PBR materials. All PBR materials must have some form of node attached to the Base Color, Roughness, and Metallic nodes. You may use a map or a numerical value (including zero) but it must have some form of input in order to be accepted for the Marketplace.

[Ivey]

Preparing Your Assets: Environments

Please be sure to follow all steps and guidelines outlined in the UE Documentation for setting up your assets correctly.

**Content folder structure
**See General Asset Requirements for how to structure your folders.

**Demo Levels
**We require that you add a Demo Level to your submission that allows the user to experience the functionality of your submission the way you intend it to be used.

&stc=1

**Overview Map
**All asset packs must contain an overview map that lays out the content included in the package.

&stc=1

**Technical Specifications:
**

• Texture Size (please list textures for each resolution)
• Collision (Yes/No, and specify which type – custom, automatically generated, or per-poly?)
• Vertex Count
• LODs
• Number of Meshes
• Number of Materials and Material Instances
• Number of Textures
• Intended Platforms
• Platforms Tested
• Documentation Included (Yes/No)
• Important/Additional Notes

Important note: Not every asset type will require all of these technical specifications, but please provide as much of this information as you can.

This not only helps us review your content, but it will help potential paying customers understand what they’re getting. It is a smart sales strategy to clearly communicate what you have to offer with as much information as possible.

will request additional information if we decide the technical specifications are not detailed enough.

We will always be reasonable, but we still reserve the right to reject submissions that are unwilling to offer enough information when requested.

**Package Delivery
**When you are finally ready to deliver your asset pack to us, please the Config, Content,and .Uproject files together and provide us with a download link.

&stc=1

**Static Mesh Requirements
**
**Point of Origin
**The origin of your mesh will be the location that your mesh scales and rotates from once imported into Unreal Engine. This is generally represented by the world origin in most modeling applications. Be sure to position your model relative to that spot before exporting it, especially for modular meshes.

For example if you’re creating a modular wall piece, a good place for the origin is on the edge or the corner of the mesh so it can snap easily into place. Conversely, a statue on a plinth might work better with the origin at the bottom center of the mesh so that it can be easily rotated and scaled.

**Grid Snapping
**All static mesh content should snap together nicely on the standard 10cm grid where possible to retain modularity. If meshes contain edges that are meant to be adjacent to other meshes then those edges should be easily snapped to some multiple of 10cm.

**Triangle Counts and Texture Sizes
**Always keep the target platform in mind for the content, and be efficient in your use of triangle counts and texture sizes. Fewer vertices mean faster rendering, and for content targeting mobile platforms it is important to keep both triangle count texture sizes reasonably small to maintain performance.

**Texture Density
**Assets should be UV mapped so that 1 texture tile covers 1m in the game world to maintain a consistent texture density. For example, if you build a wall 2m in length the texture you apply to it should tile twice along the length of the wall. Unique or more complex assets may break this guideline, but only where justified.

**UV Layouts
**Generally for static meshes you’ll need two sets of UV coordinates. The first set is your base set of coordinates where you map diffuse, normal, and other maps to the mesh. The second set is your light map coordinates which have special considerations such as all UV islands must fall within the 0-1 UV space. Also, no islands may overlap, otherwise errors will be introduced in your lighting results.

**Material Requirements
**
**Physically-Based Rendering Materials
**Whether or not the goal of your materials is to be photorealistic, it is required that your submission effectively uses UE4’s PBR materials. All PBR materials must have some form of node attached to the Base Color, Roughness, and Metallic nodes. You may use a map or a numerical value (including zero) but it must have some form of input in order to be accepted for the Marketplace.

[Ivey]

**Preparing Your Assets: Code Projects
**
Please be sure to follow all steps and guidelines outlined in the Unreal Engine Coding Standard.

**Content Folder Structure
**See General Asset Requirements for how to structure your folders.

**Demo Levels
**We require that you add a Demo Level to your submission that allows the user to experience the functionality of your submission the way you intend it to be used.

&stc=1

**Technical Specifications:
**

• Input Mappings (If any input is included in your C++Project, please include which methods of input are preconfigured (Gamepad, Keyboard, Mouse… etc.))
• Network Replicated (Yes/No)
• List of Features (Please include a full, comprehensive list of the features of your Blueprint)
• Intended Platforms
• Platforms Tested
• Documentation Included (Yes/No)
• Important/Additional Notes

This not only helps us review your content, but it will help potential paying customers understand what they’re getting. It’s a smart sales strategy to clearly communicate what you have to offer with as much information as possible.

will request additional information if we decide the technical specifications are not detailed enough.

We will always be reasonable, but we still reserve the right to reject submissions that are unwilling to offer enough information when requested.

**C++ Project Requirements
**
**Demonstration Video
**All C++ Projects submitted should include a video demonstrating how they are used. No C++ Project submissions will be accepted without a video.

**Code Structure
**All Blueprints must be neatly laid out and make reasonable use of Blueprint functions to organize the overall logic structure. Functions, variables, and events should all use names that reflect their intended purpose or use in the Blueprint.

**Compilation and Cleanliness
**Code within your project should not produce any warnings or errors on compilation. Code must have all #include files that you’re not actively using completely removed prior to submission.

All headers should protect against multiple includes with the “#pragma once” pre-processor directive. Note that all compilers we need to use support “#pragma once”, but make sure to only use this directive in the header file, not the .cpp file.

Epic will build all binaries during the staging process, so DO NOT include binaries that the Unreal Editor generates. Essentially this means delete any files that start with “UE4” in the Binaries folder. Also, DO NOT include .sln or .sdf files or the Build or Intermediate folders for distribution. Compress your overarching [YourProject] folder into a file for submission.

**Custom Blueprint Nodes
**If you’re using custom blueprint nodes in your project, please make sure they are categorized with your project name as a preface. For example: “[YourProject][Category][BlueprintName]”.

Also, all custom blueprint nodes require a “Static” flag. We cannot accept submissions at this time that include custom blueprint nodes without this static flag.

**Source Code Distribution
**Any source code which requires Unreal Engine source code to compile must be provided to the user. Many of our users get the engine from GitHub, and they should be able to continue using your project by compiling it against a modified version of the engine. It’s only acceptable to include externally compiled code which does not include or reference any Unreal Engine source code in a static library and/or DLLs.

**Blueprint Requirements
**
**Blueprint Structure
**All Blueprints must be neatly laid out and make reasonable use of Blueprint functions to organize the overall logic structure. Functions, variables, and events should all use names that reflect their intended purpose or use in the Blueprint.

**Commenting and Documentation
**Blueprints must be thoroughly commented with explanations of the function and operation of the Blueprints. In general more useful comments will explain the ‘why?’ rather than the ‘how?’, and any comments that merely provide labels should be avoided.

**Static Mesh Requirements
**
**Point of Origin
**The origin of your mesh will be the location that your mesh scales and rotates from once imported into Unreal Engine. This is generally represented by the world origin in most modeling applications. Be sure to position your model relative to that spot before exporting it, especially for modular meshes.

For example if you’re creating a modular wall piece, a good place for the origin is on the edge or the corner of the mesh so it can snap easily into place. Conversely, a statue on a plinth might work better with the origin at the bottom center of the mesh so that it can be easily rotated and scaled.

**Grid Snapping
**All static mesh content should snap together nicely on the standard 10cm grid where possible to retain modularity. If meshes contain edges that are meant to be adjacent to other meshes then those edges should be easily snapped to some multiple of 10cm.

**Triangle Counts and Texture Sizes
**Always keep the target platform in mind for the content, and be efficient in your use of triangle counts and texture sizes. Fewer vertices mean faster rendering, and for content targeting mobile platforms it is important to keep both triangle count texture sizes reasonably small to maintain performance.

**Texture Density
**Assets should be UV mapped so that 1 texture tile covers 1m in the game world to maintain a consistent texture density. For example, if you build a wall 2m in length the texture you apply to it should tile twice along the length of the wall. Unique or more complex packs may break this guideline, but only where justified.

**UV Layouts
**Generally for static meshes you’ll need two sets of UV coordinates. The first set is your base set of coordinates where you map diffuse, normal, and other maps to the mesh. The second set is your light map coordinates which have special considerations such as all UV islands must fall within the 0-1 UV space. Also, no islands may overlap, otherwise errors will be introduced in your lighting results.

**Material Requirements
**
**Physically-Based Rendering Materials
**Whether or not the goal of your materials is to be photorealistic, it is required that your submission effectively uses UE4’s PBR materials. All PBR materials must have some form of node attached to the Base Color, Roughness, and Metallic nodes. You may use a map or a numerical value (including zero) but it must have some form of input in order to be accepted for the Marketplace.

[Ivey]

**Preparing Your Assets: Code Plugins
**Please be sure to follow all steps and guidelines outlined in the Unreal Engine Coding Standard and the Unreal Engine Plugins Programming Guide.

**Content folder structure
**See General Asset Requirements for how to structure your folders.

**Technical Specifications:
**

• List of Features (Please include a full, comprehensive list of the features of your Plugin)

• Network Replicated (Yes/No)

• Intended Platforms

• Platforms Tested

• Documentation Included (Yes/No)

• Example Project

• Important/Additional Notes

  This not only helps us review your content, but it will help potential paying customers understand what they’re getting. It’s a smart sales strategy to clearly communicate what you have to offer with as much information as possible.

will request additional information if we decide the technical specifications are not detailed enough. We will always be reasonable, but we still reserve the right to reject submissions that are unwilling to offer enough information when requested.

C++ Requirements

**Code Structure
**All code must be neatly presented and make full use of comments to explain what a section of code is doing and why. Functions, variables and macros should all names that reflect their intended purpose or use case.

**Compilation and Cleanliness
**Code within your plugin should not produce any warnings or errors on compilation. Code must have all #include files that you’re not actively using completely removed prior to submission.

All headers should protect against multiple includes with the “#pragma once” pre-processor directive. Note that all compilers we need to use support “#pragma once”, but make sure to only use this directive in the header file, not the .cpp file.

All properties that are exposed to the editor are required to have a category specifier in their declaration. Although the absence of this specifier may still allow for UHT to build the plugin initially, once the plugin is installed to the engine, editor-exposed properties that don’t have their categories defined will generate errors when attempting to build projects.

**Custom Blueprint Nodes
**If you’re using custom blueprint nodes in your project, please make sure they are categorized with your plugin name as a preface. For example: “[YourPlugin][Category][BlueprintName]”.

Also, all custom blueprint nodes require a “Static” flag. We cannot accept submissions at this time that include custom blueprint nodes without this static flag.

**Source Code Distribution
**Any source code which requires Unreal Engine source code to compile must be provided to the user. Many of our users get the engine from GitHub, and they should be able to continue using your project by compiling it against a modified version of the engine. It’s only acceptable to include externally compiled code which does not include or reference any Unreal Engine source code in a static library and/or DLLs (just remember to add the folders that they’re contained in to the FilterPlugin.ini if they’re not in the Binaries folder).

Code Plugin Requirements

**Demonstration Video
**All plugins submitted should include a video demonstrating how they are used. No plugin submissions will be accepted without a video.

**Example Project
**All plugins purchased and imported from the Epic Launcher will be installed as an engine plugin, not a project plugin, so creating an Example Project to be used in conjunction with your plugin is strongly encouraged. This should allow the user to experience the functionality of your plugin the way you intend it to be used. Please add a DropBox (or similar hosting site) link to your Technical Details section beside the specification “Example Project: “. This link should download just your supplementary example project to be used in conjunction with your plugin. Just make sure that this link DOES NOT allow users to download the actual plugin itself, as they should only be getting that by downloading it from the launcher.

**Third Party Dependencies
**Third party dependencies may only be used with proof of permission and you must ensure that they’re in a ThirdParty folder located in the Source folder.

**Including Custom Folders
**For folders included in your overarching plugin folder besides the Content, Resources, or Source folders (like ThirdParty or Documentation folders), please ensure within the Config folder there is a “FilterPlugin.ini” that contains something similar to:

[FilterPlugin]
/ThirdParty/…
/MyOtherFolder/…

**Specifying Build Platforms
**Plugin authors MUST test their plugin on all the plugins which they intend to support. Within the .uplugin descriptor, you’re required to Whitelist the appropriate platforms that your plugin is intended to be built for in the appropriate module(s) with something similar to:

“WhitelistPlatforms”: “Win64”, “Win32”, “Mac”, “IOS”, “Android” ]

Ensure that this attribute-value pair is located inside of the approptriate module(s) within your .uplugin descriptor.

**Compilation for the Marketplace
**In order to minimize errors that are produced during’s compilation of your plugin, ensure that final debugging has been completed before submission by running this command from installed UE4 builds of each Editor version that you’d like your plugin to support:

Engine\Build\BatchFiles\RunUAT.bat BuildPlugin -Plugin=[Path to .uplugin file, must be outside engine directory] -Package=[Output directory] -Rocket

**Packaging for Distribution
**Epic will build all binaries during the staging process, so DO NOT include binaries that the Unreal Editor generates. Essentially this means delete any files that start with “UE4” in the Binaries folder. Also, DO NOT include the Build or Intermediate folders for distribution. Compress your overarching [YourPlugin] folder into a file for submission.

Blueprint Requirements

**Blueprint Structure
**All Blueprints must be neatly laid out and make reasonable use of Blueprint functions to organize the overall logic structure. Functions, variables, and events should all use names that reflect their intended purpose or use in the Blueprint.

**Commenting and Documentation
**Blueprints must be thoroughly commented with explanations of the function and operation of the Blueprints. In general more useful comments will explain the ‘why?’ rather than the ‘how?’, and any comments that merely provide labels should be avoided.

Static Mesh Requirements

**Point of Origin
**The origin of your mesh will be the location that your mesh scales and rotates from once imported into Unreal Engine. This is generally represented by the world origin in most modeling applications. Be sure to position your model relative to that spot before exporting it, especially for modular meshes.

For example if you’re creating a modular wall piece, a good place for the origin is on the edge or the corner of the mesh so it can snap easily into place. Conversely, a statue on a plinth might work better with the origin at the bottom center of the mesh so that it can be easily rotated and scaled.

**Grid Snapping
**All static mesh content should snap together nicely on the standard 10cm grid where possible to retain modularity. If meshes contain edges that are meant to be adjacent to other meshes then those edges should be easily snapped to some multiple of 10cm.

**Triangle Counts and Texture Sizes
**Always keep the target platform in mind for the content, and be efficient in your use of triangle counts and texture sizes. Fewer vertices mean faster rendering, and for content targeting mobile platforms it is important to keep both triangle count texture sizes reasonably small to maintain performance.

**Texture Density
**Assets should be UV mapped so that 1 texture tile covers 1m in the game world to maintain a consistent texture density. For example, if you build a wall 2m in length the texture you apply to it should tile twice along the length of the wall. Unique or more complex packs may break this guideline, but only where justified.

**UV Layouts
**Generally for static meshes you’ll need two sets of UV coordinates. The first set is your base set of coordinates where you map diffuse, normal, and other maps to the mesh. The second set is your light map coordinates which have special considerations such as all UV islands must fall within the 0-1 UV space.

Also, no islands may overlap, otherwise errors will be introduced in your lighting results.

**Material Requirements
**
**Physically-Based Rendering Materials
**Whether or not the goal of your materials is to be photorealistic, it is required that your submission effectively uses UE4’s PBR materials. All PBR materials must have some form of node attached to the Base Color, Roughness, and Metallic nodes.

You may use a map or a numerical value (including zero) but it must have some form of input in order to be accepted for the Marketplace.

[Ivey]

Preparing Your Assets: Characters and Animations

Please be sure to follow all steps and guidelines outlined in the UE Animation Documentation for setting up your assets correctly.

**Content folder structure
**See General Asset Requirements for how to structure your folders.

**Demo Levels
**We require that you add a Demo Level to your submission that allows the user to experience the functionality of your submission the way you intend it to be used. This typically consists of a 3rd person map with the default character replaced.

**Overview Map
**All asset packs must contain an overview map that lays out the content included in the package.

&stc=1

Technical Specifications:

• Scaled to Epic skeleton (Yes/No)
• Rigged (Yes/No)
• Rigged to Epic skeleton (Yes/No)
• Animated (Yes/No)
• Number of characters
• Vertex counts of characters
• Texture Resolutions
• Number of Animations
• Animation types (Root Motion/In-place)
• Intended Platform
• Platforms Tested
• Documentation Included (Yes/No)
• Important/Additional Notes

Important note: Not every asset type will require all of these technical specifications, but please provide as much of this information as you can.

This not only helps us review your content, but it will help potential paying customers understand what they’re getting. It is a smart sales strategy to clearly communicate what you have to offer with as much information as possible.

will request additional information if we decide the technical specifications are not detailed enough.

We will always be reasonable, but we still reserve the right to reject submissions that are unwilling to offer enough information when requested.

**Package Delivery
**When you are finally ready to deliver your asset pack to us, please the Config, Content,and .Uproject files together and provide us with a download link.

&stc=1

Skeletal Mesh Requirements

**Demonstration Video
**All Animations submitted should include a video demonstrating how they are used. No Animation submissions will be accepted without a video.

**Animation Importing
**The Unreal Engine expects each animation to be imported from its own FBX file. For example, if you have a run, walk, and jump animation for your character you would have FBX files for each animation such as MyChar_walk.fbx, MyChar_Run.fbx, and MyChar_Jump.fbx.

**Rigging and the Epic Skeleton
**All humanoid characters in Unreal Engine are required to have configured rig using Rig’/Engine/EngineMeshes/Humanoid.Humanoid’ for Marketplace (Make sure you enable “Show Engine Content” option in the content browser), so that it can be converted any other humanoid characters.

This will allow animations to be converted to other skeleton using the same configuration Rig. Meshes that are not humanoid in nature can be rigged as you please to any skeleton provided they are unique enough to not interchangeable with other content.

Creating a character for the Unreal Engine Marketplace

In order to ensure maximum compatibility with the animations Epic provides, both in the content samples and in the Marketplace, we provide a skeleton template file you can use to model your character to. This approach is how we at Epic approach modeling characters that share animations in games, such as Fortnite.

IMPORTANT UPDATE: The Epic Skeleton template below has been updated for 4.8 with new proportions. All new Marketplace content submissions using the Epic skeleton need to use this new skeleton. All existing Marketplace content using previous skeletons will need to retarget their animations to be compatible with future versions of the engine.

• Epic Skeleton Template

The SK_Mannequin.fbx file can be loaded into any 3d package that can import FBX files. You will want to model your character to the proportions and pose of this skeleton.

&stc=1

You may notice these joints in the hierarchy. These are the bones the engine uses as IK targets for the in-game IK. You’ll want to make sure that these joints stay in the skeleton hierarchy and that you also do not weight any part of your character to the IK joints.

We also provide two FBX animations for you to import onto your character to test the deformations. These are the same animations that ship with the Unreal Engine third person shooter template. If the animation changes your character in some unwanted way, it means that the skeleton has been modified and your character hasn’t been built to the template.

Here is a checklist of the major “Don’ts” for working with the skeleton:

• Make sure to not change the joint orientations. It is imperative they remain the same. This also means to not rotate the joints to get the skeleton into a different pose.
• Make sure to not skin weight your mesh to any of the IK joints.
• Do not scale the skeleton

If you absolutely must move a joint, make sure that the joint isn’t move very far, and make sure the joint orientation does not change. If you’re using a program like Maya, which has an option in the move tool to automatically orient joints, you’ll want to make sure and turn that off!

We cannot accept only root motion assets without in-place counterparts due to fact that this could limit compatibility with other content curated within the engine or purchased on the Marketplace. If you are submitting a root motion and in-place animation pack, you must split them into separate “InPlace” and “RootMotion” folders.

For more information on root motion, please see the documentation: Root Motion in Unreal Engine | Unreal Engine 5.1 Documentation

&stc=1

Testing your character with the included animation files or even better, in the engine with Epic animation assets, is the best way to ensure your model will be plug and play with the rest of the assets.
**
Creating a character for the Unreal Engine Marketplace (After 4.5)**
In order to ensure maximum compatibility, both in the content samples and in the marketplace, we provide an asset - Rig’/Engine/EngineMeshes/Humanoid.Humanoid’ - and your skeleton should set up using the rig.

To configure the rig, go to “Skeleton” tab and open “Retarget Manager”

&stc=1

In the middle section, you’ll be able to find “Set up Rig” section. You can select the rig provided above - Rig’/Engine/EngineMeshes/Humanoid.Humanoid’ – and configure each mapping bone. Make sure you enabled “Show Engine Content” in the view option of Content Browser.

&stc=1

The left column is the node name in the rig, and the right column is the bone name from the current skeleton that is mapped to the node. To see more detail of this animation retargeting please gohere.

This data will be used when the buyer convert the animation for their skeleton. If you have missing nodes or if you don’t see the node you’re looking for, those won’t be converted, but it will make sure all other data is converted correctly.
One thing to note is that it is recommended to have neutral T-pose as reference pose. When retargeting animation, we assume their reference pose is same. We call this “Retarget Base Pose.” By default, it is from a reference pose. You can modify this at the bottom section in your “Retarget Manager” window. Retarget Base Pose is saved per Skeletal Mesh.

**Material Requirements
**
**Physically-Based Rendering Materials
**Whether or not the goal of your materials is to be photorealistic, it is required that your submission effectively uses UE4’s PBR materials. All PBR materials must have some form of node attached to the Base Color, Roughness, and Metallic nodes. You may use a map or a numerical value (including zero) but it must have some form of input in order to be accepted for the Marketplace.

[Ivey]

Preparing Your Assets: Blueprints

Please be sure to follow all steps and guidelines outlined in the UE Blueprints Documentation for setting up your assets correctly.

**Content folder structure
**See General Asset Requirements for how to structure your folders.

**Demo Levels
**We require that you add a Demo Level to your submission that allows the user to experience the functionality of your submission the way you intend it to be used.

&stc=1

**Technical Specifications:
**

• Number of Blueprints
• Input Mappings (If any input is included in your Complete Project, please include which methods of input are preconfigured (Gamepad, Keyboard, Mouse… etc.))
• Network Replicated (Yes/No)
• List of Features (Please include a full, comprehensive list of the features of your Blueprint)
• Intended Platforms
• Platforms Tested
• Documentation Included (Yes/No)
• Important/Additional Notes

Important note: Not every asset type will require all of these technical specifications, but please provide as much of this information as you can.

This not only helps us review your content, but it will help potential paying customers understand what they’re getting. It is a smart sales strategy to clearly communicate what you have to offer with as much information as possible.

will request additional information if we decide the technical specifications are not detailed enough.

We will always be reasonable, but we still reserve the right to reject submissions that are unwilling to offer enough information when requested.

**Package Delivery
**When you are finally ready to deliver your asset pack to us, please the Config, Content,and .Uproject files together and provide us with a download link.

&stc=1

Blueprint Requirements

**Demonstration Video
**All Blueprints submitted should include a video demonstrating how they are used. No Blueprint submissions will be accepted without a video.

**Blueprint Structure
**All Blueprints must be neatly laid out and make reasonable use of Blueprint functions to organize the overall logic structure. Functions, variables, and events should all use names that reflect their intended purpose or use in the Blueprint.

**Commenting and Documentation
**Blueprints must be thoroughly commented with explanations of the function and operation of the Blueprints. In general more useful comments will explain the ‘why?’ rather than the ‘how?’, and any comments that merely provide labels should be avoided.

You must include an in-editor tutorial blueprint asset that will walk users through implementation, application and modification of your asset.

Static Mesh Requirements

**Point of Origin
**The origin of your mesh will be the location that your mesh scales and rotates from once imported into Unreal Engine. This is generally represented by the world origin in most modeling applications. Be sure to position your model relative to that spot before exporting it, especially for modular meshes.

For example if you’re creating a modular wall piece, a good place for the origin is on the edge or the corner of the mesh so it can snap easily into place. Conversely, a statue on a plinth might work better with the origin at the bottom center of the mesh so that it can be easily rotated and scaled.

**Grid Snapping
**All static mesh content should snap together nicely on the standard 10cm grid where possible to retain modularity. If meshes contain edges that are meant to be adjacent to other meshes than those edges should be easily snapped to some multiple of 10cm.

**Triangle Counts and Texture Sizes
**Always keep the target platform in mind for the content, and be efficient in your use of triangle counts and texture sizes. Fewer vertices mean faster rendering, and for content targeting mobile platforms it is important to keep both triangle count texture sizes reasonably small to maintain performance.

**Texture Density
**Assets should be UV mapped so that 1 texture tile covers 1m in the game world to maintain a consistent texture density. For example, if you build a wall 2m in length the texture you apply to it should tile twice along the length of the wall. Unique or more complex assets may break this guideline, but only where justified.

**UV Layouts
**Generally for static meshes you’ll need two sets of UV coordinates. The first set is your base set of coordinates where you map diffuse, normal, and other maps to the mesh. The second set is your light map coordinates which have special considerations such as all UV islands must fall within the 0-1 UV space. Also, no islands may overlap, otherwise errors will be introduced in your lighting results.

**Material Requirements
**
**Physically-Based Rendering Materials
**Whether or not the goal of your materials is to be photorealistic, it is required that your submission effectively uses UE4’s PBR materials. All PBR materials must have some form of node attached to the Base Color, Roughness, and Metallic nodes. You may use a map or a numerical value (including zero) but it must have some form of input in order to be accepted for the Marketplace.

[Ivey]

Preparing Your Assets: Audio

Please be sure to follow all steps and guidelines outlined in the UE Audio Documentation for setting up your assets correctly.

**Content folder structure
**See General Asset Requirements for how to structure your folders.

**Technical Specifications:
**

• Number of Audio Wavs
• Number of Audio Cues
• Sample rate / bit rate (i.e. 44.1 kHz, 16bit Stereo WAVs)
• Does music/audio loop Yes/No
• Minutes of audio provided
• Intended Platforms
• Platforms Tested
• Documentation Included (Yes/No)
• Important/Additional Notes

Important note: Not every asset type will require all of these technical specifications, but please provide as much of this information as you can.

This not only helps us review your content, but it will help potential paying customers understand what they’re getting. It is a smart sales strategy to clearly communicate what you have to offer with as much information as possible.

will request additional information if we decide the technical specifications are not detailed enough.

We will always be reasonable, but we still reserve the right to reject submissions that are unwilling to offer enough information when requested.

**Package Delivery
**When you are finally ready to deliver your asset pack to us, please the Config, Content,and .Uproject files together and provide us with a download link.

&stc=1

[Ivey]

Preparing Your Assets: Arch Viz

Please be sure to follow all steps and guidelines outlined in the UE Documentation for setting up your assets correctly.

Content folder structure
See General Asset Requirements for how to structure your folders.

**Demo Levels
**We require that you add a Demo Level to your submission that allows the user to experience the functionality of your submission the way you intend it to be used.

&stc=1

**Overview Map
**All Assets packs must contain an overview map that lays out the content included in the package.

&stc=1

**Technical Specifications:
**

• Props scaled to Epic skeleton (Yes/No)
• Texture Size (please list textures for each resolution)
• Collision (Yes\No, and specify which type – custom, automatically generated, or per-poly?)
• Vertex Count
• LODs
• Number of Meshes
• Number of Materials and Material Instances
• Number of Textures
• Intended Platform
• Platforms Tested
• Documentation Included (Yes\No)
• Important/Additional Notes

**Package Delivery
**When you are finally ready to deliver your asset pack to us, please the Config,Content,and .Uproject files together and provide us with a download link.

&stc=1

Static Mesh Requirements

**Point of Origin
**The origin of your mesh will be the location that your mesh scales and rotates from once imported into Unreal Engine. This is generally represented by the world origin in most modeling applications. Be sure to position your model relative to that spot before exporting it, especially for modular meshes.

For example if you’re creating a modular wall piece, a good place for the origin is on the edge or the corner of the mesh so it can snap easily into place. Conversely, a statue on a plinth might work better with the origin at the bottom center of the mesh so that it can be easily rotated and scaled.

**Grid Snapping
**All static mesh content should snap together nicely on the standard 10cm grid where possible to retain modularity. If meshes contain edges that are meant to be adjacent to other meshes then those edges should be easily snapped to some multiple of 10cm.

**Triangle Counts and Texture Sizes
**Always keep the target platform in mind for the content, and be efficient in your use of triangle counts and texture sizes. Fewer vertices mean faster rendering, and for content targeting mobile platforms it is important to keep both triangle count texture sizes reasonably small to maintain performance.

**Texture Density
**Assets should be UV mapped so that 1 texture tile covers 1m in the game world to maintain a consistent texture density. For example, if you build a wall 2m in length the texture you apply to it should tile twice along the length of the wall. Unique or more complex assets may break this guideline, but only where justified.

**UV Layouts
**Generally for static meshes you’ll need two sets of UV coordinates. The first set is your base set of coordinates where you map diffuse, normal, and other maps to the mesh. The second set is your light map coordinates which have special considerations such as all UV islands must fall within the 0-1 UV space. Also, no islands may overlap, otherwise errors will be introduced in your lighting results.

**Material Requirements
**
**Physically-Based Rendering Materials
**Whether or not the goal of your materials is to be photorealistic, it is required that your submission effectively uses UE4’s PBR materials. All PBR materials must have some form of node attached to the Base Color, Roughness, and Metallic nodes. You may use a map or a numerical value (including zero) but it must have some form of input in order to be accepted for the Marketplace.

[Ivey]

Preparing Your Assets: 2D

Please be sure to follow all steps and guidelines outlined in the UE 2D Documentation for setting up your assets correctly.

**Content folder structure
**See General Asset Requirements for how to structure your folders.

**Demo Levels
**We require that you add a Demo Level to your submission that allows the user to experience the functionality of your submission the way you intend it to be used.

&stc=1

**Overview Map
**All asset packs must contain an overview map that lays out the content included in the package.

&stc=1

**Technical Specifications:
**

• Number of Blueprints
• Number of Materials
• Number of Textures
• Number of Widgets
• Intended Platforms
• Platforms Tested
• Important/Additional Notes

Important note: Not every asset type will require all of these technical specifications, but please provide as much of this information as you can. This not only helps us review your content, but it will help potential paying customers understand what they’re getting.

It is a smart sales strategy to clearly communicate what you have to offer with as much information as possible. will request additional information if we decide the technical specifications are not detailed enough.

We will always be reasonable, but we still reserve the right to reject submissions that are unwilling to offer enough information when requested.

**Package Delivery
**When you are finally ready to deliver your asset pack to us, please the Config, Content,and .Uproject files together and provide us with a download link.

&stc=1

**Material Requirements
**
**Physically-Based Rendering Materials
**Whether or not the goal of your materials is to be photorealistic, it is required that your submission effectively uses UE4’s PBR materials. All PBR materials must have some form of node attached to the Base Color, Roughness, and Metallic nodes. You may use a map or a numerical value (including zero) but it must have some form of input in order to be accepted for the Marketplace.