3
\$\begingroup\$

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?

\$\endgroup\$
1
  • 2
    \$\begingroup\$ 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. \$\endgroup\$
    – Nathan Reed
    Commented Oct 21, 2011 at 23:28

1 Answer 1

Reset to default
4
\$\begingroup\$

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.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ 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. \$\endgroup\$
    – void
    Commented Jun 14, 2011 at 12:07
  • \$\begingroup\$ 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. \$\endgroup\$
    – sebf
    Commented Jun 15, 2011 at 11:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .