top of page

​

Preferred File Format

Our preferred file format  is FBX. Many files that open and import FBX files also export to that format. You can use the FBX SDK to convert OBJ, 3DS, DXF, and DAE files to FBX. Here is a list of programs you can use to export FBX files (in alphabetical order):

 

Autodesk 3DS Max, Autodesk MotionBuilder, Autodesk AutoCAD, Autodesk Maya, Autodesk Softimage, Bentley, Bforartists, Blender, Cheetah3D, Foundry, Google ARCore, Houdini, MS Paint3D, NewTek LightWave, Roblox, Sketchup, TouchDesigner, Unity, Unreal

 

Metrics & Scale

  • For reference

    • 1 Unreal Unit (UU) = 1 cm 

  • All assets should be scaled correctly.  

    • Level designers or blueprint authors should not have to tweak the scale of meshes to get them to conform in the editor.  

    • Scaling meshes in the engine should be treated as a scale override, not a scale correction.

  • Ensure Maya’s Units are set up correctly to centimeters so that the exported FBX is at the right scale.  

 

Environment Props

Modular Props

  • A good modular set has as few pieces as possible while still being able to achieve a wide range of variety. 

  • Build modular assets to a grid for easy snapping and to have a variety of incremented pieces.  

  • Modular pieces are usually textured using trim sheets and tiling textures, with vertex blending or decals to break up any visual repetition.

 

Geometry

  • Minimize the number of elements per object.

  • Combine models to have a reasonable amount of triangles per element (e.g. 300+ per element).

  • Overall polycount of one model should be no more then 63 000 triangles.

  • Material: up to 10 material slots per 1 object

  • All Meshes Must Have Collision - Regardless of whether an asset is going to be used for collision in a level, all meshes      should have proper collision defined.  This helps the engine with things such as bounds calculations, occlusion, and lighting.  Collision should also be well-formed to the asset.

  • Limit UV seams and hard edges as it results in more vertices for the hardware. In the worst case, high poly meshes with hard edges result in 3 times more vertices than reported in modelling applications.

  • The vertex processing cost for Skeletal Meshes is higher than for Static Meshes.

  • The vertex processing cost gets larger when adding morph targets or when using WorldPositionOffset. Texture lookups        can be quite slow due to caching.

  • Tessellation adds quite a lot of extra cost and should be avoided when possible. Pre-tessellated meshes are usually faster.

  • Very large meshes can be split for better culling. This is for view culling, as light culling is usually done at a finer granularity.

  • Adjust the draw distance on smaller objects to allow for better culling.

  • Billboards, imposter meshes, or skybox textures can be used to efficiently fake detailed geometry.

  • Good level design takes occlusion culling into account (add visibility blockers for better performance).  Use r.VisualizeOccludedPrimitives to check this.

  • Verify LOD are set up with aggressive transition ranges. A LOD should use vertex count by at least 2x. 

  • All meshes, regardless how they are to be used, should not be missing UVs.

  • All meshes, regardless how they are to be used, should have valid non-overlapping UVs.   However, if the mesh is textured using a strip-map technique, overlapping UVs are ok.

  • Any mesh that can be seen at varying distances should have proper LODs.

  • Modular, socketless assets should snap together cleanly based on our grid settings of 10U

 

Materials

  • Opaque materials are fastest due to having the best z buffer culling, masked are a bit slower, and translucent materials are slowest because of overdraw.

  • Materials with few shader instructions and texture lookups run faster.  To optimize materials, use Material Editor stats and the view mode ShaderComplexity.

  • Some material expressions are more costly (sin, pow, cos, divide, Noise).  The fastest expressions include: multiply, add, subtract, as well as clamp() when using 0 and 1.

  • Shading models have a cost: Unlit is fastest, Lit is what should be used mostly, and other models are more expensive.

  • Decal performance cost scales with the number of pixels they cover.
     

Textures

  • All textures, except for UI textures, must have its dimensions in multiples of powers of 2.  Textures do not have to be square.

    • e.g. 128x512, 1024x1024, 2048x1024, 1024x2048, 1x512.

  • All UI textures must have dimensions that are divisible by two.  This allows the texture to be compressed.

  • No texture should have a dimension that exceeds 8192, unless you have a very explicit reason to do so. 

  • Every texture has a Texture Group property used for LODing, and this should be set correctly based on its use.  

    • For example, all UI textures should belong in the UI texture group.

  • Every texture has a Compression Settings property, and this should be set correctly based on its use. 

  • All textures should be of a size appropriate for their standard use case.

    • A general guideline for the project’s texture density is 8 pixels per 1 unit, therefore, a texture that is meant to be applied to a 100x100 unit cube should be 1024x1024, as that is the closest power of 2 that matches our desired texture density.

  • Never disable mipmaps if the texture can be seen on a smaller scale, to avoid slowdowns due to texture cache misses.

  • Smaller texture formats result in faster materials (e.g. DXT1 is 4 bits per pixel, DXT5 is 8 bpp, ARGB uncompressed is 32 bpp).

  • Lower resolution textures can be faster (when magnified).  Sometimes they can be even smoother, as bilinear filtering can result in more shades than the texture format can express.



Naming convention: https://www.tomlooman.com/ue4-naming-convention/

​

bottom of page