- allows filepath with spaces for textures
- allows names with space for internal names in obj (group, material)
- It fixes incorrect matching (material name matching on first part of a name like "my material" merges all material with same start)
Problem: on a 22gb file, it fails on "out of bound write"
Fix: using size_t on 64bits for arithmetic ptr alloc/index system fixes it
Usage: user can define FAST_OBJ_UINT_TYPE as size_t on x64
When moving the unprocessed line to the beginning of the buffer, in rare
edge cases where the unprocessed chunk is larger than the processed
chunks (which means the lines are very long), the source & target range
will overlap. This is undefined as per C standard and triggers ubsan
errors.
Fix this by using memmove.
When string_equal's first argument is a prefix of the second argument
but the second argument is longer, the loop goes through all characters
of the first string, compares terminating NUL with a different character
in the right hand side string, discovers that it's different and leaves
the loop - with 'a' having already been incremented.
After this the condition proceeds to read from *a which causes a buffer
overrun.
Fix this by changing the function to something that's obviously correct,
even if somewhat less efficient.
Instead of each group storing a separate face/index array, we now store
one large face/index array and each group stores offsets inside it.
This makes it easier to parse .obj files when group information is
unimportant since one can just skip it - group information is often
inessential as it doesn't affect rendering behavior.
This makes parsing large files slightly faster (rungholt.obj parses in
~500ms instead of ~530ms after this change).
For use-cases that require parsing the .obj file and outputting another
file, resolving texture paths is inconvenient since the result depends
on the path that's passed to obj_fast_read. While this can be resolved
by recomputing the relative path in user code, it seems cleaner to keep
the map names as is when parsing .mtl.
Of course, if .obj file is required for rendering, the path
concatenation is still convenient. This change makes
fastObjTexture::name contain the original data, and fastObjTexture::path
contains the resolved path that can be used to actually load the texture
if necessary.
Negative indices refer to offsets of vertices (before multiplying by
stride), but array size of position/etc. is multiplied by stride.
Integer division isn't ideal for performance, however division by 3 is
lowered into integer multiplication on gcc/clang/msvc so this shouldn't
be a big concern.
In some .obj files, there's a stray 'g' followed by a newline at the
very end of the file. What happens right now is that *p++ skips past the
"terminating newline", and then proceeds to process out of bounds memory
which leads to a crash.
I'm not sure if 'g' can actually be empty per spec, so this change just
fixes the crash without resetting the group to "default" or anything
like that; 'v'/'f' shouldn't be empty but this would fix crashing when
parsing malicious/malformed .obj files as well.
