Sweep bugging?


I tried to upload model to shapediver with profiles to and make closed loft from them, but in GH it works flawlessly, but in shapediver it just dont work, it lofts profiles in random order, nothing solved it so I used sweep2 and it sometimes does this:

In GH it always works without a hitch. Is this a common thing with Shapediver ? Or do I have to work differently in GH to be able to use it in Shapediver ?

I checked orientation of curves, changed seams, used swp1/2 and loft, nothing works as same as in GH.

It looks like the order of the lofted curves gets lost at a point. You might be using a component that outputs a list in unpredictable order and assuming the order from what you get locally, although it might be different on different machines and/or versions of Rhino. Check in particular all split/explode components and merge/join components to make sure the order of curves is not lost. I can help if you send a minimal version of the definition for debugging.

I cut off most of non-interesting parts.
gh_minimal_prev.gh (28.2 KB)

As I suspected, the issue is likely the result of an unsafe use of the “Join Curves” component. As a matter of fact, when I open your file on my local Rhino, I see a result very similar to your screenshots above. The culprits are the following components:

First of all, the order in which the list of output curves will be arranged depends directly on the order in which you connected the two input lists. Instead of connecting several input lists to the same knob, I strongly suggest to use “Merge” components which ensure the order in which merged lists will be sorted:

In your case, however, this will not do the trick. “Join Curves” will try to match the list of input curves in the best way possible, resulting in the least possible amount of resulting curves. I honestly do not know which algorithm is used to do so, and I would not assume that the resulting list of joined curves has a predictable order with respect to the input. In fewer words, this is risky.

Now you could try to implement some logic to the output list to make sure it is ordered according to proximity, in order to sanitize the input of your “Sweep” component. However, in this case you have a better option! You already know that those input curves will match two by two, and you have two lists that are ordered identically: the ideal solution is to graft both input lists before sending them to the “Join Curves” component, and to flatten back the output:


Now to be clear, that only works because both input lists are ordered the same. Also make sure that grafting results in trees with identical structures, or at list the same number of ordered branches.

The grafting operation will result in this fundamental change: instead of sending one list of 2*N curves, you are sending N lists of 2 curves. This has two advantages:

  1. The branches of the tree are ordered according to both input lists, which is the order you expect in your Sweep component. You can then just flatten the output tree to get the exact list you need.
  2. Instead of comparing 2N curves with each other ( O(N²) comparisons), you are comparing the corresponding indices of two lists of N elements (O(N) comparisons). From quadratic to linear complexity, just with a graft!

Here is your minimal example attached with said change.

FIXED_gh_minimal_prev.gh (35.4 KB)

Now that seems to work fine on ShapeDiver, but please do apply the same to your full example and let me know if the issue is solved. There might be another similar unsafe operation somewhere else that I overlooked.

Thanks for this structured explanation it works in ShapeDiver perfectly. I tought that order of curves comes from order of points from which they were created. But if I want to fillet those joind curves as on screenshot below, I try to keep the same list of curve and then use fillet. But I got same result as before. I dont know if this is a good way to keep the same order, at this point I dont even know if I am using fillet correctly.

I am not sure I understand your current problem. The “Fillet” component operates on single curve items, so whether you use it on a list or a tree, it will output an unchanged data structure with filleted curves. I don’t see what could be wrong with the screenshot you took above (although I would personally flatten the curves before filleting, but again that does not change anything, as long as you send a flattened list to the sweet component).

If you still have an issue, maybe you can send an updated minimal file?

I tought too fillet shouldn’t change anything, but so did before with joining curves. I tried to flatten curves befor and after to see if it makes any difference.
It resulted again in this shape.

gh_minimal_fillet_prev.gh (29.2 KB)

One of the connections was wrong in this file:

With this fix, it seems that the file uploads without issues, please let me know if you can confirm.

FIXED_gh_minimal_fillet_prev.gh (32.1 KB)

I knew about that but forgot to fix it for the minimal file. This was not the issue for the weird shape.

So you are saying that when you upload the last file I attached in my previous message, you still experience the issue? I have uploaded it 3 times just now and always get the correct result.

Yes. I used the same file.
You can see if you change the parameters of size and segments, you can get various outputs. Those sweeps mostly works properly but you can find few which are deformed or even is missing.

Thank you for the precision, now I can reproduce the issue. I can also reproduce it in Rhino 6, which is the version of Rhino that is running on our shared system:

I tried to find an obvious cause but the only explanation I have is that with the fillet radius, the segment curves get quite far from the rail curves and the sweeping operation fails. It is possible that this algorithm is more robust in Rhino 7, I don’t really know.

In the short term, you could either work in Rhino 6 for the time being and make sure your definition doesn’t break there. Alternatively, your account could be transferred to Rhino 7 servers with a Designer or Business account. In the future, all users will have access to Rhino 7 but there is not clear date for the switch yet.

I moved sweep rails inwards on profiles and now it works, so far I didnt found any set of parameters to replicate any bad shape.

Thank you for your time and explanation, it was very helpful.

1 Like