I've been throwing together a simple iPhone game, and am at the point where I would like to display some 3D models for my characters.

Unfortunately my Google-fu is weak and I have been unable to find a simple format that meets my needs. They all either don't support skeletal animation, or are drastic overkill for my project (Shaders? We don't need no stinkin' shaders! Or tangents, or physics data, or much of anything really).

At the moment all I need are:
Vertex/Index data (duh)
Vertex Normal data
Texture coords
Skeletal animation (ideally multiple animations, and they don't need to be blendable either)
Easy to load
Relatively compact (i.e. not ASCII)

I've considered writing my own format, but then I'd have to write an exporter/converter for that format and that would be a project in and of itself.

I've also considered the MD2/MD3 formats, but having a duplicate of the entire mesh for each keyframe kind of dissuaded me from that (unless someone convinces me it is still okay for an iPhone game). If anyone has a suggestion I would love to hear it. At the moment this is basically the only thing keeping me from continuing my game.

One option is John Ratcliff's MeshImport library and its XML-based EZ-Mesh file format. It's human-readable ASCII, but you could convert it to an equivaent binary format for compactness.

3DS is a simple binary format, but none of the tools I use can export it with the features I need (IDK if it even supports some of them). I guess I will probably end up creating my own 3D format and Blender plugin. I just wanted to avoid reinventing the wheel.

If you really want to make a custom format, I would suggest doing that. Writing a converter might not be so bad;
You can make a preprocessing tool using Assimp. Assimp pretty much imports any format you want, and then you can access the data directly. In general, I've had few problems. I know it supports animations, but I haven't used this part of it myself. In my projects I usually just spit out the data Assimp provides me in an easy to parse binary format that allows me to just really quickly load data to the GPU using glMapBuffer().

A link: http://assimp.sourceforge.net/

I've been throwing together a simple iPhone game, and am at the point where I would like to display some 3D models for my characters.

Unfortunately my Google-fu is weak and I have been unable to find a simple format that meets my needs. They all either don't support skeletal animation, or are drastic overkill for my project (Shaders? We don't need no stinkin' shaders! Or tangents, or physics data, or much of anything really).

At the moment all I need are:
Vertex/Index data (duh)
Vertex Normal data
Texture coords
Skeletal animation (ideally multiple animations, and they don't need to be blendable either)
Easy to load
Relatively compact (i.e. not ASCII)

I've considered writing my own format, but then I'd have to write an exporter/converter for that format and that would be a project in and of itself.

I've also considered the MD2/MD3 formats, but having a duplicate of the entire mesh for each keyframe kind of dissuaded me from that (unless someone convinces me it is still okay for an iPhone game). If anyone has a suggestion I would love to hear it. At the moment this is basically the only thing keeping me from continuing my game.

MD2 has worked fine for me on the iPhone but it doesn't support skeletal animation. You should look into PowerVR's POD format. The code to render a POD is already in the PowerVR SDK. You will also find a plugin for exporting POD format from 3DS and a tool for converting from collada to POD. POD supports skeletal animation and is optimized for the iPhone hardware.

I just wanted to avoid reinventing the wheel.

This is one area where 'reinventing the wheel' is very common thing to do, even in the professional world.

Your final data format is going to match your data layout in memory; effectively it's nothing more than a raw dump of your vertex/index buffers with some meta data to indicate what it contains and any materials required.

While you can reuse an existing format as suggested here the simplest format is the one you can just load directly in with no messing about with parsing at runtime.

Relatively compact (i.e. not ASCII)[/quote]
ASCII is compact!

prolly about the same size than binary (maybe slightly larger) uncompressed.
But when compressed its usually smaller than binary

So dont let file size stand in your way for not choosing ascii

[quote name='Firestryke31' timestamp='1298178936' post='4776571']
I just wanted to avoid reinventing the wheel.

This is one area where 'reinventing the wheel' is very common thing to do, even in the professional world.

Your final data format is going to match your data layout in memory; effectively it's nothing more than a raw dump of your vertex/index buffers with some meta data to indicate what it contains and any materials required.

While you can reuse an existing format as suggested here the simplest format is the one you can just load directly in with no messing about with parsing at runtime.
[/quote]

Indeed.

As you most likely already know, the base of nearly every game game 3D file format is Wavefront .OBJ. All the file formats I have seen are nothing more than permutations of it. The only divergence is whether they combine the animation data in the same file, or do it stand-alone.

There is really not that much structure in the file format that making your own would take up a lot of time. Not a whole of wheel to reinvent, so to speak. Just follow the basics of binary file format rules and you can do it in one sitting.

If you can stand ASCII, the Blitz3D file format seems to fit all of your other requirements and is widely implemented in loader libraries. (You could write the loader yourself in one sitting.)