Rhino BETA Feature: UV Editing Improvements

[Jussi_Aaltonen]

Hi all,

There are already some improvements to UV unwrapping and editing in Rhino BETA and more is coming. I’m concentrating on fixing issues with workflows and reliability.

UV Unwrapping

As-rigid-as-possible method in the Unwrap command has been replaced for better results.
Symmetric parts unwrap symmetrically for both LSCM and ARAP. Parts with similar shape are oriented consistently.
Reliability of unwrapping has also improved. It is less likely to find parts that won’t get valid UV islands.

UV Editing

Adding and removing UV constraints is more flexible. It is possible to add edges to existing edge straightening constraints and combine two or more of them into one. In addition to removing all constraints it is also possible to remove individual constraints.

Please, try out Rhino BETA and let me know what you think. What would simplify your UV workflow?

[martinsiegrist]

I see constraints

[Jussi_Aaltonen]

And, as you may have noticed, the UV Editor has constraints also in Rhino 8.

[Charles]

Hi Jussi

These are good news!

Especially for the constraints, it would be useful to see the selection in the viewport.

UV Editor and sub-selection

It would be good if a sub-selection of an island would show in the viewport: [image] I was quite surprised that it’s not the case. @Jussi_Aaltonen

[kiteboardshaper]

@Jussi_Aaltonen

I hope this issue/workflow falls within the scope of what you’re currently working on.

I have a workflow where I need to apply a graphic texture to a 3D model, and then unroll that model into flat panels for printing and cutting.

The problem is shown in the image above: the graphics/textures on the unrolled parts do not match the original 3D model.

Here’s the process I’m currently using:

• Apply the texture to the 3D model using surface mapping
• Bake the texture to a .bmp file
• Unroll the parts using UnrollSrf with Keep Properties = Yes

The problem is graphics on the unrolled panels are a mix of:

• Flipped
• Rotated
• Slightly off-scale and/or location

As a result, I end up spending several hours per file manually resizing and rearranging the UV mapping to get the unrolled panels to visually match the 3D model.

What’s particularly frustrating is that the result is almost correct — it’s close enough to feel like there’s just a small bug or mismatch in the pipeline, which leads to a lot of unnecessary cleanup work.

I tested this again with Rhino 9 this morning, and the problem still persists.

One more request: could the Bake functionality be added to RhinoCommon? That way I could script this process and avoid some of the manual steps.

Thanks,

DK

[Jussi_Aaltonen]

@kiteboardshaper

I have a workflow where I need to apply a graphic texture to a 3D model, and then unroll that model into flat panels for printing and cutting.

Does the UV pattern match the baked texture after running the Bake command?
Is it necessary to work on polysurface/surface objects? Could you use meshes for this?

[Jussi_Aaltonen]

@Charles

Especially for the constraints, it would be useful to see the selection in the viewport.

Yep, that’s one the features I would like to add. But it’s a bit tricky to do.

[kiteboardshaper]

Hi @Jussi_Aaltonen

In my experience, unless the texture is baked properly, there’s no reliable connection between the flattened geometry and the original UV mapping:

These panels are intended for laser cutting and will be assembled to sub-millimetre tolerances (over meters of seam length) - so while meshes are fine for artistic workflows, they don’t meet the precision requirements for engineering at this level.

Cheers

DK

[kiteboardshaper]

Hi @Jussi_Aaltonen

Just for good measure, I:

• Exploded the panels
• Bake the texture from a single panel
• unrolled that panel

This is even less of a desirable result with the UV mapping showing the panel reference massively out of scale to the texture:

Cheers

DK

[UAS-Design]

smart UV unwrap layout

It would be amazing if Rhino 9 could make an smart suggestion for an continuous unwrap layout and also automatically adjust the size of the UV grid, so that you would only have to manually edit the seams when necessary.

Below is a rough proposal for the unwrap of a rounded cube.

[Steve_Howden]

Hi DK,

It’s a long time since I dfid this so my memory is a bit hazy.

However I seem to remember the process as follows:

• Model sail and split into Deg1 developable panels, making sure all panels will join back into a single polysrf with no naked edges.
• Planar map image onto polysrf
• Bake textures
• explode and unroll with texture coords (script attached)

This all went well and the sail was actually pretty fast too.

Hope that helps. Sorry I can’t remember the process in more detail, but at least you now know it is possible

Regards, Steve

UnrollWithTextCoords.rvb (3.5 KB)

[UAS-Design]

the Rhino help shows the following behavior for the command ExtractUVMesh:

Texture mapping | Rhino 3-D modeling

But that’s actually how it looks for me. Am I doing something wrong? Is there a checkbox to activate a continuous unfolding?

[Jussi_Aaltonen]

Usually the only type of texture mapping on mesh objects that survives flattening is the surface mapping. Baked objects use surface mapping.

[Jussi_Aaltonen]

@UAS-Design

It would be amazing if Rhino 9 could make an smart suggestion for an continuous unwrap layout and also automatically adjust the size of the UV grid, so that you would only have to manually edit the seams when necessary.

