7
\$\begingroup\$

I'm beginning to write an iPhone game using OpenGL-ES and I've come across a problem with deciding what format my 3D models should be in. I've read (link escapes me at the moment) that some developers prefer the models compiled in Objective-C .h files. Still, others prefer having .obj as these are more portable (i.e., for deployment on non-iPhone platforms).

Various 3D game engines seem to support many(?) formats, but I'm not going to use any of these engines as I would like to actually learn OpenGL-ES. Am I putting myself at a disadvantage here by not using a packaged engine?

Thanks!

\$\endgroup\$

4 Answers 4

3
\$\begingroup\$

Every engine that you learn will actually teach you OpenGL ES better, as long as you see what is happening under the hood. You can roll your own engine, but be ready to rewrite it many, many times. It'd better to learn an existing one, and then decide wether you want to write from scratch.

That said, personally I think that storing models in .h is a very crude and ugly way of doing it. It will work only if you have just a few models. Do not even start to think about in a case of a game that will need resource handling (ergo have more than a basic amount of models/textures).

\$\endgroup\$
1
\$\begingroup\$

No. It all depends what you want to learn.

If you want to learn game programming as a whole but more aimed towards logic, then use a game engine.

If you want to learn OpenGL-ES, which is what you say, then it makes a great deal more sense not to use a game engine. That way you can see what works, and what doesn't. With a game engine, you would maybe do something like 'AddModel("address"); RenderAll(); ' or whatever. This doesn't do a great deal of teaching OpenGL.

And for the model format, I think it makes sense to keep them as an .obj file. You can edit them with a modelling program, and you learn how to load models universally, rather than just on iPhone.

\$\endgroup\$
1
\$\begingroup\$

Using .h files for your model is really only useful for something really quick and dirty. Every time you change anything about your model you need a rebuild. I could see it done for something that is crucial (say if you have a 3d loading image that has to be there even if loading fails) but apart from that it's even too oldskool for my liking (and I'm a dinosaur in most departments).
While I would hardcode a cube while getting to grips with an environment, I'd swap to loading models as soon as I got my prime renderer up and running as it's only a fraction harder to read the models and then index the data than it would be too reference hardcoded models.
Loading them also sets you up a lot better for reusing the engine because if you hardcode your models the rest of your code will probably end up following the same hardcoded philosophy and will be quite unreusable.

\$\endgroup\$
0
\$\begingroup\$

OBJ models are not an ideal format for OpenGL, since they use separate indexes for positions, normals and texture coords. Using OBJ with OpenGL means you have to preprocess the data when loading it to create either new vertices and indices, or use non-indexed arrays to render.

A similarly simple to parse but more efficient format is IQM and its text-based companion format IQE. IQM also supports basic skeletal animation and vertex colors.

http://lee.fov120.com/iqm/

\$\endgroup\$

You must log in to answer this question.

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