Interpreting LoadObj return value -- strict OBJ specification

[SeanCurtis-TRI]

I've encountered an issue when using LoadObj to parse a file. Specifically, what happens when the wrong file type is provided to the parser. In this case, LoadObj doesn't return an error, it simply leaves the vector of shape_t empty.

The reason for this, based on a coarse once over on the code, is that the parsing takes an XML-like approach. It looks for specific tokens at the beginning of lines (e.g., f, v, vt, etc.) If it finds such a token and the remainder of the line is not consistent with what it expects to see, it returns false. However, if it finds no such token at the beginning of the line, the line is simply ignored. Thus, if I were to pass an STL file into LoadObj, the parsing would report "success", but give me empty geometry.

If we applied a stricter interpretation of the Obj spec, a line that isn't strictly valid OBJ and isn't commented out should produce an error as being malformed for an OBJ file. This would give us a greater power to distinguish the output of LoadObj.

I'm willing to submit a PR in this regard -- but I want to gauge the interest of the set of users in this regard.

[syoyo]

strict parse mode will be nice to have!

the line is simply ignored

.obj is super flexible format and it may be difficult to detect input data is invalid or not.

Currently unknown tokens are parsed as unknown_parameter and user can do whatever they want with it, so we cannot report error in non-strict mode(current implementation of tinyobjloader).

.obj has many commands(tokens)

http://www.martinreddy.net/gfx/3d/OBJ.spec

so writing a robust(strict) parser would require lots of work.

For a while, we could do

• Check if input file is ASCII or Binary and report an error if a file contains Binary data.
• Report a parse error when unsupported command(e.g. bezier surface) was found in .obj in strict mode.

[paulmelnikow]

I'm getting stuck on this issue too.

• Check if input file is ASCII or Binary and report an error if a file contains Binary data.

This makes sense to me. Although I'd also really like to reject files containing JSON or XML as well.

Short of implementing the full spec, two options come to mind:

1. Add generic handling for unsupported commands, which checks that the command is made of letters, and is followed by some other tokens that are valid for OBJ. This would reject non-OBJ-like things, such as XML and most every JSON file.
2. Add a flag that emits warnings on unknown commands.

[syoyo]

@paulmelnikow

Add generic handling for unsupported commands, which checks that the command is made of letters, and is followed by some other tokens that are valid for OBJ

I see. We can scan the head of a file(e.g. first N bytes) then we can reject a file which contains invalid charactes(e.g. { for JSON, < for XML, non-ascii characters for Binary data). This would require less work to implement.

Add a flag that emits warnings on unknown commands.

👍