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.
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.