Grundsätzlich sollte man die Formate in zwei Kategorien unterteilen. 1. Formate von Modellierungssoftware und 2. Formate für Spiele. Erstere lassen sich meistens besonders leicht landen und verarbeiten, erzeugen jedoch einen riesigen Overhead an Informationen (3ds z.B.). Die zweite Kategorie entgegen enthält nur Informationen über wirklich benötigte Informationen.
Ein schönes Beispiel wie so ein Format aussehen könnte ist z.B. das Milkshape3D Format, dass extrem schlank gehalten ist und vom Aufbau der Datei denkbar simple ist (n int für die Anzahl, n Datensätzefolgen etc.).
Ersteres ist zumeist Einsteigern zu empfehlen, da die Loader dafür fast ohne Probleme out-of-the-box erzeugen und sich der Overhead nicht bei wenigen Objekten bemerkbar macht. Für ein echtes Projekt sollte man zu einer aus Variante 2 greifen (für ms3d hat DGL beispielsweise Source Code oben). Insbesondere wird sich der Fortgeschrittene selbst ein Dateiformat erzeugen, dass die Daten so strukturiert, wie er sie im Programm am besten weiterverarbeiten kann. Hierfür wird er wohl einen Konverter 3ds ==> eigenes Format erzeugen. Wer ein wenig Python kann, sollte direkt zu Blender greifen. Dieser 3D-Modellierer ist zwar gewöhnungsbedürftig, allerdings kostenslos und ermöglicht das direkte schreiben von Plugins für den Export via Python.
Etwas aus der Rolle fallen dabei Textformate (Pov,.x, .obj, .vrml etc.), die ich eigentlich eher zu Kat 1 zähle, da zumeist die Ladezeit schlechter sind als die von binären Formaten. Der Vorteil von diesen während der Entwicklung kann jedoch darinne liegen, dass man schnell mal eben ein wenig das Objekt editieren kann.
_________________
"Menschen sterben nicht wenn man sie zu Grabe trägt, sondern wenn sie ihre Träume verlieren..."