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, and 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 16bit textures which contain much more data than typical 8bit maps. 8bit 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.
8bit dithered textures are 16bit 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 8bit 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 doesn't include any compression options. As InstaLOD currently does not support JPEG texture baking, we recommend converting your PNG textures from InstaLOD into JPEG textures using an image editing software of choice to reduce the overall file size even further.
Baking JPEG textures will be supported in an upcoming version of InstaLOD.
16bit normal map PNG (9,5MB) vs 8bit 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 the 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.