Hi !
I’ve an issue with GH Component: Human / Custom Mapping (UV) [the yellow duck]
I’ve used it for made a custom UV unwrapping for our needs =)
But, the result is different online =/
In Grasshopper (Rhino 3D v7SR23 + ShapeDiver 1.9.4 + Human_1.2.0)
In shapediver (rhino v6)
Any suggestion please ?
I’ve tried another method.
I’ve use ShapeDiver’s ‘Transfort Texture UV’ insteed:
But: same bad result in SD =/
(still working as espected in GH)
Are you meshing meshes or Breps? Could you share a minimal definition so I can reproduce the issue?
Sharing for others a simplified one: custom_uv_method.gh (22.9 KB)
Cyan groups are ShapeDiver’s components and Orange groups are Human’s components.
Display 3 and 4 produce same result in GH, and now working in SD too!
Now debugging my own definition… 
Found my problem !
I use dynamic flipped planes to correct orientations, using this componenent:
This component does not seams to work correctly in ShapeDiver.
When i internalise the ‘flipped planes’ data, it’s working in ShapeDiver (but not updating with parametters)…
Any suggestion ?
Up!
Any other method to help me ?
Could you upoad a minimal definition using the Flip Planes component that shows the issue?
Additionally, can you confirm that you are using Rhino 7 locally but are uploading to a Rhino 6 server? This is the likely cause of your issue. You could try to open the same definition in Rhino 6 locally and check if the issue is present there. In that case, please contact our team if you need to upgrade and have access to Rhino 7 servers.
Hello Mathieu,
There is an minimal definition: custom_uv_method_bug.gh (38.7 KB)
You can ‘toogle’ the issue with the ‘Use Internal Planes’ to see the difference in ShapeDiver. When we use Internalized planes data, i’ts working, else not. Still investigating…
And i’ve also tried: everything is working on Rhino6 and Rhino7 (internal data or live data).
We’re happy wih ShapeDiver Rhino 6 server for now =)
Is there a significant problem working with Rhino 7?
(especially since the GH and SD have the same versions)
Thanks for helping !
My apologies for the delay, I had my suspicion that the issue came from “unsafe” assumptions in your model but it took me a long time to investigate.
The problem comes indeed from the first components in your definition, where you successively “Join Breps”, “Merge Brep Faces” and “Deconstruct Rectangles”. Any of these operations (I suspect one of the first two but maybe even Deconstruct Rectangles) will possibly result in slightly different mathematical definitions for the resulting surfaces and rectangles. For example, the same identical rectangle can be defined by two different normal planes depending on the orientation of its edge. I tested the planes coming out of the “Decontruct Rectangle” component and it appears that the ShapeDiver servers give a different orientation for those planes (opposite normals) as when I run the definition locally. This is something that can not be predicted, different version of Rhino but even just two different machines running the same version might give different results. The only way to prevent such issues is to add sanity checks to your definition after such components, and if necessary flip objects to ensure that the orientation you expect is respected.
I hope that clears up some of your issues.
Thanks for your message!
Indeed, remplacing “Deconstruct Rectangles” with my own mathematical cluster, using project inputs, to get the same component’s outputs needed (center origin points and domains), to build well oriented normal planes. Mapping is now working perfectly, thank you @mathieu1 
