The (texture) map file name in an MTL might contain spaces. For example, there could be a definition like
map_Kd /images/this name contains spaces.png
With the current version of the MTL reader, the name of this map will be /images/this.
The MTL specification description at http://paulbourke.net/dataformats/mtl/ does not say anything about "spaces in file names". For producers of OBJ/MTL, this should mean
No spaces in file names, period!
Any attempt to accept file names with spaces will lead to unresolvable ambiguities.
An example of such an ambiguity: There could be a definition like
map_Kd -s 2 3 4 where does the file name start.png
According to the section "Options for texture map statements" of the MTL description, the -s option is a scaling factor with up to 3 arguments - namely, the scaling factors u, v, and w, indicating the scaling factors in x, y, and z-direction (for 3D textures... yeah, really...).
The problem is: The v and w arguments are optional. From the line above, it is not clear whether the tokens 3 and 4 are the v/w scaling factors, or part of the file name. So the file name could be
3 4 where does the file name start.png or
4 where does the file name start.png or
where does the file name start.png
This PR tries to address the issue: The MtlReader is reading the "option name" (-s in this case), and then tries to parse expected tokens. Specifically, for the -o, -t, and -s options, it parses and processes the following tokens, as long as they are valid floating point values. (For other options, like -cc on, the option name will always be followed by a single value, so this is not a problem). The remaining part (up to the end of the line) is considered to be the "file name".
This will work for maybe 99.9999% of all MTL files (in fact, I have never seen an MTL file that actually used the -s option). But I'll still leave this PR pending for a while, because I hesitate to do something that may encourage people to create MTLs that use spaces in file names. Most MTL loaders will not be able to process them. The approach of "parsing tokens as long as they appear to be float values" is a pain in the back. And eventually, allowing spaces in file names will always be ambiguous for MTL.
The (texture) map file name in an MTL might contain spaces. For example, there could be a definition like
With the current version of the MTL reader, the name of this map will be
/images/this.The MTL
specificationdescription at http://paulbourke.net/dataformats/mtl/ does not say anything about "spaces in file names". For producers of OBJ/MTL, this should meanNo spaces in file names, period!
Any attempt to accept file names with spaces will lead to unresolvable ambiguities.
An example of such an ambiguity: There could be a definition like
According to the section "Options for texture map statements" of the MTL description, the
-soption is a scaling factor with up to 3 arguments - namely, the scaling factorsu,v, andw, indicating the scaling factors in x, y, and z-direction (for 3D textures... yeah, really...).The problem is: The
vandwarguments are optional. From the line above, it is not clear whether the tokens3and4are thev/wscaling factors, or part of the file name. So the file name could be3 4 where does the file name start.pngor4 where does the file name start.pngorwhere does the file name start.pngThis PR tries to address the issue: The
MtlReaderis reading the "option name" (-sin this case), and then tries to parse expected tokens. Specifically, for the-o,-t, and-soptions, it parses and processes the following tokens, as long as they are valid floating point values. (For other options, like-cc on, the option name will always be followed by a single value, so this is not a problem). The remaining part (up to the end of the line) is considered to be the "file name".This will work for maybe 99.9999% of all MTL files (in fact, I have never seen an MTL file that actually used the
-soption). But I'll still leave this PR pending for a while, because I hesitate to do something that may encourage people to create MTLs that use spaces in file names. Most MTL loaders will not be able to process them. The approach of "parsing tokens as long as they appear to be float values" is a pain in the back. And eventually, allowing spaces in file names will always be ambiguous for MTL.