I have a very large definition that creates a different pair of surfaces on GH Mac than on GH Windows.
I’m not sure where to find the starting point of this discrepancy. Does Network Surface produce different results on Mac vs. Windows?
Attached is an example extracted from my larger definition.
Surface Join Problem GHmac.gh (132.8 KB)
Hi Leo -
At this stage, there’s nothing in that .gh file that points to the origin of the issue. The Brep Join components here are irrelevant as the inputs already differ. When you bake all 4 to a Rhino document and run SelDup, nothing is selected.
-wim
Thanks for your reply Wim.
I’ll start tracing back through the definition to see where the geometry result differs between the two platforms.
Ah I found the culprit.
Wherever the Explode Curve component is used the indices of the resulting curves seem to be reversed between the two OS’s.
I’m having to trace through my definition and add different indices for selecting curves depending on whether the OS is MacOS or Windows.
Hi Leo -
In a quick check here, the indices are identical on both OS’s. Can you post a curve with which this is not the case?
Thanks,
-wim
I was on the wrong track, but I’ve now found that the curve I exploded was the result of an Offset Curve operation. Here is an example of an arbitrary curve where Offset Curve produces a different result in Windows vs. MacOS:
Curve Offset Point Order.gh (4.1 KB)
This is a definition breaking difference between the two operating systems.
Hi Leo,
are there any other steps to repeat this? I’m seeing 0-34 on opening your file in both platforms.
Please run systeminfo in the Rhino command line and post the result. Thanks
I should have also included the Rhino file for unit tolerances:
Curve Offset Point Order.3dm (56.7 KB)
And the system info:
SystemInfo.txt (4.0 KB)
Hi Leo -
Thanks → RH-84394 Grasshopper: Curve Offset Is Platform-Specific
-wim
Thanks for making a YouTrack Wim. 
Can you explain how is this a breaking difference? I have rooted out where the difference happens for this example but it doesn’t seem like the same issue as you’re reporting.
This curve doesn’t explode at all. It and its offset is a single segment curve. If there’s an example where the number of segments vary between platforms I’d like to see that.
Thanks for looking into this Joshua.
In my working grasshopper file I have a polycurve which explodes but the indices of the segments differ between the two platforms. The number of segments does not differ.
Here is a screenshot of the platform workaround required to overcome this bug: separate index numbers for each operating system. I’m sorry I can’t share the actual definition.
Can you reproduce with the Rhino commands? Or a different very simple Grasshopper definition with just the problematic the curve? I can’t dig into this from a picture
Is it not clear that any downstream components which reference these vertices by index will break if the definition is run on a different platform from the one it was created on?
I’m having difficulty understanding why there would be any doubt about the need for both platforms to generate the same result.
This does not sound the same as this:
If I work on the second one which you attached an example for it doesn’t seem like it’d help resolve the segment problem which may or may not be the actual problem. I’d really need to see the exact problematic curve and a simple definition or script to reproduce it since you cannot share the actual definition.
I’m afraid that it’s not practical for me to put more time into this issue beyond the significant time already spent.
The original Grasshopper file is immense and takes several minutes to produce a result which makes the testing process involving re-booting into each OS painfully slow.
This week I’m migrating to an Apple-silicon Mac and retiring this current Intel one so I won’t be able to use Bootcamp anymore.
