Setting up Assets for Fab in Launcher

Fab in the Epic Games Launcher supports one-click export to a variety of digital content creation (DCC) tools and engines, similar to how Quixel Bridge functions. This desktop version of Fab expands the user's workflow of acquiring assets to importing them into an application.   

To learn how to use the launcher, see Exporting Assets from Fab in Launcher.

This guide outlines key information and best practices to help ensure that your content is set up correctly when a user exports it from the launcher. Preparing your assets properly not only saves time but also improves performance, compatibility, and visual quality across DCCs and engines. 

To ensure smooth exports and accurate setup, please review the criteria below. Make any necessary updates —or let the Fab support team know if you or your organization follow other widely adopted standards. The team is here to help support your workflow.

Supported DCCs, Engines, and File Formats

The table below lists the supported versions and renderers for each application the launcher can export to.

The table below lists the supported file formats for each application. 

How to Prepare Your Assets for Upload to Fab

The recommendations below are best practices for how you should package your content on Fab to avoid any issues when that content is exported into a DCC or engine using Fab in Launcher. How the content appears and behaves after export depends largely on the DCC or engine itself.

Testing the Package You Intend to Upload

When users export your asset from Fab in Launcher, they will choose one format (like .fbx, .usd, or .glb). You can test each of the file formats you plan to upload by importing it manually into a DCC or engine (for example, Maya or Blender), so you know exactly how it behaves.

Embedding Information in the Model File

Fab in Launcher relies on embedded information for the following file formats:

• .gltf

• .glb

• .usd

• .usdz

To make sure your models load with the correct materials and automatically link to their textures, it’s important to either:

• Embed the texture files directly within the model file.

• Use relative paths that point to external texture files placed alongside the model.

Following this practice helps ensure seamless material setup and minimizes the chance of missing or incorrectly linked textures during export or import into DCCs or engines.

Use Recognized File Naming Conventions

If your material textures are not embedded/referenced in your models:

• .fbx will ensure the best compatibility.

• For .fbx and .obj formats, Fab in Launcher will attempt to automatically map textures based on file names and directory structure. The general steps for this automatic mapping are:

  1. Detect model files based on the .fbx or .obj extensions.

  2. Try to find texture maps containing the model file name.

  3. Detect a common suffix in the texture file name to determine the type of texture map.

  4. Link detected texture maps to material channels.

Texture Naming Convention Example

Name textures based on the modelfile_suffix convention, for example:

• cube_basecolor.png

• cube_roughness.png

• cube_normal.png

Example

Differently-named models and textures (for example, cube_*.png andsphere_*.png) will be treated as separate assets.

Recognized Suffixes for Texture Naming

Texture files in formats like .jpg, .png, and similar are automatically matched to models based on their suffixes. By using recognized suffixes (for example, _basecolor, _normal, _roughness), Fab in Launcher can accurately assign each texture to the correct material channel during export.

To ensure correct material setup, use the following recognized suffixes for each texture type:

Normal Maps Convention

You must provide normal maps in tangent space, in the DirectX convention by default, to use them with Fab in Launcher. You can use additional suffixes to specify the convention you use in the provided normal map. If you do not provide an additional suffix, DirectX will be assumed.

• If you author normal maps as OpenGL, use a suffix such as opengl, gl, or normalsgl.

• If you use DirectX, use a suffix such as directx, dx, or normdx.

Recommended Folder Structure

• Include all textures alongside the Model in the same directory.

• Automatic texture matching will not occur within subfolders if the parent folder contains a .gltf, .glb, .usd, or .usdz file. Keep textures at the same directory level as the model file for correct association.

• Fab in Launcher does not support archives within archives (for example, a .zip file inside another .zip file). Please ensure your archive is flat and self-contained.

• When your archive contains multiple individual assets, do either of the following:

  • If all files are at root level, use unique prefixes for each asset (for example, rock1.fbx, rock2.fbx)

  • Use separate folders per asset.

Working with Multiple Assets

