BUG Join: Preserve individual custom texture mappings when joining

[AlanMattano (Soaring Stars lab)]

Expected vs Actual

Bug Request Join: Add option to preserve individual custom texture mappings by auto-assigning separate channels.

Old request, and the need remains important in 2025 (Rhino 8+):

Without this option, Join is effectively broken for any production workflow that requires both a single mesh (performance) and correct per-part UVs (visual quality).

When joining separate surfaces/polysurfaces that each have their own carefully adjusted custom UV mapping (different mapping types, manual unwraps, etc.), the resulting polysurface loses all individual mappings and forces a single mapping for the entire object.

This breaks workflows where different parts require different UV treatment (e.g. cylindrical vs planar vs custom unwrap) while still needing a single joined object for performance reasons.

Real-world requirement (unchanged since the join introduction):

• Game export, Unreal/Unity, VR presentations → minimum draw calls → one joined mesh/object required
• But visually correct texturing → different UV strategies per part required

Current workarounds are painful:

• Manually re-create everything after join (extremely time-consuming)
• Export → join in Blender/RizomUV/Plasticity → re-import (destroys history, adds steps)
• Keep objects exploded (hurts performance)

Requested solution (same as original 2019 request, still missing):
Add a simple checkbox in the Join command:

☐ Preserve individual texture mappings

• Automatically assigns each original mapping to a separate mapping channel in the joined polysurface and updates the material to use per-face/channel mapping

This would:

• Save hours on every complex model
• Make multi-channel mapping accessible to users who don’t know the advanced tricks
• Keep Rhino competitive with Blender/Max/Maya/Plasticity for game/VR asset creation

Original thread (still unresolved):

[FEEDBACK] V7: Joining surfaces does not lose its individual texture mapping unwrap

I was trying to make a custom Unwrap but was not cutting along the selection. It looks buggy. And I was not able to make individual custom unwrapping for a polysurface (or I do not know how to use multiple mapping channels). So the object was divided it into 3 different polysurface and apply different mapping technic to each one. But when I use “join” I lose its individual texture mapping unwrap. I wish an option in “join” that allows preserving the texture mapping and (automatically) assign ea…

Similar recent requests confirming the problem persists:

Keep Texture when Joining

is there a way that the texture stays put when i join as either a subobject mapping or that it creates an entire texture mapped accordingly? before anybody suggests using subobject texturing on a joined object, i have huge issues with getting textures to align, so i am often mapping the surfaces separately because that is at least managable without having to trial and error for an hour… before join [Bildschirm­foto 2023-07-07 um 08.36.42] after join [Bildschirm­foto 2023-07-07 um 08.36.50…

Retaining joined meshes texture coordinates - how?

I have 2 mesh objects with custom planar mapping applied to each of them (same material). When I join them, the mapping gets messed up. How do I make the resulting mesh vertices to remember the original texture coordinates? Or - how to embed/bake the custom texture coordinates applied via mapping widget to the mesh vertices? Any help would be much appreciated. Thank you

Texture gets messed up when joining

In the attached, there is a bent wood piece (just a pipe capped on one end) plus its mirror image. It has a woodgrain texture applied… If you leave them unjoined, fine, but as soon as you select the two and call join, the UV gets swapped on one half and it takes the texture with it… This seems just plain wrong… OK, remove the end caps on the lower end… Now join. It’s sorta OK, but the texture no longer matches across the seam like it did before… something got swapped. Now Cap… boom, it’…

Cut and paste wont keep mapping channels

Hello, When I copy to clipboard an object that has mapping coordinates defined and paste it in another scene, the mapping channels are gone. Is this by design ? The only way to preserve them seems to be exporting the object first to disk and importing into the other scene … Is this normal ? Using Rgino 5 with latest SR

Please implement this small but high-impact option. It would be hugely appreciated by the entire real-time rendering community using Rhino.

[nathanletwory (Nathan 'jesterKing' Letwory)]

No need to repost. You already logged this: RH-53858 Join does not conserve individual surface UV mapping

[AlanMattano (Soaring Stars lab)]

Hello Nathan, I´m blind!

Just a reminder of the situation. You no longer need to include the Rh track number and link to the Join bug report. It is not helpful for us. We want to know the actual state and progress in this thread. Please keep us update.

As I understand, the Rhino Team disabled user access to YouTrack without providing a clear explanation.

As a result, I´m blind!

I’m now unable to track the status of the ~50 bug reports (I miss Pascal) I’ve already submitted, nor to organize the remaining ~30 I still need to report (from 80, I have to guess which of them are). I need to think about how to fix this and make a big spreadsheet with links.

YouTrack wasn’t only helpful in submitting bugs — it was essential for understanding which issues were already logged, how they progressed, and what temporary workarounds existed. Losing access means losing that transparency.

At the moment, the only way forward is for me to recreate my own “mini-YouTrack” externally, probably in a spreadsheet, just to keep things coherent. That shouldn’t be necessary.

If there is any internal workaround, alternative URL, or read-only mode that users can rely on, it would help a lot. Otherwise, we’re effectively reporting bugs blind, unable to see whether they are duplicated, fixed, or acknowledged.

Thank you, Nathan, for taking the time to read this user bug report post.

[wim (Wim Dekeyser)]

@AlanMattano

Just a reminder of the situation. You no longer need to include the Rh track number and link to the Join bug report. It is not helpful for us. We want to know the actual state and progress in this thread. Please keep us update.

You added two Discourse links on December 29^th.
You filled in the “Affected versions” field on March 9^th.
I added a link to this new thread a few minutes ago.
-wim

[AlanMattano (Soaring Stars lab)]

My frustration comes from how old/long this issue really is. Join has existed since the earliest Rhino, and from the very beginning, it has rebuilt the render meshes but never merged (destroying) the UV mappings.

So while the links were added recently (THX), the underlying bug feels like it has been with us since… well, let’s say 1996-2003, give or take a decade.

[AlanMattano (Soaring Stars lab)]

(An [ x ] can be added to the icons of each tool that is not working completely to remind me to be careful or not use it at all.)

Bugs are like lies.

You can hide them for a while, but if they’re not fixed, they keep coming back, eating stronger.
Coming from Alias (90s), where visual precision is everything, I noticed this behavior in Join from the moment it was introduced.

And the truth is: this type of bug is like a parachute that doesn’t open.
The customer doesn’t come back to complain. They simply never return.
I’m just trying to survive here, being persistent.

I can’t imagine how many potential users Rhino has silently lost over the decades because surface continuity and UV integrity shape the very first impression of quality. And now that rendering is everywhere {fast, accessible, unavoidable }, issues like this can no longer be hidden behind workflow complexity.

Fixing _Join isn’t just maintenance; it is making this tool finally truly available.