4

Ok... I'm doing simple OpenGL ES programming and when I say simple, the most complicated things I do aren't much more than glorified beveled cubes and L-shapes. (Think very Tetris but in 3D.) However, getting all that vertex data into an app is either a) hand-coded (UGH!) or b) 3rd-party game engine (double-UGH!!!) or you use some 3rd-party filetype importer. (Partial Ugh!)

With one exception.

I've been using a program on the Mac called Cheetah3D which is a pretty good modeler (not great, but solid... good) and the one thing it has that I haven't seen elsewhere is the ability to export your models directly to c-ready header files. It exports all the arrays for you and even gives you the code to render them (albeit in a commented out block as a reference.)

While this is great for 90% of what we do, there are some things the modeler can't, like allowing me to specify the same vertex for two different faces but using a different normal for each one... or even to mix flat and curved normals (or rather how they render) in the same model.

Note those features are easily described in an .obj file since your normals and vertices are in different arrays that you can easily specify together with faces but they don't come out in the header file that way.

SO... obj files (or any other file type that will work for that matter...) best way to get it into your code?

Thoughts?

Mark A. Donohoe
  • 28,442
  • 25
  • 137
  • 286

4 Answers4

3

OBJ file format.

Anyone doing 3D work, should at sometime write a obj model loader.

Its a very simple file format.

v
t
n
f

Where:

  • v is the vertices.
  • t is the texture coordinates.
  • n is the normal.
  • f is the face.

An example obj file segment:

v 1.0 0.1 0.1
t 1.0 0.0
n 1.0 1.0
f 1/1/1 1/1/1 1/1/1

All it takes is storing four collections of the above, and when it comes to rendering the face of a vertex, use the index and perform simple look ups. Simple file I/O is very easy to do in any language, so all in all, using an obj file is quite easy.

Naturally, the downside to obj files is they can get quite big. Personally, I've never found this an issue, and often take the obj file format as a starting point and remove some of the duplication to create a custom file format specially for my application.

Finglas
  • 15,518
  • 10
  • 56
  • 89
  • I saw you can omit the texture data (we don't use them... just colors and lighting) and instead of v/t/n you can just use v/n. But I can't get a confirmation if that's considered standard. Collada seems to have promise tho since XML parsing is native to most platforms. But as I said above... Collada or ObJ or anything else... I kinda like not having them be outside of the app where anyone can jsut grab them and open them up (or even modify them!) outside of the program. – Mark A. Donohoe Jan 09 '10 at 01:04
  • Don't worry about standards. Just go with what your modeller makes. Further work must follow this standard from then on. As I said, you can edit obj files to be whatever you want. – Finglas Jan 09 '10 at 11:10
  • I guess the question is, how do you convert the f to indices in the model header file (and what are the `1/1/1`'s? – ina Oct 09 '10 at 01:15
  • @ina, the 1/1/1s are the indicies. His typed example is just confusing because he made them all 1's. The format in his example is v/t/n so 1/1/1 is the first vertex index, the first texture index and the first normal index. – Mark A. Donohoe Apr 01 '11 at 04:40
  • @Ina, the other good thing is that the obj format lets you specify per-vertex normals, not just per-face as other specs/modelers do. That adds a lot of flexibility with what you can do. (For instance, a beveled cube can easily be made to look like those beveled edges are rounded by using the same normals as the major faces for the vertices along the edges of the beveled sides. It's a neat trick that gives you very cool results. I can't believe more programs don't support per-vertex normals. – Mark A. Donohoe Jun 29 '11 at 02:59
2

OBJ files were used quite a bit historically and it isn't that difficult to roll your own importer or at least an importer that works for simple models you care about. Just handle verts, colors & normals to start and you'll be fine for the simple models you are describing. Sure it will barf if you try to read in arbitrary OBJ files--but just don't do that. ;^)

You certainly don't want to recompile each time you modify your model, if I'm reading your cheetah3d comment right. That will get tedious very fast.

goger
  • 583
  • 7
  • 15
  • Precisely (the recompile bit!) That's why I like the idea of OBJ files. Then again, in a lot of (most) cases, once the models are done they won't change. Again, simple primitive types, and I'm not really crazy about having the models outside the compiled app. But for right now I'll settle for getting it in at all. – Mark A. Donohoe Jan 09 '10 at 00:59
  • Actually, I'm starting to look at possibly making an OBJ to H-file converter so I can have the best of both worlds. Plus, there's some features that OBJ supports but most modelers don't such as per-vertex normals, not just face. Actually... anyone know of any sub-$500 modelers that let you do per-vertex normals? Please don't guess... I've already tried about eight packages. (My favorites in order are Bonzai3d, Cheetah & Hexagon I've also looked at Swift3D, FormZ, Blender, Cinema4D, SketchUp, SolidWorks – Mark A. Donohoe Jan 09 '10 at 01:09
2

For sure, you don't want to embed anything inti your code, loading OBJ is a good option but different modelers can have their own implementations of OBJ, as there is no official standard for the format. It's simple but I've seen many situations where application X can't load an OBJ from app Y. So if you ever plan on authoring assets from different packages take a peek at their outputted OBJ files to make sure they follow the same conventions.

The best OBJ file documentation I've found is here http://www.martinreddy.net/gfx/3d/OBJ.spec

I've found it's a good starting point but if your app becomes more complex and you start delving into more complex material definitions on your objects then you might want to look into something more standardized like Collada - an XML based format ( https://collada.org ) that covers a lot more but would also be more complex to load into your app.

Also, another good option for generating OBJ files is Blender, a freely available and pretty solid modelling tool ( http://www.blender.org ).

Fraser Graham
  • 4,650
  • 4
  • 22
  • 42
  • 3
    OBJ is the file format of Wavefront's Advanced Visualizer. There is a great spec, that the vast majority of software ignores. It's linked from the wikipedia page, http://local.wasp.uwa.edu.au/~pbourke/dataformats/obj/ – tfinniga Jan 06 '10 at 22:22
  • I had no idea an official spec existed. I once spent a long time looking for it (many years ago). I guess this is one of those situations where a document is only useful if somebody actually reads it :) I don't think I've ever encountered two implementations of OBJ that were exactly the same. – Fraser Graham Jan 06 '10 at 22:35
  • 1
    Yes, the official spec used to be very difficult to find.. I have a bookmark that I've been keeping handy for a while. – tfinniga Jan 07 '10 at 17:34
1

I have written a reader/renderer for AC3D files that works fine on the iPhone (OpenGL ES)

Feel free to have a look at it here.

There is also an obj loader by Jeff Lamarche at google code.

epatel
  • 45,805
  • 17
  • 110
  • 144