Getting basic 3D models into an OpenGL app

问题

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?

回答1:

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.

回答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.

回答3:

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