I believe I have encountered a potential bug in Rhino 8 that pertains to the UV Mapping of meshes.
Here’s what I’ve observed: When a mesh is copied from Rhino 5 to Rhino 8, there appears to be a change in the UV Mapping. I’ve attached an image for reference that displays the original mesh and its corresponding UV mapping channel in Rhino 5. In this image, the red curve delineates the UV bounding box, while the green curve indicates the original UV size.
It’s evident that Rhino 8 seems to scale up the bounding box of the UV Mapping channel to the maximum limits of the 1:1 square. I’m unsure if this is an expected behavior or a bug.
Hello,
Thank you for the support. Here is the information:
This is the Rhino 5 file containing the correct mesh and UV (the real dimensions of the UV are noted as 350 x 350 mm): UV-Mapping-Issue-Rhino-5.3dm (1.3 MB)
And this is the Rhino 8 file with the same mesh copied from Rhino 5, you can see that Rhino 8 seems to scale up the UV Mapping channel to the maximum limits of the 1:1 square (green rectangle) instead of keeping the original size (red rectangle): UV-Mapping-Issue-Rhino-8.3dm (1.2 MB)
The texture on the object’s material defines mapping channel 1 to be used. Mapping channel 1 does not have any mapping defined so it defaults to the surface parameter. For some reason that surface parameter mapping is not applied when the object is drawn - outdated vertex texture coordinates are being used instead.
You can see the correct result in Rhino 5 as well by triggering a texture mapping update on the object by for example applying and then deleting any mapping.
I’ve linked your report to an existing bug track item. This is a tricky issue to solve. It’s good to have another model to test with. So far we have not figured out a reliable way to detect this sort of situation when loading a model into Rhino 8.
I’m uncertain if it’s related to the older version, as opening the attached Rhino 5 file with Rhino 7 (tested with version 7.37.24107.15001) shows the UV Mapping correctly. Additionally, pasting the mesh from Rhino 5 into Rhino 7 doesn’t present the issue. However, copying and pasting from Rhino 5 to Rhino 8 results in the problem.
It was created by starting with surfaces, then remeshing, followed by UV Mapping. The mesh is topologically accurate, free of errors, and does not contain any non-manifold edges.
Our workflow is well-established, we carry out these operations daily, and Rhino 7 has never presented this type of issue. The bug in Rhino 8 was noticed as our company is transitioning to the recent version. Hence, this issue is a significant barrier to adopting the latest Rhino releases.
I understand your suspicion. It definitely appears to be a bug in Rhino 8. From users’ perspective it certainly is a regression from older versions.
Mesh geometry in your 3dm file specifies that after the surface parameters have been mapped into texture coordinates they should be scaled into [0,1] x [0,1] domain. That is not what Rhino 5, 6 or 7 are showing when you load the model - until something causes them to re-apply the texture mapping.
When data in a 3dm file is inconsistent Rhino has to decide which way to interpret it: is it the texture mapping defined that is correct or the vertex texture coordinates created by another texture mapping? I need to figure out how to make the right decision.
Only in the sense that both of these bugs were hard to spot earlier due to the same reason: objects were often drawn using texture coordinates that did not match the specified texture mappings.
It’s a little bit more complicated with Rhino. One of the reasons is that NURBS geometry requires another approach and Rhino started as a NURBS modelling tool. Mesh vertex texture coordinates were originally used for storing packed evaluation parameters of the underlying NURBS geometry.
Rhino 4 added the concept of primitive texture mappings (box, spherical, cylindrical, etc.). It seems like at that point it became unclear whether the vertex texture coordinates stored on meshes were actually manually modified or generated by a primitive texture mapping.
That is what I was referring to by “inconsistent”.
It’s tricky to make big improvements while supporting old models, plug-ins, scripts and workflows.
I have a sketch for a bug fix. More test files are very much appreciated. You can share them here if you don’t mind them being publicly available. Or you can upload them privately to me using our upload tool.
I haven’t received any extra test models from you yet. If you prefer to rather test yourself here’s a link to an internal build of Rhino 8.11 which has a preliminary fix for loading old mesh models with uncertain texture data: Download Rhino 8.11.24207.18001
Notice that this build has other preliminary changes as well and it’s not in a release candidate phase yet.
Hey @Jussi_Aaltonen,
I grabbed the new version you shared, and yep, this particular UV is loading just fine now! I will try with other files and let you know.
