I have worked out that its easier to use Rhino Renderer and Rhino textures to have easier control over textures without the hassle of having to do texture mapping…so I was playing around with that, and then put a door in the wall, which I undid, then re-did in the attached screen recording.
I am just wondering why that is?
I thought I had solved my problem with wanting to show the wall cladding types using the ‘realistic’ view type in our elevation layouts, but now have this issue!
Yes, this is a known issue with objects that has no texture mapping applied. You can see this issue just using Rhino native breps:
Create a box (using the Box command)
Assign a material with a texture to the newly created box.
Explode the box.
Join all surfaces into a poly surface.
New brep will probably have changed the texture direction.
Now create another box to subtract.
Subtract the box.
The texture direction will change again.
The problem happens because, by default, Rhino uses surface texture mapping. Surface texture mapping means that real UV coordinates from the surface will be used as texture coordinates. Boolean operations (and many other geometry operations) will modify the surface and depending on how the new surface is computed, UV coordinates may be transposed. My guess is that when Rhino creates the new front surface, the first curve on the trim loop will define the U coordinate. Which curve will be the first is something unknown, as it can depend on how surfaces lie in the space, how curves are ordered to speed-up boolean, etc.
You can solve this using material with WCS texture coordinates, or just applying a box surface mapping on the objects.