1
\$\begingroup\$

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.

Could anybody please help me I have been at this for hours..

\$\endgroup\$
4
  • 4
    \$\begingroup\$ You could use less polygons. \$\endgroup\$ Commented Jan 20, 2013 at 21:33
  • \$\begingroup\$ 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. \$\endgroup\$
    – dreta
    Commented Jan 20, 2013 at 21:45
  • \$\begingroup\$ 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? \$\endgroup\$ Commented Jan 20, 2013 at 22:19
  • \$\begingroup\$ 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. \$\endgroup\$ Commented Jan 20, 2013 at 23:16

2 Answers 2

3
\$\begingroup\$

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).

\$\endgroup\$
1
\$\begingroup\$

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.

\$\endgroup\$
1
  • \$\begingroup\$ 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 \$\endgroup\$
    – tigrou
    Commented Feb 27, 2013 at 14:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .