Editing UV’s in Rhino is at least cumbersome but everyone who works with it knows that and somehow agree with its nature - a general overhaul of this would be more than welcome. Anyway i found today that opening uv editor doesn’t respect selection of channel which i’d like to edit:
Let’s say i have two channels of uv’s (both unwrapped differently)
Above relates to both v5/v6. I hope this won’t be moved to “Future”.
It also applies that Rhino never asks if i would like add another unwrap as second channel like for planar for eg. it just always assume that i want to unwrap 1st one. Here also imported objects have problem since it is not concerned as a custom object but a surface mapping(?) and in multiple channels Rhino shows nothing…
Tip for others:
before doing anything with such model at first glance hit uveditor button and just accept it it will show then imported mapping as a custom object mapping.
I decided to split my question from other topic to here since it could be more relevant here:
I’m also tackling issue related to the fact that GetCachedTextureCoordinates was returning different coords than _ExtractUVMesh or (null) and as i assume due to that fact part of the unwrapped mesh is folding under the rest of the mesh ( it looks like it lost one seam during processing )
@Jussi_Aaltonen does v6 already have a way to overcome this issue?
I found out i have to set coords to get them back after mapping transform however it still returns wrong coords.
It is really wishy-washy when it comes to dealing with uvs here.
So the question here will stay the same what is the proper way of obtaining unwrapped meshes per channel in uv space?
I even prepared files for this - UV_Info.zip (43.7 KB) - and i’d really like to know where my logic failes. Or it doesn’t ?
Hi D-W, I will take a closer look at your model in a bit with someone who is not as awful GH user as I am.
But I can already say that custom object mapping can add UV seams that the object render mesh can’t represent. And because GetCachedTextureCoordinates is based on object render meshes that will be the first problem. _ExtractUVMesh extracts the actual custom object mapping primitive projected to uv space - and it should show all uv seams correctly.
It may well be that there is no way to get uwrapped meshes for channels other than #1. I’ll check this.
The thing is that i need actually exactly that uv mesh since i need to map stuff from uv to xyz and the other way from xyz to uv - and i don’t need it in gh but in rhinocommon - gh file is just for rapid showing api issue and so far i didn’t find a way to get it.
@Jussi_Aaltonen theres no magic there are 2 main components with api code rest is just for “preview” purpouse if you double click c# component you will see code to investigate.
@Jussi_Aaltonen those are actually two things - first related to UI bug - not considering channel selection - second to API - due to getting object related uv mesh.
And for now, there’s no other way/ workaround to overcome this problem? That would be very bad news for me.