When your archive contains multiple individual assets, Fab in Launcher attempts to export each one. To ensure these assets are properly recognized and textures are correctly matched, you can organize them in one of two ways:

1. Group Assets by Directory

Organizing assets into separate folders helps Fab in Launcher treat each group as a standalone asset. 

Example Archive Structure:

Result:

• rock1.fbx and rock2.fbx will each be exported with their corresponding textures.

• A third material named additionalmaterial will also be generated in the user’s export location, based on its matching texture prefix.

2. Use Multiple Prefixes Without Folders

If your archive uses unique prefixes for each asset and keeps all files at the root level, Fab in Launcher will still correctly identify and export them—just as if they were organized into separate directories.

Example Archive Structure:

Result:

• rock1.fbx and rock2.fbx will be treated as separate assets, with their textures automatically matched based on the shared prefix.

• additionalmaterial will be created as a standalone material.

• rocks_roughness.jpg will only be used if a model with a matching rocks prefix is included—otherwise, it will be ignored.

Using consistent prefixes is a flexible alternative to folder grouping and helps maintain clarity and compatibility during export.

Examples of Valid Archive Structures

To help you prepare your content for smooth export through Fab in Launcher, below are several examples of archive structures that Fab can correctly interpret and process.

0 Models, 1 Material

• Exported as: A standalone material.

0 Models, 2 Materials (Same Directory)

• Exported as: Two separate standalone materials.

0 Models, 2 Materials (Different Directories)

• Exported as: Two separate standalone materials.

1 FBX Model, No Textures

• Exported as: The model only. If the FBX includes materials, they will be preserved.

1 Model, 1 Material

• Exported as: The model with a newly created material replacing the original.

3 Models Sharing One Material

• Exported as: All models with a shared, newly created material.

“Pack” with 2 Models + 1 Additional Material (Flat Structure)

• Exported as: Two models with matched materials, plus a third standalone material.

“Pack” with 2 Models + 1 Additional Material (Structured by Folders)

• Exported as: Same outcome as above, using directory separation.

1 glTF Model with Referenced Textures

• Exported as: The model only, using textures from the textures / directory only if they are explicitly referenced in the .gltf file.

1 glTF Model + 1 Standalone Material in Separate Folders

• Exported as:

  • The model with linked textures (if referenced).

  • A standalone material built from the contents of dir2.

These formats ensure optimal performance and compatibility when using Fab in Launcher. 

Other Tips

Textures and Materials

• Use PBR materials: Export with Base Color, Metallic, Roughness, Normal maps, and other similar materials. Make sure the maps are compliant with either the Specular or Metallic workflow.

• Resolution: Keep texture resolution as powers of two (for example, 512x512, 1024x1024).

• Texture size: Balance quality and performance. Avoid textures larger than 4K unless necessary.

• File types: 

  • .png or .tga are preferred 8bit formats.

  • You can use .jpg but you should be mindful of the compression artifacts.

  • If using .png, use uncompressed for best quality.

  • For 16/32 bits, use .png or .exr.

• Color Space: Make sure your textures are in the correct color space.

• Assign one material only per surface or object.

File Naming

• Use lowercase letters.

• Use underscores instead of spaces.

• Avoid using non-ASCII characters (for example, accented letters or symbols)

Geometry and Optimization

• Polygon count: Optimize geometry — aim for the lowest poly count that preserves silhouette and detail.

• No ngons: Use only quads or tris.

• Normals: Ensure normals are correct and smoothed where needed.

• Pivot points: Set the origin of your mesh correctly for animations and alignment.

• Clean transforms: Apply scale/rotation in your 3D software before exporting.

• Non-manifold geometry: Avoid! These can cause issues in rendering or physics.

• Apply transforms: Reset transformations before export to avoid scaling issues.

• Check mobile performance if your model is intended for AR/VR or web viewing.

Camera and Lighting

• Default camera: Position your model facing forward (Z+ or Y+ depending on platform).

• Avoid baking lighting unless you are deliberately going for baked static lighting.