Unity Mobile 3D Asset Optimization Checklist: Meshes, Textures, Materials, LODs and Colliders

Mobile optimization is not one setting and it is not one polygon number.

A 30,000-triangle object can be cheap in one scene and expensive in another. A low-poly mesh can still be costly if it uses too many materials, large textures, transparent shaders, complex colliders or hundreds of separate renderers. The correct target depends on the camera, device class, scene density, lighting, shaders and how often the asset appears.

The useful goal is therefore not “make every model as small as possible.” It is:

keep the visual information that matters to the player while removing work the target device does not need.

This checklist is designed for artists and Unity developers reviewing a 3D asset before it becomes part of a mobile production scene.

If you want a first automated pass for common import and prefab issues, use the free Unity Asset Preflight Auditor and then review the findings in context.

1. Test on the device class you actually target

Desktop Editor performance is not a reliable substitute for mobile hardware.

Before changing assets, define at least one representative target device. Ideally use a small range:

• lower-end supported device;
• typical target device;
• higher-end device if you plan scalable quality settings.

Then profile a realistic scene, not an empty test room.

A mesh that looks harmless alone can become expensive when fifty copies are visible, shadows are enabled and each copy uses several materials.

Record a baseline before optimizing so you can tell whether a change helped.

2. Optimize for what the camera can see

Start with the expected viewing distance.

Ask:

• how large is the asset on screen?
• can the player approach it closely?
• is it a hero object or background dressing?
• does the silhouette matter more than surface detail?
• will dozens of copies be visible at the same time?

Spend geometry on the silhouette and on parts that noticeably change under animation or close inspection.

Remove or simplify geometry that is permanently hidden inside the object, pressed against a wall, buried under the ground or too small to affect the final image.

Do not destroy useful geometry just to hit an arbitrary triangle target. Optimize where the player cannot tell the difference.

3. Check the number of separate renderers

A scene can contain a modest triangle count and still suffer from too much object-management and rendering overhead.

Review whether one visual object has been split into many tiny mesh objects without a practical reason.

Common examples include:

• every metal band as a separate object;
• every stone in a wall as a separate renderer;
• decorative bolts exported as separate meshes;
• repeated pieces that could be combined for a static prop.

Combining is not always correct. Separate objects are useful when they need different animation, visibility, collision or interaction. The point is to avoid unnecessary fragmentation.

4. Reduce material count before obsessing over triangles

Each extra material slot can create additional rendering work.

For a mobile prop, ask whether several materials can share one texture set or atlas without making the workflow worse.

Check:

• how many material slots are on each renderer;
• whether visually identical materials were duplicated;
• whether separate materials exist only because the source file was assembled from multiple objects;
• whether multiple small props can share a common trim sheet or atlas;
• whether shader variants are more complex than the asset needs.

One clean shared material can be more valuable than shaving a few hundred triangles from the mesh.

5. Treat transparency as expensive until profiling proves otherwise

Transparent and alpha-blended surfaces can create overdraw, especially when many layers overlap on a small screen.

Review foliage, particles, cloth edges, magical effects, windows and decorative cards.

Where the visual style allows it, consider:

• alpha clipping instead of full blending;
• tighter transparent geometry around the visible shape;
• fewer overlapping layers;
• smaller effect coverage on screen;
• lower-cost shaders for repeated background elements.

Do not replace every transparent surface automatically. Test the real scene and visual requirement.

6. Give texture resolution a reason

Large textures cost memory even when the object is small on screen.

For every texture, ask what visible detail the resolution preserves at the normal viewing distance.

Review:

• base color;
• normal maps;
• masks and packed maps;
• emission;
• detail textures;
• lightmaps if relevant.

A small background prop usually does not need the same texture budget as a close-up character or hero weapon.

Unity's platform overrides let you use smaller texture limits or different compression settings on mobile without destroying the source art.

Keep the master texture at a sensible production resolution, then tune the imported mobile version.

7. Use texture compression appropriate to the target

Compression is a platform decision, not just an art decision.

The correct format depends on the target devices, quality needs, alpha requirements and Unity platform settings.

Instead of assuming one universal compression format:

1. select the texture in Unity;
2. inspect the platform override;
3. check the estimated memory footprint;
4. compare visible artifacts on device;
5. choose the smallest acceptable result.

Pay extra attention to normal maps and textures with alpha, because aggressive settings can create obvious artifacts.

8. Pack masks when the shader supports it

If your shader can read several grayscale masks from different channels of one texture, channel packing may reduce the number of texture samples and files.

Typical candidates include:

• metallic;
• roughness or smoothness;
• ambient occlusion;
• emission mask;
• custom effect masks.

Only do this when it fits the project's shader pipeline and makes maintenance easier rather than harder.

9. Review mipmaps instead of disabling them globally

Mipmaps help reduce aliasing and can improve texture sampling when objects become smaller on screen, but they also consume memory.

Do not use a blanket rule.

For world-space textures that appear at different distances, mipmaps are usually useful. For some UI or special-purpose textures they may be unnecessary.

Judge the setting by usage, not by file type alone.

10. Add LODs where they actually save meaningful work

Level of Detail is useful when an asset stays visible while occupying progressively fewer pixels.

Good LOD candidates include:

• buildings;
• trees;
• large rocks;
• repeated environment props;
• large decorative structures;
• objects visible across long distances.

A tiny prop that disappears from view quickly may not justify several manually maintained LOD meshes.

When creating LODs:

