No, it’s a good old version of Unfold3D. The developer changed the company and it’s called RizomUV RS now.
I’ve done more testing - same results - attached the files for someone else to test
UVMap_Test.3dm (2.7 MB)
test.fbx (2.1 MB)
Micha - There is a little progress to report on the issue. SR1 seems to fix some of the UV maps but not all.
See - My topic report.
1 Like
Hello @Micha
I’m looking into this issue right now.
Rhino is getting confused because that object material appears to have a texture that has repeat set to zero. Although that texture seems to be on a disabled channel it still goes and takes those repeat values and so all the texture coordinates get set to zeros.
Is that a Vray material? Can you verify that there is zero repeat on at least one disabled material channel?
Hi @Jussi_Aaltonen,
I checked the file but can’t find a disabled material channel. Could you post a screenshot please?
-Micha
Ok, sounds like there might be a bug somewhere else as well. I can’t post a screen shot because I’m only looking at the data created from the /.Polster.2KL material - that is not a native Rhino material so there’s a conversion on that 3rd party plug-in.
Anyway it looks like the 2 disabled channels (bump and transparency) should be completely ignored on the export.
Yes, it are V-Ray materials. @Nikolay Could you check please that there are no zero repeats are set?
Thanks for reporting. There appears to be a bug with the cylindrical mapping as well.
RH-78677 Texture Mapping: cylindrical mapping applied wrong on cylinder
looking at the .rmtl, for the diffuse texture it says repeat = {1,1,0}
there are neither bump nor transparency textures set, so no way V-Ray can set zero repeats to those.
Mind that latest available V-Ray was build against Rhino 8 BETA SDK, not against the official release’ and some things may not work properly
Thanks @Nikolay
I’ll try to figure out where those values come then.
I bet on CRhRdkTexture default ctor
@Jussi_Aaltonen My client is asking me for results and I tested one of the latest Rhino 8 builds, but still are my UV lost.
As a workaround I created a fresh Rhino material but there is the same problem. Here an example. How can I fix the situation and send OBJ with working UV?
Looks like the texture coordinates are exported correctly but the texture is missing this time 
@Micha
This bug has already been fixed in SR3 release candidate. So one option for you is to install one from here.
In SR2 the map_Kd row is missing from the mtl file. And the bitmap is not copied to the obj export folder.
Although this is an export bug it could have something to do with RH-71573. Perhaps @tim could confirm.
RH-71573 had to do with the strings for usemtl in the obj file and newmtl and map_xx in the mtl file. The obj exporter, these days, saves filenames as is into the obj file but in the past converted them into a short 8.3 filename. That caused problems on Mac. The latest fix in RH-71573 is code that attempts to find the full filepath from an 8.3 filname on the Mac.
I installed Version 8 SR3 (8.3.23360.13001, 2023-12-26) today and still the UV coordinates get lost. Please try to fix it soon, my client want to get mesh files with correct UV.
Does that happen on any model you export?
I run the same Rhino version as you: 8 SR3 (8.3.23360.13001, 2023-12-26)
Then I open the UV destroyed by OBJ export (Rhino material).3dm from your .rar package.
Then I do “Save As…” with OBJ as the file type using the default settings
Then accept these default OBJ export settings
And then I get these files (OBJ, MTL and PNG): TestObjExport_SR32336013001.zip (6.1 MB)
Hi @Jussi_Aaltonen,
thank you for the details. I used a button script for export/import of the mesh as OBJ and I noticed a stupid error by me that the texture coordinates were not activated. Oops, embarrassing. I works perfect now.
Thank you for your patience. 
2 Likes