Preparing models for AR/Web

About this document

Being able to display models in AR directly from your tablet or phone, produces an incredible sense of immersion. Unfortunately, not all 3D models can be rendered in AR by default due to the file-size limitations that AR and Web applications have. If the file size is too large it will require long loading times. If a model is too high-poly, the model will render at a low FPS (Frames per second) which inevitably results in stuttering 3D models and bad environment tracking. 

Reducing polygon count

Reducing the polygon count is one of the core requirements to make models renderable in AR. InstaLOD's vast feature toolkit has a variety of options to make your models AR-ready in no time. For more information on InstaLOD's polygon reduction tools please read the following article: Introduction to InstaLOD. 

A specific target polygon count for a finished AR application is difficult to generalize as hardware specifications can vary drastically between different mobile devices. Keep in mind that some scenes with multiple millions of polygons might still render fine whereas a scene with 5000 polygons might struggle, depending on the setup, number of lights and materials, and if the scene is static or dynamic. 

As a rough rule of thumb, anything between 200k up to 500k polygons should be renderable depending on the hardware of the mobile device used. 

Additional steps, such as those mentioned below, are able to optimize the overall rendering performance further whilst retaining the same polygon count. 

Reducing draw calls

Reducing draw calls is an important step to speed up the overall rendering performance of a scene. Material merging reduces the number of materials and textures in the scene by baking material parameters into textures and creating a texture atlas from the selected objects. This reduces the texture pool size, the number of materials in a scene, and subsequently reduces the number of draw calls.

For more information on this topic, please read the following article: Reducing draw calls by Material Merging

Texture file size

Textures can have a big impact on the overall file size. Normal maps tend to have a large contribution to the file size as they are usually baked as 16-bit textures which contain much more data than typical 8-bit maps. 8-bit normal maps are typically not desired as they can create banding which causes rendering artifacts. 

When baking Normal maps, for low file-size dependent applications such as AR or Web, make sure to bake '8bit dithered' maps in the 'Texture Output' window.

8-bit dithered textures are 16-bit maps that are sampled down to 8-bit maps, meaning that they don't create banding whilst benefiting from the low file size of an 8-bit texture.

Another factor that can drastically reduce the texture size is the texture file format. The default PNG file format is typically larger than JPEG as it doesn't include any compression options. 

16-bit normal map PNG (9,5MB) vs 8-bit dithered JPEG texture (1,37MB) (image enlarged)

File Export Format

Choosing the right export file format is an important final step, as this has a direct impact on the file size, including its supported attributes, features, and the number of software packages/engines that it can be imported into.

Some file formats allow for 'media embedding' which means that media such as textures are saved directly within the file. This feature is important to keep in mind when comparing file formats, as file formats without this feature might seem smaller as they don't include textures. Therefore, it is important to add the file size of the textures to the file size of the mesh to establish the true overall size. 

Some file formats can be used for specific applications such as USD which is natively supported on iPad or iPhones for AR use.