Can anyone explain why Rhino layout a texture map like this? In this case I have the wood grain on the object running the wrong way on one side. Makes no sense to me.
Thanks,
Dennis
Hi Dennis - the texture layout does not know about what material you are going to apply - but the control you have open there will let you change it to however you want - you can select the skinny rectangle that goes across the grain in the layout and rotate it 90 degrees and move onto the part of the bitmap that looks best - you are allowed to put in the same place as another panel if you like, it need not go on an unoccupied part of the bitmap.
-Pascal
Thanks Pascal. I understand that but it makes texturing more difficult. If all the map sections ran in the same direction, it would make applying a material with any sort if visible grain easier to work with. As it is you can’t fix the way the grain runs by rotating way the material is applied. You have to go in and edit the UV unwrapping itself. This seems crazy to me. Do I have the wrong type of mapping applied (e.g. Box vs. Surface?)
Hi Dennis- can you post that thing as you have it?
-Pascal
Instead of unwrapping manually, wouldn’t it make much more sense to apply a box mapping to boxy objects?
I did try that. The map had all 4 vertical sides of the column laid on top of one another. Not the most efficient use of the texture space it seems to me. I’ll post a sample tomorrow.
Pascal,
Here is the 3dm file and 2 screenshots showing different mapping examples.
Thanks,
Dennis
Column_mapping.3dm (431.3 KB)
Hi Dennis - as far as the current mapping goes, if you look at the ‘wrong’ side and the ends you can see these are parallel and the other three sides are parallel - I don’t know how Rhino decides but that seems as reasonable as any without knowing what the intentions of the user are.
If I apply capped, cplane based box mapping, I get all six sides with the same mesh occupying the entire texture - piled on top of one another… sort of the exact opposite problem from the one you show. Neither seems very helpful, I am still poking at it.
If I make a box as a brep and apply box mapping and then UVEdit, I get six separately accessible meshes, but for your object these are grouped and impossible to edit - apparently the UV mesh is inheriting the group status of the input object, which seems… wrong.
RH-62540 UVeditor: grouping is inherted
-Pascal
I would think that the mapping process would figure out that with a box taller than it is wide would by default lay out the long sides parallel to each other. Call me crazy!