UV-Editor + PushPull GumBall Workflow

[Erazmataz (Tim Elkær)]

Would it be possible to take a closer look at the UV-Editor in relation to PushPull and GumBall operations in Rhino 8 + WIP? Issues has carried over from Rhino 7 and they are still present in Rhino 8 SR 31 and the current Rhino WIP. Use theese files to see the issue or create you own.

Any texture with stripes make it easy to see the issues in the Viewports. I have used a DoubleSided one.

PBR_Double Sided.rmtl (61.4 KB)

UV_WIP_9_May_02.3dm (116.8 KB)

The starting point is a (non-trivial) Box with some cutouts done with GumBall, Boolean or Trimming. The Starting point should be a ClosedPolySurface with a standard BoxMapping.
Use a Cube for the size of the BoxMapping to make all stripes look the same on all sides.

The provided 3dm-file is 80x20x20 units and the BoxMapping could be set to 20x20x20.

Nothing should be surprising here and you can freely use the Shift+Ctrl (SubObjectSelection) to manipulate the object without getting unpredictable results. Test: Make the two cutouts deeper or more shallow and extend one of the ends and reduce the lenght in the opposite side. All is OK.

UV_WIP_9_May_05_BoxMapped+GumBall_Edited.3dm (414.2 KB)

Now try to UnWrap the Box and match the stripes in the UV-Editor. Choose all edges as Seams except the four lines in the “bottom” of the cutouts. You would like the three sides of each cutout to be stiched together as meshes in the UV-Editor. Use the vertices of the meshes to reposition and scale the meshes so all stripes flow across the surfaces as precise as with the BoxMapping. Rotate the two ends 45 deg, but keep all meshes in the same scale. I have scaled them 300 pct.

UV_WIP_9_May_07_UV+Seams+All_Aligned.3dm (430.9 KB)

Save your work, because in the last step the GumBall/PushPull-operations will destroy your work!

Without changing anything else, use the GumBall (arrowheads and/or extrudedots) to change the object back to the original shape (80x20x20 units with two cutouts in the XY and XZ-planes 20 units wide and 10 units deep). What I get after this operation looks a mess in Rhino 7+8+WIP.

UV_WIP_9_May_08_UV+Seams+All_FuckedUp_by_GumBall_Editing.3dm (455.1 KB)

EXPECTATIONS: I expect Rhino to be capable of updating the rendermesh in the UV-Editor to match any trivial editing I might do with SubObjectSelection and/or the GumBall translations. If I add new faces or radically change the topology of the Closed PolySurface this will not work, but if I only move things around without changing the topology, I expect all of the meshes to update.

WISH: I wish for the rendermesh to update if I remove faces by merging them with neighbours fx if I collapse faces using GumBall-ExtrudeDots and/or Arrowheads to remove one of the cutouts and MergeAllCoPlanarFaces - which actually (in Rhino 8+WIP) is part of the GumBall-PushPull-workflow.

BUG: The value used to select if CoPlanarFaces should be automatically merged or not after a GumBall-operation has not been working in any version of Rhino 8 SR 1-31 and I’m not sure it is working as expected in the current version of Rhino WIP. @scottd has been looking into that…

Rhino 7 SR 38 + Rhino 8 SR 31 + Rhino 9 SR 0 2026-5-12 (Rhino WIP, 9.0.26132.1230)

[Erazmataz (Tim Elkær)]

A further elaboration in Rhino WIP. Description of steps to take in the Notes-panel of the 3dm:

1. Turn object C into Object A by using only the GumBall Extrude-Dot

2. Turn object A into Object D by using only the GumBall Extrude-Dot

3. Turn object B into Object E by using only the GumBall Extrude-Dot

4. Compare your result with mine and reflect on what you see in UV…

Using Rhino 8 SR 1-31 - It has been like this since the launch in 2023.

ABC_After_UV_on_ABC.3dm (582.7 KB)

[Erazmataz (Tim Elkær)]

Same issue with an object with a topology like a frame with a hole running through the object.

Here is a sample file created in Rhino WIP 9 today (20. May 2026).

Frame_400x200x600_Before_GumBall_v9_DEMO.3dm (954.8 KB)

After removing the “frame inside the frame” using only the GumBall ExtrudeDot four times, you’ll get a result similar to this. Notice the size of the stripes inside the frame - and the bottom(!)

Frame_400x200x600_After_GumBall_v9_DEMO.3dm (967.3 KB)

WHY IS THIS IMPORTANT?

When you are designing cabinets for kitchens the best-practice in all other CAD software is to first create only ONE cabinet (with or without a front) with standard dimensions such as 600x600x800 mm. Then texture unwrap it in that dimension, choosing the relevant seams and assign a material. Next step would be to create all of the relevant variants from that ONE cabinet (different widths, depths and heights) and then just “SaveAs” under relevant names, so you can later count the number of Blocks and export CSV. When the UV-mapping in Rhino 7/8/WIP work like it currently does, you’ll will get unpredictable results.

This example show how this traditional method has been used in SketchUp and the result imported to Rhino from the SKP-file. You can then open the Rhino-8-file and Export all Blocks as separate 3dm-files in the Block Manager. There is unfortunately currently no easy way to turn all edges black or grey, since an SKP-file is imported to Rhino 7/8/WIP using the color of the Material in SketchUp instead of the color of the Layer/Tag.

Opstilling_Med_Højskabe_Rhino_8.3dm (1.1 MB)

Opstilling_Med_Højskabe_All_InkStorm_108.skp (4.9 MB) - Assigning a dark material to all objects in SketchUp is currently needed, if you don’t want white-edges on all geometry in Rhino.

[Erazmataz (Tim Elkær)]

@wim I understand why this post is now related to rendering but my issues with the UV-editor are actually more related to modelling since the problem with the meshes in the UV-editor don’t update as you expect them to do, when using GumBall editing and/or the Push-Pull tools added in Rhino 8