Hi everyone. With Fab in Launcher coming out later this summer, we want to share some more information and guidelines to make sure that all creators including you have the best possible experience on Fab.
What’s happening
For background, one of the key things that creators will be able to do with Fab in Launcher is export exchange formats individually and in batches directly to certain digital content creation tools and engines. If you have been a Quixel Bridge user, you may be familiar with a similar capability in that tool.
This export capability will speed up workflows by enabling creators to quickly bring content into their projects without the manual setup of extracting and importing files.
Here’s a list of supported exchange formats, tools and engines. The formats and tools that will be offered for export when Fab launches is a starting point and we may add more in the future.
Fab in Launcher will support the export of:
- .fbx
- .gltf, .glb
- .obj
- .usd, .usdz
Into the following tools:
- Unreal Engine 5
- Unity
- Cinema 4D
- Maya (with the exception of .gltf and .glb)
- 3ds Max (with the exception of .gltf and .glb)
Why this matters for you
If you would like Fab users to be able to export your assets from Fab in Launcher, there are some guidelines that you will need to follow when preparing files for publication on Fab. If you already have products on Fab, we recommend updating them according to our specifications.
If your files are not prepared according to our guidelines, attempts by users to export them may be unsuccessful or the export may not be set up in the target tool as expected.
We have prepared a complete explanation, including examples, that is available in our Fab documentation, but also share a summary below. Please note that these recommendations may evolve as we continue to build and refine export functionality and only apply to exchange formats (e.g., .fbx, .obj). No changes are required for assets uploaded in native engine (UE, Unity) or DCC (e.g.,.c4d, .blend) formats.
How to prepare your assets for upload to Fab
Test by importing manually into a digital content creation (DCC) tool or engine
Users will choose one format (like .fbx, .usd, or .glb) when exporting your asset from Fab in Launcher. So, you can test the content you plan to upload under each file format by importing it manually into a DCC tool or engine (e.g., Maya, Blender). The asset is correctly set up if you do not need to manually change settings after import, like setting texture maps or materials.
Embed or properly reference textures
For formats like .gltf, .glb, .usd, .usdz, etc:
- Embed the texture files directly within the model file, or
- Use relative paths that point to external texture files.
Use recognized file naming conventions
If your material textures are not embedded into or referenced by your model files:
- Use the .fbx format for best compatibility.
- For .fbx and .obj formats, we will attempt to automatically map textures based on texture naming convention and folder structure. The recommended naming best practices are:
- Name textures based on the modelfile_suffix convention (e.g., cube_basecolor.png where cube.fbx is the model file)
- Use the following recognized suffixes:
| Texture Type | Recognized Suffixes |
|---|---|
| Base Color / Diffuse | basecolor, diffuse, color, albedo, col, alb |
| Ambient Occlusion | occlusion, ambientocclusion, ao, occ |
| Normals | normals, normal, normalmap, nmap, norm, nor |
| Roughness | roughness, rough, rou |
| Metalness | metalness, metallic, metal |
| Emissive | emission, emissive, emit |
| Displacement / Height | displacement, displ, disp, height, heightmap |
Recommended folder structure
- Include all textures alongside the model in the same folder. If you’ve uploaded textures separately under “Additional Files”, please note that these files will not be automatically linked to the model during export.
- Don’t include nested archives (no .zip inside the uploaded .zip)
- When your archive contains multiple individual assets:
- Use separate folders per asset, or
- If all files are at root level, use unique prefixes for each asset (e.g., rock1.fbx, rock2.fbx)
As a reminder, see our documentation for detailed explanation with examples.