2
\$\begingroup\$

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 ?

\$\endgroup\$
6
  • \$\begingroup\$ Can you elaborate why don't you want to read the file directly ? People usually convert files for performance reasons. \$\endgroup\$
    – concept3d
    Dec 26, 2013 at 7:10
  • \$\begingroup\$ Yes. I thought it is pretty slow. Also, I think it will reach memory issue. Because Mobile device is has lower memory and creating huge String will may trigger OutOfMemory. (I haven't test yet). Looks like it is my misunderstanding??? \$\endgroup\$
    – PowerDDang
    Dec 26, 2013 at 9:19
  • \$\begingroup\$ but you also need to write a converter from that file format to your engine file format. It highly depends on your use scenario if your engine is being used only by you it is Ok. I usually use obj directly for testing. But this doesn't work for release so I build a converter to custom file format. \$\endgroup\$
    – concept3d
    Dec 26, 2013 at 9:22
  • \$\begingroup\$ Yes. I am going to create converter. My problem is which format will be the best. 1) Normal String file (like JSON), 2) Custom Binary file, 3) Convert directly to source code. I am thinking 1 or 3 because it is just easier for multi platform. I assume binary needs to be separate based on language?? \$\endgroup\$
    – PowerDDang
    Dec 26, 2013 at 9:27
  • \$\begingroup\$ are you only going to store geometry data or other data like transforms, materials etc ? \$\endgroup\$
    – concept3d
    Dec 26, 2013 at 9:32

2 Answers 2

3
\$\begingroup\$

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.

\$\endgroup\$
2
  • \$\begingroup\$ You are my saviour. Completely understand. I will try library. It will save a lot of time like you said. Thank you!!!!! (And also fast response too!!!) \$\endgroup\$
    – PowerDDang
    Dec 26, 2013 at 9:48
  • \$\begingroup\$ @PowerDDang You are always welcome to ask anything. \$\endgroup\$
    – concept3d
    Dec 26, 2013 at 9:53
0
\$\begingroup\$

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.

\$\endgroup\$

You must log in to answer this question.

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