views:

793

answers:

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?

+2  A: 

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
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.
MarqueIV
MarqueIV
+1  A: 

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
+2  A: 

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
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.
MarqueIV
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
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
+1  A: 

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