# Compress / make Blender .obj file smaller

I have been learning the basics of blender for the best part of the day, and I still cannot figure out how to make models(imported) smaller in file size(where their original file size is 2MB+).

The reason why I want to make the files smaller is because I am trying to use them in my iPhone application, however the app crashes when the .obj files are over 1MB.

• You could use less polygons. – Luis Estrada Jan 20 '13 at 21:33
• You will have to decompress the file in software before rendering no matter what, so i don't see a point to this TBH. What exactly causes the crash? Also, as Luis pointed out, a 2MB .obj file is fairly big for an iPhone app. – dreta Jan 20 '13 at 21:45
• The crash is caused because the file is too large to load. I am using AC3D (inivis.com/features.html) and memention.com/ac3dreader/usage to load the models in my app. I am also using blender to create or import and export in .obj format for the models. I can use all the formats listed in the first link. (basically the formats compatible with iOS apps) What procedure could I take for creating a 3d human model and loading it in an iphone app? – Joey Tawadrous Jan 20 '13 at 22:19
• OBJ is a text file and most of it are numbers (ASCII 48-57). You can compress it by using less polygons, or rounding decimal numbers (43.2614672346 -> 43.26 ... three times smaller file), or compress it with standard alogirhtms (ZIP). I am sure there are lots of ZIP implementations in Objective C. – Ivan Kuckir Jan 20 '13 at 23:16

AFAIK, there's no native IOS support for .obj format (referring to IOS OpenGL APIs). So either you use some IOS app that can import .obj format or you've made your own such parser.

If it's a 3rd party app, check and see if it cannot read zipped versions of the .obj files. If it does (and is properly implemented) this will use less memory when parsing your .obj file(s)

If it's your own parser, update it so that it can read zipped .obj files.

There are also .obj optimizers, which make your .obj file smaller by either rounding up values or removing vertices (if they're too close together etc).

Very few kinds of assets are expressed effectively in text-based formats.

In the case of .obj meshes, the data in the file is not suitable for direct consumption in a 3D API either, as it has multiple indices per vertex and the possibility of more than three vertices per face.

Consider making a very simple binary file format suitable for direct use with your target platform. It would essentially consist of a header outlining the vertex and index counts for each geometry, followed by solidly packed blobs of vertex and index data.

Again, text formats for bulk data rarely make much sense, at least not at the deployment end of your pipeline. The closer to the end consumer a file format is, the more specific and optimized it should be.

• Using text based file formats for assets can sometimes be useful during development (for trying stuff and debugging), but because they results in larger files and increase loading times, binary format is preferred in production. Even John Carmack admitted in some interview that using text based file format for Doom3 was a mistake. See here : fabiensanglard.net/doom3/interviews.php – tigrou Feb 27 '13 at 14:24