i’ve got an *.obj file with a png texture assigned through an mtl file. The obj file contains this information in the header:
# Rhino
mtllib Budda_tx.mtl
o object_1
usemtl Material_1
If i import this obj file into Rhino 8 WIP (8.0.22328.8305, 2022-11-24), using the default settings, it creates a new material of type Custom and instead of assigning the png texture to the color slot of the material, it assigns the “mtllib Budda_tx.mtl” file to that slot. Once i’ve deleted the imported mesh geometry, and tried to import it again, Rhino crashed and i got the following information on my desktop:
You can zip up the OBJ, MTL and PNG file into one archive and upload at Rhino - Upload to Support along with the URL to this discussion in the comments box.
Hi @nathanletwory, that’s strange. I do get repeatable crashes here on simple things like opening a complex file, make some changes, then choose new document, cancel to save and choose the Millimeter template. But i get no crash log, Rhino just shows the hourglass and closes…
Your crash was in a UI control and there’s been a lot of churn in that lately. It could be that by the time Nathan tested that crash was fixed. I’ll look at your import bug before other stuff but I took next week off so it may be a little ways out.
I guess I need specifics because it seems to work for me. Watch this video and tell me what I’m doing differently than you are. This is open but I also tried import.
Hi @tim, my E: drive is a local drive. If i copy the folder with the obj, mtl and png file to my desktop and Import from there, the texture is loaded properly.
Yes, it has a space in, there is one parent folder named “Rhino Data” in that path. But why would this error cause that the mtl is applied instead of the png ?`
I don’t know yet. The location on the desktop is a path without spaces? Here would be a thing to double-check for Tim. It is just a hunch, and could totally be off.
Thanks for the help guys. A path with a space in it on my desktop still worked. A path on my d: drive, space or no space failed. This is on my Windows box.
On my Mac box it failed on the desktop too.
I’m sure this has something to do with parsing paths on the 2 different OSs. I’ll get it fixed.
OK. It’s the ‘~’ in the filename in the mtl file that is causing all of the trouble. @clement, when you saved this from Rhino originally would the full path have had any non-ascii characters in it? I can’t understand why we would still be doing the dos 8.3 (short file name) ~ stuff if the filename itself is all ascii, even if it isn’t 8.3.
It looks like the code we use for finding files, only works sometimes if it’s a short file name. If you change the filename in the mtl file to be “DT_Bitmap.png” instead of “DT_BIT~1.PNG” it should work everywhere because the code will actually find the file.
Incidentally, the reason it was filling in the .mtl file was because I use the same code to fix paths for .mtl and textures files. It tries a number of string gyrations and the last thing it tried found a match for the .mtl file. I will fix that, it should have probably just left it blank.
I’m not sure how I should go about fixing this as a whole. Whether I should dig into the file finding code (none of it’s mine) or just write the .mtl files differently. The OBJ spec is really old school, 8.3 ascii only if I remember right. Filename only, expecting all necessary files will be in the same folder.
Hi @tim, no it’s a very simple path and file name contains an underscore.
Same here. Imho if a user exports obj + mtl using Rhino, it should be capable of importing it out of the box.
Imho i would break the spec, we are in the year 2022. If the referenced file in the mtl cannot be found in the same folder the importer should ask for it, suggesting the filename and extension.
One more question. I was looking at the OBJ export code and all of the short path stuff was never implemented in the port to dotnet (OBJ i/o is all dotnet not, since V6 I think, maybe early V7). There’s a big TODO in there to figure out if it’s even necessary. I think we’ve established that it isn’t. So, where did that stuff come from in your example file? Did you export from an older version of Rhino? Was the texture named “DT_BIT~1.PNG” in the 3dm file that you exported from?
For now, I’m not going to add UI to ask for missing textures. A whole lot of effort for a problem that does not occur that often. If more users actually run into the problem I’ll reconsider.