UV Mapping has been updated and improved in the Rhino 8 Work In Progress.
- The floating UV Editor is detached from the main window, giving you more flexibility and control over your workspace. This is especially useful for users who have multiple monitors or need to work on large UV maps.
- The new UV Editor supports pinning of vertices and straightening of edge chains. That makes it easier to manipulate UV maps without affecting the overall shape. This can be a huge time-saver for anyone working on complex UV layouts.
- Unwrapping can be done with 3 algorithms. In addition to the Default algorithm there are also now Rigid and Angle Based unwrapping algorithms.
- After unwrapping and UV editing, Rhino will show the objects with full texture resolution because texture baking is not necessary anymore. This means that the 3D model will appear in greater detail and with more clarity. This can help catch any issues with UVs more quickly and make more informed decisions about UV layout.
Try it in the Rhino WIP today and get started quickly with this sample model and tutorial video for beginners.
We hope you enjoy these new features and find them helpful! Let us know if you have any feedback or suggestions for future improvements.
this is fantastic!
a topic I have struggled with myself for years, it’s very clear and I can’t wait to try it.
can you start making grasshopper videos too?
Another wonderful, clear and understandable video from you.
I’ve always headed out of Rhino for my UV mapping in the past, but now I feel it is time to re-visit the Rhino UV Editor.
Nice, this has always felt like an afterthought in Rhino to me. Glad it is being addressed.
You may also want to have a look at Blender’s ZenUV addon, it has some really advanced, yet simple UV workflow features.
Thanks all! Have fun and please let me know any specific requests or issues you have.
Haven’t had time to look into it yet, but this seems like a real improvement.
In the latest WIP I noticed that I can no longer osnap to the corners, edge mid and center of the UV area. When working with symmetrical objects it was really nice to be able to easily center them using osnaps, and I think it worked like that previously?
A tool I would love to see, is an automatic “rectangulate” tool for 4-sided meshes; basically pinning the 4 corners of the UV and straightening the edges to be horisontal/vertical between them.
@Normand I can use Vertex Osnaps in the UVeditor but I’m not seeing a Mid or Center on anything there. I used ExtractUVMesh to get some UV meshes in the normal Viewport as well but see the same behavior there. In looking at this, I did find that Grid snap is not using all the grid lines currently in the editor which I filed as https://mcneel.myjetbrains.com/youtrack/issue/RH-72416 . If you can give me a specific case where you aren’t getting an Osnap in the editor where you would if that same mesh object were in a normal viewport please send it over. You might like using Distribute or Align in the UVeditor too.
Filed the ‘rectangulate’ request too as https://mcneel.myjetbrains.com/youtrack/issue/RH-72417 , I added a thought on it about detecting corner tolerance as well so maybe it’s an update to Straighten Edges… Jussi will of course need to decide what makes the most sense.
Thanks for the feedback!
Hello! Could we have a live update feature, please? Meaning when the texture verts/faces are moved, the 3d viewport should reflect the change immediately, not just after mouse up.
Can it compatible with sketchup model?
If the format the file is sent in can hold UV information then it should transfer. Obj and Fbx are the two that come to mind. If an app supports the Rhino 3dm format they can also read the UVs stored in it.
RH-72416 is fixed in the latest WIP
This looks SUPER intuitive. Excited for it! Even though I’ve only just learnt to deal with R7’s mapping.
Today I was having a second go at Twinmotion. It went much better but dealing with object textures was still a massive bottleneck. Will exported objects look correct in the rendering engines?
They should if the file format supports UVs such as 3dm, Obj and Fbx and the renderer you’ll use also understands the mapping method used. My experience with texture mapping being understood has been mixed with Unreal Engine and Twinmotion in the past. I found that some mapping methods set in Rhino weren’t entirely transferred with elements like size values being incorrect if WCS mapping was used for instance. If memory serves, the most reliable method was to do a custom Unwrap in Rhino and then send the file. A new material and repeat values for any textures as well as referencing a texture again may still be needed of course.
The unwrapping sucks because then you lose your live link and ability to live link. This places Rhino at a huge disadvantage in the market as one of it’s biggest strengths is it’s ability to create fast conceptual models (which then go into the rendering engines).
This partially solved my problem: I changed the setting below to “box”:
I don’t know what it’s like dealing with 3rd parties but if there’s a way to make the textures look right (or at least close) in the rendering engines it would be a big plus. The amount of extra hours I would spend after say, a year, would really add up if I have to modify each and every object in every model I import.
I tried Twinmotion briefly in the past but ended up using Unreal Engine more which if memory serves did use the custom UVs from Rhino. Perhaps the issue is unique to Twinmotion? If you have a small sample file, please post it in a new forum thread to explain what’s not working. It may be something Epic’s developers would need to address versus any change we could make in Rhino.
I tried Twinmotion briefly in the past but ended up using Unreal Engine
Isn’t Twinmotion based on Unreal Engine?
If you have a small sample file…
It should be and easy enough issue to reproduce and I’ve posted about the issue before but nobody cared; I think it’s an issue that will stay buried with R7.
Comparing say a Sketchup user to Rhino (all else equal), a Rhino user will model much faster after the initial learning curvet. Let’s say a visual artist completes their model 4 times faster than a Sketchup modeler, but upon importing the model they lose all that time fixing textures. This would potentially deter a lot of users as it essentially negates the speed advantage and removes the incentive to challenge that harder initial learning curve. This sucks because Rhino is such a good platform for rendering/conceptual models. If ensuring the texture mapping is compatible with the most popular rendering platforms isn’t too resource intensive then it’s well worth it.
Perhaps the issue is unique to Twinmotion?
It’s not unique to Twinmotion. But one user did mention that Twinmotion changed something at some point and that caused it to not jive as well with textures. Escape has issues too they’re just easier to solve I guess (partially due to better synchronization with Rhino). But remember that as people’s software profile gets loaded up with more and more subscriptions (Enscape being one of them), it draws them closer and closer to simply giving in to Evildesk’s AEC collection.
I agree that everything should just work and this rang a bell as something I had reported internally. See https://mcneel.myjetbrains.com/youtrack/issue/RH-67133 and specifically the screenshot where I show what works and doesn’t in UE. I filed this a year ago and it is on @andy’s list. I would guess you might see the same in TM but I don’t know if the development teams are different.