What are the pros. and cons. of different representations a custom geometry format for a mobile based engine?

Question

I am trying to create 3D model importer for my mobile based engine.

These are what I am considering:

1. Convert .obj file to text based structure like JSON or custom.

   • So, basically, convert .obj file to structure to fit my engine, so, it could be a little bit faster for loading time.
   • Pros: Easy, and cross platform.
   • Cons: This is text file, and maybe could be slow for parsing and string manipulation?

2. Convert .obj file to Binary that fits to my engine.

   • Use serialization and save with specific structure to binary format
   • Pros: Faster
   • Cons: It may painful for multi-platform like Java and Objective-c?

3. Convert .obj file to .java or .h(.m) file, and attach to source code.

   • Export .obj file as .java and .h(.m), so I can use inside of code
   • Pros: Easy and Faster(?)
   • Cons: (?)

First time, I didn't know about #3 method, but I found some article that people doing this for simple small game. And my game is also small too, so I am considering more #3 method.

Which method is popular and is there more pros and cons ?

Answer 1

First of all I think it's best to build a converter from your source format to your custom format. I suggest you use Assimp library because it supports multiple types of files, this way you can build a converter that uses Assimp to read multiple file formats and convert it to your file format without the need to write multiple converters for each file format, Assimpt will save you alot of time.

Now regarding your custom file formats, it really depends on your requirements:

Convert .obj file to String based structure like JSON or custom.

• It is easy to read and manipulate (This is more useful in testing and debugging).
• String files are usually slower to parse, on mobiles you usually need every bit of processing power (I assume but I don't have on-hand experience with it).
• You will usually end up with large file sizes this is bad especially on Mobiles where storage is usually limited.

In general I don't recommend this for mobile platforms, could be only for testing, if you are going to go that way, consider a compressed XML or JSON this way you will save alot of space. But I don't know if performance will be good, you need to test and profile.

Convert .obj file to Binary that fits to my engine.

• This is good for performance and size.
• Will be hard to edit manually
• You need to make sure you handle endianess correctly on multiple platforms

Convert .obj file to .java or .h(.m) file, and attach to source code.

Never do this, unless you are building a basic prototype or a small test case, where you don't need to go through the trouble of writing a custom parser (but eventually you will need to write one).

This is bad because it couples your input data to your source code, so if you want to change anything you need to recompile.

Answer 2

concept3d gave a good reason not to use option 3. Convert .obj file to .java or .h(.m) file, and attach to source code. Another reason is that Java doesn't support this approach well, because Java bytecode format cannot store arbitrary byte arrays. If you have private static byte[] DATA = {0x50, 0x2F, ...}; in your class, the compiler generates code for a static initializer that allocates the byte array and assigns each element of the array separately.

The only non-primitive data that .class files can hold is UTF8 encoded strings. It is possible to abuse this to hold your data in strings, but it's not pretty or efficient.