Skip to content
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

bad OBJ file that can still be read #2435

Merged
merged 3 commits into from
May 5, 2019
Merged

Conversation

ov
Copy link
Contributor

@ov ov commented Apr 26, 2019

I've got a bad OBJ file that has the following structure:

# vertices
v ...
v ...
v ... 

# normals
vn ...
vn ...
vn ...

# faces
f 1/1 2/2 3/3
f 4/4 5/5 6/6

The file obviously misses texture coordinates, but the "face" lines seem addressing normals instead. The parser fails on this by skipping the first digit after the slash, which leads to various harmful consequences...

It is discussable if the second number of each pair should be ignored or treated as a normal index instead of UV index, but the parser may (and so should) read the file at least partially.

This pull request sorts it out by checking if the currently read number should be a UV index, but the mesh has only normals and uses the number as the normal index instead. It passes all the tests and I added another one representing the file I have. Unfortunately I can't provide the file itself because of its size and unknown copyright status.

@kimkulling kimkulling merged commit e1fce78 into assimp:master May 5, 2019
@kimkulling
Copy link
Member

Merged, thanks a lot for the contribution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants