Hi McNeel team,
I’m having a problem where every time we convert a mesh to SubD we lose UV coordinates. Here’s an example where it’s messing all this PBR hair work when we are trying to simply smooth the hair poly strips:
Here’s a screenshot of the problem:
Thanks,
Gustavo
Yes, posted this a while back:
Furthermore I also want to link to this thread:
Where I found a workaround that enabled me to subdivide in v6 while keeping the UV’s by first running UvEditor before running subdivide
Oh God. We can use very little of subD modeling in Rhino because obvious reasons. But we are realizing that even when bringing SubD work done elsewhere we encounter all kinds of problems because there’s little attention being payed to maintain SubD-friendly workflows.
I think “don’t break anything’” should be the number one priority of all these tools, even before trying to build anything new.
G
Have you tried running UVEditor once before turning to subd? It looks like it works here, also the subdivide on a subd bug seems to be solved.
On my screenshot on first post I show UVeditor before SubD on the left; UVeditor after SubD on the right. Am I missing some other step?
So you have a mesh, run UVEditor, click apply, then convert to subd? If I do that, UV coordinates stay in tact and subd object gets the original mesh as custom mapping object assigned. I didn’t try this with multiple objects at once though, that might be the difference?
Ugh… I see. I have to Run a command that requires manual mouse clicking and drawing rectangles all over my viewport, and then hit ‘Apply’. Never mind the meshes are already fully UVed. What on earth I’m applying for here?
Thanks for clarifying this Gijs.
This makes no sense McNeel team! The mesh already had all its UV unwrapped in it. No one wants to go to through every single item in our scene and run UVeditor and hit Apply to meshes that are already fully UVed!
This is broken. If I run UVeditor and I see the UV layout that it was already done, I should not have to apply for anything.
Imagine having to do this to a car model with 1000+ parts? Why? Can You please fix this?
Thanks,
Gustavo
This is a bug. I agree that using ToSubD to convert a mesh into a SubD should copy custom mesh texture coordinates and it does not. Fixing this correctly will take some work. Details and a simple test case are in
https://mcneel.myjetbrains.com/youtrack/issue/RH-59465
Thank you Dale. Can we please also make sure that this persistent mesh UV coordinates also stay intact on the reverse situation: when we extract _controlpolygon from a SubD object.
I know historically Control polygon extraction was used for topological reasons only. But now is a common (and so far the only) way to go back and forth between SubD and Poly models when each topology type in the only valid input for terrain tools/workflows.
Also related to this reality of round-tripping via _ExtractControlPolygon: The extracted Polygon should inherit all object properties like _ExtractRenderMesh does. Right now it does no. See below:
Thanks,
G
“the object level rendering attributes”… and I’d add any object attributes, such as layer, name, etc.
Thanks!
… I guess. Of course, that’s gonna raise the price by a lot. Good news is you’ll be able to “save” even more on your capital expense deductions.
