Regarding the question of which model format to use; there is no simple answer. There are pros and cons for everything.
This points out some issues in ioquake3 and Maverick Model 3D and some areas that IQM extensions would be beneficial. This is notably missing comparing performance of MDR to MD3 and IQM in the opengl1 renderer and comparing performance of MD3 to IQM in the opengl2 renderer.
MD3
- Pros:
- Fastest model format to render in the opengl1 renderer.
- Attachment points (“MD3 tags”).
- LOD (level-of-detail) support using
_1.md3,_2.md3. - Better vertex precision than MD2 and support for multiple meshes with separate textures. (All the formats have this so I’ll not bring it up again).
- Cons:
- Uses a lot of memory. Especially as polycount and number of frames increase.
- Interpolating between frames may visibly deform as vertexes move linear (in a straight line) between key-frames instead of rotating with bone.
- Separate from the above(?) there seems to be some vertex position wobble (lack of precision) in player death animations.
- Vertex data is unpacked for opengl2 renderer vertex buffer objects, resulting is a lot of CPU memory usage like opengl1 plus an even greater amount of GPU memory usage.
- In the opengl2 renderer vertex tangents (for normal maps) are calculated at load-time (extra time to load, not sure how much) even if normal maps are never used
wait I’m suppose to critic model formats not opengl2.
- Maverick Cons:
- Misfit/Maverick exports hard edge vertex normals for UV seams in all frame animated models(?).
Note: In RTCW there is MDC format which reduces MD3 memory usage (such as bring back MD2-like vertex normal table [different table though] and not saving tag names for every single frame). In Heavy Metal: FAKK2 there is TAN which improves MD3 precision and maximum model bounds.
MDR
Raven’s Star Trek Voyager Elite Force single player has higher poly models with 1,000s of frames. Making MD3 impossible to use with a reasonable memory requirement. So they used id Software’s MD4 format… but fixed it and added compression and called it MD Raven.
- Pros:
- (Unconfirmed) Better interpolating between frames than MD3.
- Smaller file size and memory usage than MD3 and IQM.
- Support for “MD3 tags”.
- LOD (level-of-detail) support built into the format. (Still just separate levels like separate MD3 models though.)
- Cons:
- (Unconfirmed) Probably slower than MD3 in opengl1 renderer.
- (Unconfirmed) Probably has model bone joint deform issues while interpolating between frames (that I fixed for IQM).
- Performance is bad in opengl2 renderer. There isn’t vertex buffer object support and causes vertex normals are repacked each frame (could be fixed). The opengl2 renderer would unpack the data for vertex buffer object in which case it would pretty much converting to IQM at run-time.
- No bone joint names so it would be more difficult to use with dynamic bone rotation. (Neither ioquake3 renderer supports this though.)
- No bone joint bounds for use with dynamic bone rotation. (Neither ioquake3 renderer supports this though.)
- In the opengl2 renderer vertex tangents are calculated at load-time (same as MD3).
- Maverick Cons:
- Not supported by Maverick but is supported by Noesis. I made a (broken) exporter for Misfit years ago and think I finally found issue in 2018 but haven’t got around to working on it again.
IQM
Inter-Quake Model format is designed to replace MD5 (Doom 3) and SMD (Source engine ASCII intermediary format).
- Pros:
- IQM is the best quality with no compromises (Well, animated bones are still slightly compressed).
- Contains the data in a form readily usable for OpenGL 2.0 with GLSL GPU bone skinning.
- Better interpolation between frames (using quaterions) than MD3 and MDR.
- Smaller file size and memory usage than MD3.
- Maverick Pros: IQE uses the vertex normal smoothing/max angle settings where as MD3 does not. (Fixes my turtle player MD3 having a very visible UV seam on leg caused by vertex normals not being smoothed). This would apply to MDR as well if Maverick supported it.
- Cons:
- Slower than MD3 in opengl1 renderer.
- (Unconfirmed) Probably slower than MDR in opengl1 renderer.
- Uses more memory than MDR.
- No real support for “MD3 tags” (attachment points). Instead bones are used which in the opengl2 renderer are naively uploaded to the GPU for bone skinning.
- No bounding box is saved for unanimated models (ioquake3 calculates when the model is loaded instead).
- No LOD support built-in like MDR or support for _1.iqm, _2.iqm in renderer like MD3.
- No bone joint bounds for use with dynamic bone rotation. (Neither ioquake3 renderer supports this though.)
- Maverick Cons:
- Not directly supported by Maverick and must export IQE and convert to IQM separately.
- Quake 3 player model IQE/IQM export hasn’t been made public yet due to being unsatisfied with the code and I haven’t worked on it in ages.
opengl2
For all formats if the Q3 shader falls back to CPU vertex effects (like ones with multiple deformVertexes if I remember correctly) in opengl2 the performance is terrible; much worse than in opengl1 renderer due to unpacking and re-packing vertex normals every frame. (No idea how someone should check if a shader falls back to CPU.)