Unwrapping with automatic seams has been requested before too. Linked this request there as well.

What do you mean by ‘adjusting the size of the UV grid’?

[Jussi_Aaltonen]

@UAS-Design

But that’s actually how it looks for me. Am I doing something wrong? Is there a checkbox to activate a continuous unfolding?

The ExtractUVMesh command just adds a flat mesh object that represents the object in the UV (texture mapping UV, not NURBS surface UV) space.

[AlanMattano (Soaring Stars lab)]

@Jussi_Aaltonen

Please, try out Rhino WIP and let me know what you think. What would simplify your UV workflow?

Thank you, Jussi, for the excellent work. Rhino has improved significantly on the rendering side, and proper UV mapping was one of the missing pieces. Thanks to these recent improvements, it is now truly possible to work effectively with UVs.

A few quick questions: What does baking do exactly? What is its purpose? When and how should it be used correctly?

Some feedback:

• I would prefer the Rendering tab to match the Properties: Texture Mapping panel more closely. In the Rendering tab, some buttons are missing and the existing ones are not in the same order as the icons in the Properties panel.
  
  Conversely, the Properties: Texture Mapping panel is also missing some buttons that appear in the Rendering tab.
  

  

• It is quite difficult to understand the current state of UV mapping in Rhino because the UV mapping inspector does not always display or update all relevant parameters.

  

One possible solution would be to add a second UV Editor window (post process) called “Final Mapping” (or similar), which would show the actual real UV mesh that will be exported. Alternatively, the existing UV Editor could be updated to display the final, export-ready UV mapping.

• Perhaps (this may be an ambitious request) Rhino could benefit from a true surface-based 2D UV Editor (with control points/CVs) alongside a 2D UV Mesh editor. This would align better with Rhino’s traditional modeling philosophy — treating UVs as editable surfaces projected into 2D space.
• Finally, it is not clear to me how to properly export a joined UV mapping mesh (UV island). At the moment, the export appears to separate the geometry. Also, if vertex welding is Unmodified or Welded is selected.
• Fixing some more bugs: Bug Report: Surface Mesh fails to import in Substance Painter (UVs) - #7 by AlanMattano

[Jussi_Aaltonen]

Thanks for the feedback!

@AlanMattano

A few quick questions: What does baking do exactly? What is its purpose? When and how should it be used correctly?

Texture baking takes in geometry G, texture TA and texture mappings MA and MB. It creates a new bitmap texture TB that being mapped to geometry G using texture mapping MB yields the same look as the texture TA mapped with MA.

Here’s an example where I’ve used BakeMapping from channel 1 to channel 2:
BakeMappingExampleV9.3dm (3.4 MB)

@AlanMattano

I would prefer the Rendering tab to match the Properties: Texture Mapping panel more closely. In the Rendering tab, some buttons are missing and the existing ones are not in the same order as the icons in the Properties panel.

Conversely, the Properties: Texture Mapping panel is also missing some buttons that appear in the Rendering tab.

I filed your request as RH-95931 Texture Mapping toolset mismatch

@AlanMattano

It is quite difficult to understand the current state of UV mapping in Rhino because the UV mapping inspector does not always display or update all relevant parameters.

Surface mapping does not have a primitive that could be transformed in relation to the object. Therefore the rotation and scaling settings have been removed in Rhino 9. I do not know why the Position setting was not removed. @BrianJ do you remember why?

@AlanMattano

One possible solution would be to add a second UV Editor window (post process) called “Final Mapping” (or similar), which would show the actual real UV mesh that will be exported. Alternatively, the existing UV Editor could be updated to display the final, export-ready UV mapping.

This would probably work for mesh objects in some exporters. But many exporters allow for example welding of the meshes. For polysurface objects there are even more settings that affect the mesh and therefore also the UVs. So the UV Editor can’t know what the UV’s look like after export.
If you have modified your geometry after UV editing, you can run TestRenderMeshMapping to replace the mapping primitive with the current object render mesh. That may or may not work well depending on the geometry and the mapping primitive.

@AlanMattano

Perhaps (this may be an ambitious request) Rhino could benefit from a true surface-based 2D UV Editor (with control points/CVs) alongside a 2D UV Mesh editor. This would align better with Rhino’s traditional modeling philosophy — treating UVs as editable surfaces projected into 2D space.

This has been discussed many times. So far nobody has been convinced we should attempt to do it. I don’t know of any software that does it.

@AlanMattano

Finally, it is not clear to me how to properly export a joined UV mapping mesh (UV island). At the moment, the export appears to separate the geometry. Also, if vertex welding is Unmodified or Welded is selected.

I think you need to give an example of the issue. Is this possibly related to some of the YT items you’ve logged over the years?

[AlanMattano (Soaring Stars lab)]

Hello Jussi, Thank you for your time and detailed explanation.

@Jussi_Aaltonen

Is this possibly related to some of the YT items you’ve logged over the years?

