[BUG?] Mesh UV mapping does not update properly not exporting correctly?

As you can see I “GoNuts4” using Rhino. But I gave UV map exporting problems.

  • I make a simple polysurface.
  • Unwrap it using Unwrap
  • Convert it to mesh

As you can see looks perfect

but is not the case exporting

The uv-mapping looks like is not updating properly the uv mesh after the mesh conversion and for that reason when loading or saving a Rhino file is not recalculating the uv map.

Enclosed you will find the file example: Debug-UVunwrap.3dm (93.2 KB)

Rhino6 and Rhino7 WIP: If you try to export the content as OBJ or FBX and reimport, the UV map is not correct.

I remember having this problem before. I was fixing it not making a surface that can generate tringles that merge in the centre (in a tube or a sphere I create holes in the poles). Anyway
Doing some research looks like is a known Rhino5 bug reported in 2016 using Rhino6 hope for a fix in Rhino7…

I hope for a fix as soon as possible or I’m making something wrong?
Do I need to report it as a bug? if that is the case, I suggest to developers (as a partial solution) to recalculate the UV map from the mesh when unwrap is press and check if match the stored UV data.
If that does not work, as a dirty fix when unwrap is press you can export and reimport the mesh using FBX or OBJ. In this way will pop out the broken UV expose them to the users. So that the user is conscious of the problem much sooner. I mean as a partial solution until a real fix is done.

Possible solution for the Rhino6 user:

before we create our custom UV mapping we need to set up custom Render Mesh Quality in the Preferences and after that, we need to create or export mesh with the SAME SETTINGS as the Render Mesh Quality settings in the preferences. After that, no UV problem will appear. Mesh displayed in the UV map should be identical with the export mesh.

Related forum
solution: Mesh UV export problem
2019: UV mapping issues, export model from Rhino5 to 3D Max
2018: UV map problem after export
2017: UV map distortion when exporting OBJ (or converting to mesh)

Related bugs



I support you in a fight for the proper UVs.
I am happy to see that some Rhino users have interest in Substance and texturing - beautiful work!

1 Like

How to inspect the final FBX or OBJ UV mapping?

Make a new custom button that export and save the object mesh as FBX, and reimport it.

make a folder and copy the path.
make a new custom button using these commands here below
replace “E:\Your_Custom_Folder_Path\testfbx.fbx”

! -Export "E:\Your_Custom_Folder_Path\testfbx.fbx"


_Import "E:\Your_Custom_Folder_Path\testfbx.fbx"


After you created this new button command, select the mesh object and press this custom button. Then press enter and place the UV editor rectangular mapping plane as usual.
Remember to close the UV editor before running this command.

This new button will update (or destroy) your original UV mapping mesh. Will delete your object mesh and replace it with a new one imported from FBX. So you will lose your original UV mapping. If your intention is rendering inside Rhino, you need to preserve your original UV mapping. So consider making a copy of your original mesh object or hitting undo, undo after using this button.

I has made a bug report: https://mcneel.myjetbrains.com/youtrack/issue/RH-54126

Video Part 1 Description: https://youtu.be/eFBlg_hBbNI
Video Part 2 Expected Result: https://youtu.be/S2JmCHcwwS4

If you wish fixing please vote.

Hello - here is what I get, in our latest-

from the sphere as a surface:
i.e. the render mesh is used

and from the meshed sphere:

Is that what you expect to see or am I missing the point?


Yes, but with custom unwrap apply to the surface.

Did you take a look to Video Part 2 ?
Expected Result : https://youtu.be/S2JmCHcwwS4

The explanation is long. If you wish I can make a Skype call.

To summarize yes. But it is not the complete answer since in your second screenshot (with high density), the mesh (top left) is not the exact same mesh when you close it. And it is not the mesh in the FBX / OBJ. I hope the FBX does not perform a conversion to the mesh. And other things that are a trigger because _Mesh is not unwrapping the surface when runs.

Now follow these steps:

  1. make the surface sphere
  2. perform a custom unpacking and apply modifications
  3. convert it to mesh
  4. ask me the previous question

I think you are close to the point: We are using the surface projection instead of the mesh itself.
The real UV mapping projection is there in render view but never shown to the user.

Hello - please see my comments on the bug track item - does that correctly describe what you see?


1 Like

Your steps are perfect.
Since I feel like your last sentence was not correct, I added 3 more steps and a video. I think it(*) is part and trigger by the same issue( so can fit in this bug report). Please take a look.

(*): vertex normals change and that let me think that is not the exact same mesh. Also, FBX exporter is giving a different UVmapping making it’s own unwrap.

The point is that the final UV mapping projection is never shown by the UV editor (is hiding).

PS: This is an intuition but if this bug is fix probably rhino will run faster (by using the actual polymesh and not the additional distorted copy).

Thinking in a solution to this bug:
I was reading Jussi answer: “FBX export applies the texture mapping


It can be more useful if in the UVEditor, is displaying the final applied texture mapping as the FBX does instead of displaying the MappingMeshEditor. It can be a toggle in an experimental UVEditor that shows the applied texture mapping. This toggle option will expose mesh issued to the user and debug faster hidden mesh problems.

Other more radical solution in parallel can be purchased: https://www.rizom-lab.com/rizomuv_sdk/