• preserve the outer silhouette first;
• collapse small interior details early;
• reduce material complexity when practical;
• verify transitions from the real gameplay camera;
• avoid a first LOD that is almost identical to the source mesh.

The purpose is measurable savings, not simply having “LOD0 / LOD1 / LOD2” folders.

11. Use culling aggressively for things the player cannot see

LOD reduces the cost of visible objects. Culling removes invisible work entirely.

Depending on the project, review:

• camera frustum culling;
• occlusion culling for suitable environments;
• distance-based disabling for small decorative objects;
• particle and effect culling;
• shadow distance;
• whether far background props need to stay active at all.

The best optimized mesh is still more expensive than a mesh that does not need to render.

12. Keep colliders simpler than the visual mesh

Collision often does not need visual precision.

For static props, prefer simple primitive or low-complexity colliders where gameplay allows it.

Examples:

• a crate can often use a box collider;
• a pillar can often use a capsule or simplified convex shape;
• a decorative wall can use a clean box-like collision volume;
• a pile of small objects may need one combined interaction volume instead of per-piece collision.

Mesh colliders have valid uses, but do not make them the default simply because the mesh already exists.

Check whether the collider is used for:

• player movement;
• projectiles;
• clicks/taps;
• physics simulation;
• trigger volumes;
• placement validation.

Build the collider for that function.

13. Review Read/Write on meshes

Unity may retain additional CPU-side mesh data when Read/Write is enabled.

If runtime code does not need to modify or read the mesh data, review whether the option can be disabled.

Do not disable it blindly if systems such as runtime mesh processing require it.

The Unity Asset Preflight Auditor can flag readable models so you can review them instead of opening every importer manually.

14. Check normals and tangents import choices

Imported data can affect both file size and runtime memory.

Depending on the asset and shader, Unity may import or calculate normals and tangents.

Use the option that preserves the intended shading with the least unnecessary data.

Test hard-surface assets carefully: changing normal handling can visibly alter beveled edges and baked normal maps.

15. Remove unused animation data

A static prop does not need animation-related complexity.

For animated assets, review whether the imported file includes unnecessary clips, bones, curves or transforms.

For static environment pieces, confirm they are imported as static meshes and are not carrying irrelevant rig data from the source scene.

16. Keep prefab references clean

Optimization is not useful if the prefab is fragile.

Before shipping or integrating an optimized asset, check:

• missing scripts;
• missing materials;
• missing textures;
• unexpected nested prefabs;
• inactive objects left from production;
• debug components;
• unnecessary lights or cameras;
• duplicate colliders;
• accidental high-cost effects enabled by default.

An optimized mesh inside a broken prefab still creates production cost.

17. Review shadow settings per asset class

Dynamic shadows can be visually valuable and expensive.

Not every decorative object needs to cast a shadow at every distance.

Consider whether the asset should:

• cast shadows;
• receive shadows;
• use baked lighting;
• use simplified shadow geometry;
• stop casting beyond a distance;
• be grouped into a lower-cost lighting strategy.

Again, test in the actual project's render pipeline and target hardware.

18. Watch shader complexity and variant growth

A simple mesh using an expensive shader can cost more than a denser mesh using a cheap shader.

Review features such as:

• transparency;
• multiple texture samples;
• parallax;
• expensive procedural effects;
• real-time reflections;
• unnecessary keywords and variants;
• per-pixel features on tiny repeated objects.

Use the simplest material that still supports the intended visual role.

19. Test repeated placement, not just one asset

A mobile scene rarely contains one prop.

Create a stress test that resembles the actual level:

• dozens of repeated props;
• realistic lights;
• real camera distance;
• UI active;
• particles and gameplay systems running;
• representative environment density.

This exposes costs that are invisible in an isolated preview scene.

20. Profile after each meaningful change

Optimization without measurement easily becomes destructive busywork.

After a meaningful change, compare:

• frame time;
• CPU and GPU load;
• rendering batches/draw calls where relevant;
• memory use;
• texture memory;
• mesh memory;
• loading time;
• visual quality on target devices.

If a change saves almost nothing but noticeably damages the art, revert it.

If a visually invisible change removes repeated work across the whole scene, keep it.

A practical review order

When time is limited, use this sequence:

1. profile the representative scene;
2. identify the actual bottleneck;
3. review material count and repeated renderers;
4. review texture sizes and compression;
5. simplify collision;
6. add useful LODs and distance culling;
7. review import settings such as Read/Write;
8. remove unused components and references;
9. profile again on device;
10. document the mobile-specific overrides.

This keeps the work connected to a measurable problem.

Final mobile 3D asset checklist

Before calling the asset mobile-ready, verify:

• tested on representative target hardware;
• no hidden or useless geometry that is expensive at scale;
• reasonable renderer/object count;
• material slots are intentional;
• texture resolutions match on-screen importance;
• mobile texture compression has been reviewed;
• transparency is justified;
• LODs exist where they create real savings;
• distant or hidden content can be culled;
• colliders are no more complex than gameplay requires;
• Read/Write is enabled only when needed;
• prefab references are clean;
• shadows and shader features are intentional;
• repeated-placement stress test has been run;
• final decision is based on profiling, not a magic polygon limit.

For a broader technical handoff pass, continue with the Unity Asset QA Checklist and the Blender to Unity FBX Checklist.

You can also use the Unity game-development resource hub to move between QA, optimization, asset budgeting and production tools without hunting through the full site.