All my bug reports have been submitted correctly to JetBrains YouTrack or fixed by you. You have fixed so many export bugs that it is hard to tell. Unfortunately for me, I can’t look at them anymore. I am not allowed.

But here in this one: AM65 UV mapping fail Vr4.3dm (734.6 KB)

Rh9 WIP

For all of this objects, I was not able to import them correctly to other software. Are upside down. I have tried and tried but I can’t find a solution. So I presume it is a bug.

---

About the actual state

A lot of false positives occur because the final mapping is controlled in a decentralized way, spread across the exporter, UV Editor, Properties, Grashopper and the texture itself. All 5 are fighting for control over the final UVs. This is how Rhino works. If the Properties panel goes away, it will simplify things by centralizing more control in the UV Editor.

Yep, so the problem now is that the final UV mapping setup has four or more points of control:

1. The export interface
2. The Editor Texture > Mapping (handy)
   
   

3. The Properties Texture Mapping setup. So this will go away in Rh9? I like that idea.
   

   

4. The UV Editor itself

And eventually also Grasshopper.

They all fight for control. Mapping is spread decentrally, so exporting creates false positives. For the user, it is hard to tell what is really happening.

Some rough ideas on the fly: an option window showing the final UV view before exporting, with the final UVs displayed.

@Jussi_Aaltonen

I think you need to give an example

In Rh9 WIP, make a box, export as OBJ (welded). Notice that the UV islands

are NOT preserved on export.

In Blender

RizomUV

---

@Jussi_Aaltonen

This has been discussed many times. So far nobody has been convinced we should attempt to do it. I don’t know of any software that does it.

In the long run, it would feel natural for users to request this ability. After all, Rhino was originally built around NURBS surfaces — a strong selling point.

The mesh interface side is still not as mature or user-friendly as Rhino’s NURBS surface tools. Therefore, the UV editor feels limited.

Perfect unfolding of complex curved surfaces is not always possible without surface cuts or some approximation. Still, is there a known technical reason that makes direct UV editing on NURBS surfaces much harder than on meshes?

[Jussi_Aaltonen]

Hi Alan,

I sent you a message about your YouTrack viewing problems. Let’s also deal with the export issues there.

@AlanMattano

Yep, so the problem now is that the final UV mapping setup has four or more points of control:

Yes, many things affect the final UV’s exported.

@AlanMattano

1. The export interface

These settings mostly affect the geometry that the texture mapping is applied to. Surely it will that way also affect the final UVs.

@AlanMattano

2. The Editor Texture > Mapping (handy)

Texture has UV space transforms and other UV space settings. Some file formats don’t support these on the textures so they need to be baked into the final UVs too. And this actually not only about whether the file format itself supports it - but whether that option is widely supported by 3rd parties.
We could for example add an option to Wavefront exporter to either “bake texture uv transform to vertex UV coordinates” or “save texture transforms to mtl files”. But as far as I know UV space rotations are not supported.

@AlanMattano

3. The Properties Texture Mapping setup. So this will go away in Rh9? I like that idea.

These are the actual texture mapping settings: how 3d points are mapped into UV space. Texture mappings also support UV space transforms which are applied before any UV space transforms from textures. We are not removing texture mapping settings for Rhino 9 - we have only hidden some settings that based on the mapping type are not relevant. The only example that comes to my mind now are the world space transforms for surface type mapping.

@AlanMattano

4. The UV Editor itself

UV Editor and the Unwrap command create and modify custom type texture mappings. I agree that ideally UV Editor would show the real object geometry in the UV space: meshes as meshes, polysurfaces as polysurfaces and SubDs as SubDs. But in reality the meshes shown in the UV Editor are not from the object geometry. They are the custom type mappings 3d meshes in UV space. In the early days of its development UV Editor was called Mapping Mesh Editor.

@AlanMattano

And eventually also Grasshopper.

They all fight for control. Mapping is spread decentrally, so exporting creates false positives. For the user, it is hard to tell what is really happening.

Yes, there are still commands and plug-ins that bypass the whole texture mapping architecture and directly modify the run-time computed vertex UV data in the render meshes. This issue exists mostly for historic reasons. We’ve been working on making things more consistent.

@AlanMattano

Some rough ideas on the fly: an option window showing the final UV view before exporting, with the final UVs displayed.

This would basically mean exporting and importing the file before drawing the final preview. Perhaps that would improve the workflow. Logged as RH-96804.

@AlanMattano

Perfect unfolding of complex curved surfaces is not always possible without surface cuts or some approximation. Still, is there a known technical reason that makes direct UV editing on NURBS surfaces much harder than on meshes?

Yes, computationally it is much harder to for example unwrap a polysurface. Controlling UV distortion and continuity on curved surfaces while allowing smooth editing is also much harder on polysurfaces. Finite element methods are very efficient and versatile for meshes.
Another level of technical problems would be on how to store the UV parameterization in the openNURBS and maintain it in Rhino as polysurfaces are modified.