PixarAnimationStudios / OpenSubdiv

An Open-Source subdivision surface library.
graphics.pixar.com/opensubdiv
Other
2.88k stars 558 forks source link

Documentation for OpenSubdiv OBJ crease extensions #1291

Open virtualritz opened 1 year ago

virtualritz commented 1 year ago

I saw that tinyobjloader lib has support for reading (but not interpreting) a seemingly undocumented OBJ extension from Pixar for storing crease chains.

The tinyobjloader repo. has an example OBJ.

It looks to me like there is a new token, t (probably for tag?), than then has the tag type (crease), and then three integers separated by /. The first one seems to be the number of vertices in the crease edge chain, the second the number of crease weights but the third (always 0 in the example) eludes me.

Can someone from Pixar clarify this or post a link describing this extension in sufficient detail for someone writing a parser? I e.g. assume there is probably a corner tag too etc. Thanks heaps in advance!

davidgyu commented 1 year ago

Filed as internal issue #OSD-403

davidgyu commented 1 year ago

The custom tags used in the regression shape files were added to support testing of features in the implementation and are not intended for asset interchange.

For asset interchange of subdivision surface data we encourage the use of something like USD (Universal Scene Description) which is already widely supported by DCC tools, render engines, etc.

There are significant deficiencies in the current encoding of these custom OBJ tags which should be addressed before promoting their use more widely, e.g. the current encoding of component indices is zero-based unlike the one-based encoding used elsewhere in OBJ, many of the enumerated values are represented as integers where a string token would be more robust and easier to read, etc.

Support for the custom OBJ tags and the best current source of documentation is the code in regression/common/shape_utils and regression/common/far_utils along with the example usage in the data files in regression/common/shapes.

We agree that it would indeed be helpful for these custom tokens to be described more fully in the documentation!