I'm not working on a big engine or anything, but it nevertheless is an engine that comes with its own editor. So far I've been ignoring proper asset format support - if needed, static geometry can be imported via obj files, which are simple and effective to handle. The imported meshes are then stored in a proprietary format.

However, I'm looking for the best extensible solution that wouldn't be awkward or foreign to use for people that already have experience with industry standard suites. I need to have support for animated geometry and character animation roughly with the same kind of complexity that obj support is for static meshes and md5 support is for models.

I've been doing some digging and it seems that for instance UDK has settled on fbx being their standard format. Unity as well seems to be going roughly in the same direction.

Now, since I've never really used fbx before for anything myself and since it's a closed format, I'm not sure whether it's the best solution for a small-scale application such as my own. As such, I'd like to get some feedback from people who do have this experience or who can suggest the most convenient/effective workflow from both the artistic side as well as the programming side.

So yeah - suggestions and thoughts are welcome!

Personally I'm building my 'content pipeline' around FBX; most if not all modelers export to it, the SDK is one download no mucking about with external libs, is pretty well documented and pretty much does what you need 'out of the box'.

I'd start with code which imports a simple series of test models first and then expand and refactor as required going forward.

It seems this is a VERY common question/problem. If you would like you can check out my topic if you haven't already: http://www.gamedev.net/topic/621731-3d-model-loading-choices/
Basically either you can use assimp like Reloadead_ suggested, or you can make your own. The latter seems to be the preferred solution. It's faster, easier (to read/write), smaller (file size), more convenient, more professional, and more secure. But the former does have its own advantages.

Xarles; you are convoluting two aspects here.

The OP is talking about having an editor and being able to import existing models in an interchange format into the editor; at a later point these models will be converted into the runtime asset.

This is a good approach as it allows you to work "directly" with the art package output in the editor where assets are likely to change often before doing a 'data build' to reduce the required assets down to 'run time' formats which can be quickly loaded.

Our pipeline at work works along those lines;

Artist work flow is;
[max] -> {output to custom 'interchange' format} -> [world editor]

Game data flow is;
{custom interchange format} -> [pipeline] -> {run time formats/files}

The former can be done in a matter of seconds and allows for quick reloads, the later can take a few minutes (depending on data pipeline work load) but loads quickly 'in game'.

My bad, I misunderstood the OP.

Personally I'm building my 'content pipeline' around FBX; most if not all modelers export to it, the SDK is one download no mucking about with external libs, is pretty well documented and pretty much does what you need 'out of the box'.

I'd start with code which imports a simple series of test models first and then expand and refactor as required going forward.

This is actually precisely the kind of feedback I was looking for. I was simply mildly concerned there might be some caveats regarding fbx (in terms of whatever from licensing to integration). Thank you!