-
Notifications
You must be signed in to change notification settings - Fork 594
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interpreting LoadObj return value -- strict OBJ specification #272
Comments
.obj is super flexible format and it may be difficult to detect input data is invalid or not. Currently unknown tokens are parsed as .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
|
I'm getting stuck on this issue too.
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:
|
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.
👍 |
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 ofshape_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 intoLoadObj
, 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.
The text was updated successfully, but these errors were encountered: