Hi @nathanletwory
I’ve experienced this more than a few times, but I’m seeing no pattern (so far): Upon envoking Cycles (as opposed to render preview) the UV mapping suddenly gets shifted, completely messing up the UV islands. This usually happens on complex mesh objects with complex UV maps. Is this something you can recognise/has seen happen? Sometimes it helps to undo the latest command, sometimes all is lost, and the only remedy is to re-load the file from the last savepoint. I’m working on scanned meshes at the moment, and if I spot a pattern/find a sure-shot way of making it happen, I’ll be sure to upload a file and instructions!
-Jakob
Can’t say I have noticed this. Cycles (I assume you mean Raytraced) does not edit data, everything comes from the ChangeQueue mechanism.
I’m at-mentioning @andy and @Jussi_Aaltonen in case they have seen anything along these lines.
Steps to repro would indeed be useful
Hi @Normand
This is something I haven’t heard of before.
Has this recently started happening?
Do you have UVEditor open when that happens?
What texture mapping type do those meshes have?
Are they imported or UV edited in Rhino?
Can you provide a sample file that you know this happened with?
SystemInfo would also be nice
Here goes - this one seems to repeatedly mess things up. Looks fine in Rendered mode, but as soon as I hit Raytrace, things go haywire. This a mesh coming out of RealityScan, but I’ve seen it happen with scans from other sources too. The UV editor is NOT open when this happens. Actually just tested to see if opening the UV editor BEFORE going to Raytraced helps, and that might be it! At least it’s a place to start - seems to work here! So in a nutshell: If I open the attached file and go directly to raytraced, it messes up the UV mapping. If I start the UV editor first and either leave it open or click apply, all is well and it renders correctly
Rendered
Raytraced (without opening the UV editor)
As mentioned, I think I’ve been seeing this only when dealing with scanned meshes, so somehow forcing Rhino to unwrap the UV “settles” the UV islands in the correct place…?.. or something… I have NO clue what I’m talking about As you’ll see if/when you open the file, these scans have very complex UV maps, as the scanning software doesn’t retopo the surfaces - lots of little islands scattered all over the place!
The original file - in this case the FBX version - can be downloaded from here. I can’t recall if I’ve seen this strange behaviour only with imported FBX files or if it’s been happening with other formats as well.
And the file:
deer skull mount.3dm (14.4 MB)
HTH, Jakob
I confirm this file works the same with bella as you describe for raytraced – uvs messed up in the same way you show above, unless the uv editor is opened first.
Thanks @jdhill and @tay.othman for testing - always good to know that it’s not just my setup that’s acting up Hopefully it’s something that can be fixed. By the way @Jussi_Aaltonen - if I leave the mesh untrimmed before going to raytraced, it seems to work OK - it could be a hint as to what is going on?
-Jakob
Thanks for models and info @Normand!
I am able to open the original fbx correctly in Rhino 7 and both Rendered and Raytraced display modes show the model correctly.
But in the 3dm file the texture mapping is different. When Raytraced mode starts it applies that mapping and shows it correctly - Rendered display mode and UV Editor appear to use outdated computed data.
So the question is: how did you trim that mesh in the fbx file? I tried with MeshTrim and it worked fine.
fwiw, exporting the mesh from the .3dm to.obj or .fbx, and then importing either into a fresh 3dm, appears to “fix” the issue – you can mess with texture mapping params (e.g. uvw repeat) and undo will return the uvs to what they were, while in the original “defective” 3dm, any change will mess them up, and undo will not fix it.
Hi @Jussi_Aaltonen
Hmmm… that’s a good question I actually think it’s a combination of several different things. I think I simply just deleted some faces (subobject selecting them) and I might have run smooth on either the entire thing or portions of it. I might even have manually moved/scaled some areas of the mesh. I’ll keep an eye out for when things go wrong!
-Jakob