   Most common formats
  For my game engine, which I have been designing for quite some time, I have come across a stumbling point. I was deciding what model file formats I would use and I found so many; I wish not to exclude anyone from using a certain format. So I was wondering what the top five formats that you have seen that are used in games which you would recommend.   
  I'll assume you're talking about geometry formats.Static:.obj.3ds.ms3dDynamic(animated).md2/3.3ds.ms3dI recommend you just support .3ds. It's very popular, and not entirely a nightmare to parse. GameTutorials has some, tutorials, on it though you'll have to pay for them.Milkshape (ms3d) is also a good format but the modeller kind of sucks and the good tutorial on it no longer exists (rsn.gamedev.net).The ideal solution would be a custom format. That only contains the data you care about, in an easy / optimized format. You could then write exporters for the different modelling suites to store geometry in this common format.   ;  Yes, I meant geometry, my bad.Thank you for the suggestion. For now, I will support .3ds and add support later if I need/want for other formats.   ;  i wouldnt recommend 3ds, its very old.im sure theres a FAQ about the various pro's + cons of various model formats , also a lot of ppl unlike say textures make their own format.   ;  You could always try to support FBX which has just about everything you'd ever need. Also, you could support Collada (make a tool that converts collada files into your own model format).   ;  A custom format, and ship with conversion tools, or some of the more performance-optimized formats [like .md5, which is pretty nice], and ship with exporters to those.  The .3ds's and .x's and many others are so verbose and all-encompassing that they really are terrible for run-time performance.  Pick [or make] a file format that features a better optimized data arrangement for your purposes, and convert everything to that.  Depending on your needs, different file arrangements will be of different value, and different engines will need different information.  Even those clunky many-featured formats like .3ds aren't particularly good in many instances due to omitting data that would be exclusively useful to games [like mass distribution for physics, anchor points, animation scripts, ect].Give careful consideration to making your own, and not natively supporting anything else.  You don't have to please everyone upfront, you just have to provide them with tools to allow you to use their resources [converters].Convert things to your own format outside of the game, where the user has a chance to add the information that your engine will need, but that the file format doesn't feature [a stand alone tool, separate from the user's game].  This will also give you a chance to perform some expensive optimizations on the model that would be obstructively time consuming to do in real time, like triangle reduction, generation of a navigation data, static shadows, and much more.   ;  Ok, I agree with the recent posters now after I did some research (just to make sure it was as Bzroom said. I have decided on  making my own format and the appropriate importers and exporters for the file format.Once again thanks.   ;  I ran into this problem in my game as well. Ultimately, I decided to use COLLADA for the time being. It's slow, and not designed for use in a final end product (Collada is designed as in intermediate format), but Collada is very simple to use and to parse. It's also supported by practically everything.When load times became an issue, I just modified my mesh loader to dump the raw mesh data to disk as a cache. Next time the program started, the mesh loader would use the cached mesh on disk instead of the Collada one, greatly decreasing load times.   