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.
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.
Solution
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"
enter
enter
Delete
_Import "E:\Your_Custom_Folder_Path\testfbx.fbx"
enter
enter
_UVEditor
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.
Attention
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.
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:
make the surface sphere
perform a custom unpacking and apply modifications
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.
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).
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.
Solution
A special thank to Tim Hemmelman and Jakub Czajczynski that help to develop this solution.
To double-check your UV mapping in Rhino, make a new custom button that export and import the object mesh as FBX. Be careful to not import the cameras.
Make a new custom button using these commands and notes here below
! -Export _geometryonly=_yes "E:\Your_Custom_Folder_Path\testUV.fbx"
enter
enter
Delete
_Import "E:\Your_Custom_Folder_Path\testUV.fbx"
enter
enter
_UVEditor
Notes
Make a folder “Custom_Folder” and copy the path.
In Windows, do not use the C: drive. Use other D:, E: or external drive.
replace “E:\Your_Custom_Folder_Path\testUV.fbx” with your path.
To avoid exporting and importing new cameras into your project, in the export FBX options select Save Geometry only enable.
How it works
It exports the object as an FBX file and reimports it. It will delete your original object. So after running the command, you can undo to be sure to recover your original file or make a copy.
After you created this new button command, before you run it, be shore to close the UVEditor. Select the mesh object and press this custom button. Then press enter and place the UV editor rectangular mapping plane as usual. So remember to close the UV editor before running this command.
Attention
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.
The _geometryonly=_yes prevent you from importing multiple cameras. If you are importing a lot of cameras you can delete them by running the command: NamedView, select them all and delete them.
This Major bug was reported in 2019 we are in 2021…
Any news?
I know is in progress but I wish the occasion to point out to Bob @bobmcneel that:
I wish to Jussi many more resources. Perhaps a couple of clones of himself?
Or much better upgrade him to PM and put a large team under his direction/division.
Prolific awesome developers like Jussi Aaltonen try to do it all by themself but they really need a large team that works hard trying to follow him attached to his b… So that his expertise and creativity are not slow down or stopped by fixing stupid bugs RH-57899 that are slow to solve. Sometimes fixing multiple smaller bugs does not let you too much time to fix the more important full picture that in this case is RH-54126.
