Rhino 9 WIP
BETA (9.0.26216.12303, 2026-08-04)
Rhino 8 SR33
(8.33.26188.13001, 2026-07-07)
I’m isolating the issue to provide a small file with clear steps.
Included you will find a zip file (AM75 Block UVmapping) with three Rhino 9 files:
one collection and two blocks.
AM75 Block UVmapping.zip (580.6 KB)
Steps to reproduce
- Open the collection file.
- Notice the texture is not correct in Block A as shown in the screenshot bellow.
- Select the blockA and update it (or rename it as a workaround).
- Observe the material / UV mapping on the other block.
Expected
Both blocks keep correct UV mapping and materials of the original file after insertion and update.
Actual
On my PC, Block A shows an incorrect texture (see screenshot).
Updating one block breaks the UV/material on the other. Fixing the second one then breaks the first. The problem chains and prevents adding more blocks cleanly.
hi @AlanMattano
I see the UV mapping issue in the file you sent, however:
I cannot reproduce the texture breaking on the other block that you show in your video. The object that has wrong mapping stays like that, no matter what I do.
I cannot reproduce it when I create a new file and add the two blocks.
I’m curious which are the exact steps to recreate the issue from scratch. I’ll log a bug for this issue anyway, since the UV mapping on the WoodColletion4Pablo3 FINAL block is different from the UV mapping it should have.
Thanks Gijs.
I presume the logged bug will fix the UV mapping difference on the WoodCollection4Pablo3 FINAL block.
Once the fix is in, I’ll retest the full sequence on my local machine to confirm it is not related to my environment or any external files.
@AlanMattano sorry, I looked at the file again, and at first thought something was wrong with the UV mapping, but it was a missing texture. If I look at it in UV mapping mode, it looks correct to me.
I’ll send you a recent build to check if that resolves the issue.
I tested it with the latest Rhino 9 from your link (9.0.26219.00303). The issue is still there.
My gut tells me there is more than one bug here. Because why does the mesh hide when I hide the layer named “Blocks”?
Steps
- Open AM75 Bug Report 005.3dm
- Create a new layer
- Make the new layer current
- Hide the layer named “Blocks”
- Notice that the meshes disappear
Actual
On my PC, both Block A and Block B meshes disappear.
Expected
There should be no relation between the project layer named “Blocks” and the imported blocks.
Hypothesis
When the blocks are imported they appear to be assigned to the current layer.
If both end up on the same layer, something may be going wrong with material or UV handling (shared references or shader data being overwritten). This is just a presumption — I don’t know the internal code.
That is not how it works, and it never has worked this way. When you add a block definition to Rhino, no matter if it is linked, embedded or both, once you place an instance of that block definition, that instance has to reside on a layer.
It’s probably one of the most confusing parts of blocks.
Again, I can’t reproduce your bug here on my end, the file you sent looks ok (apart form the missing textures)
In UV space:
Can you reproduce the issue that you show in your video in the file you sent?
Yes, I can still reproduce the problem shown in the original video, but only in the big 1 GB file.
I cannot reproduce it in the small file I uploaded (AM75 Bug Report 005.3dm).
Would it help if you try fixing the missing textures first, to see if that solves the main UV/material issue?
The original file is very large (about 1 GB), so I don’t know a good way to upload it to you.
About the layer behavior
I’m still a bit confused by how layers work with blocks.
When I insert a block, the instance is automatically placed on the current layer. That connection feels unexpected.
Would it make more sense if, when inserting a block, Rhino automatically:
- Creates a new dedicated layer for the instance and puts the block as a child of that layer, or
- Hides the instance from the normal layer system so it doesn’t appear to “reside” on a visible/current layer (which can feel random to a new user)?
Just thinking out loud about the UI/UX.
You can upload large files here
As for the blocks:
We’re not going to change the way this works. Sometimes you want to use the same blocks in a file and control their visibility with layers. Simple case: floor tiles that are used on different levels in a building.
I cannot fix missing textures on my end.
Thanks Gijs.
I just tried to upload the large file (about 3 GB) using the link you provided. And fails: Proposed upload exceeds the maximum allowed size. I will keep trying. Do you know the max allowed size?
It contains the original file + a few short, small videos with the exact steps to reproduce the issue.
I understand the decision about layers and blocks; it is unconventional, but the floor tiles example makes sense.
Thanks again for checking this, especially on a Saturday.
I managed to upload a reduced version of the file (1.5 GB) with the original model + short videos showing the exact steps.
Please let me know when you receive it.
Thanks again.