Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Out of every format I know, the only one that works accross all applications perfectly is OBJ. I think it is an excellent format and I would use it for everything - except it does not support skinning.

I am wondering, why the spec has never been extended to include support for skinning. It wouldn't require overhauling the format - just add a 'vertex weight' and 'vertex bone id' parameter, and a list of bones and transforms at the end (or perhaps store all skinning data in a seperate file in the same way as material parameters are)

Its frustrating battling with all the other formats, while OBJ is just sitting there lacking this one thing.

Could someone with more industry experience theorise as to why this extension has never been added?

share|improve this question
The main reason why OBJ "works across all applications perfectly" is that it's a dead-simple format that doesn't include things like skeletons, material definitions, lights etc. that are likely to break compatibility between apps. – Nathan Reed Oct 21 '11 at 23:28
up vote 4 down vote accepted

Lack of time and expected reward.

There's a lot more to skinning than just adding vertex / bone weights to a geometry format, there's not much point in having that unless you also have the skeleton definition. And that's a lot more work, even for a basic implementation. Not to mention, none of the tools which export to OBJ format will support it. Why bother, when you already have other animation formats already defined, formats which are much better suited to storing animation data?

There's nothing stopping you or anyone else from extending the format yourself, both on the export and import sides. But an organised extension to the spec would be work for whomever took it on. Better to treat OBJ as what it is: a static geometry format.

share|improve this answer
It might also be good to remember that OBJ is not a very good format for certain things. It supports indices per stream, where most graphics API:s indexes all steams by the same index. This can complicate reading code a lot, especially if you want to us as little memory as possibe. – void Jun 14 '11 at 12:07
I thought that an enormous share (even if just amongst hobbyists/modders/less tightly controlled pipelines) would be the reward but I see why a company wouldn't extend the effort with no guarantee that current applications would embrace it. While there are better formats, all of them seem to have drawbacks that OBJ does not (COLLADA is complex with all sorts of references jumping around inside it, FBX requires an SDK, etc). Though void makes a good point that makes me think this is one of those 80/20 scenarios - for 80% of everyone else, skinning isn't the deciding factor. – sebf Jun 15 '11 at 11:41

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.