I have loaded an old Grasshopper experiment that I did with Rhino 7 in Rhino 8. Now one conversion from a Bounding Box to a Surface fails - and I don’t understand why. There are various other conversions where I do exactly the same and these work. Have unfortunately already uninstalled Rhino 7 but I’m pretty sure it worked there.
Any ideas? (To get to the place look for the “Defect is in this tangent loft group” note and inside the group for the “I have no clue why…” note beside the red srf box with the error message.)
Tested with Grasshopper 2023-10-31 in Rhino 8 on Windows 11.
polymoe_body_bounding_box_to_surface_conversion_error.gh (77.4 KB)
I agree, because your curve is planar (A), I would expect the result of the bounding box (B) to be a Flat Box, which is the translated to a Surface
Here I have used Bounding Rectangle that comes with Pufferfish plugin to do something similar
I think this is a weird thing in Rhino 8 (which I also have started using just tonight…)
this is the very same file opened in v7, and indeed shows a Flat Box, which doesn’t break the script and gets translated into a surface succesfully:
2 Likes
Thanks for the workaround and for verifying with Rhino 7! So seems to really be a new oddity introduced with Rhino 8.
The odd thing is that I do exactly the same thing three additional times in the same group - and there it works. (Also there is another linked copy of the group in the graph where all four surface conversions work.)
So something seems wrong with that particular sketch? Funny thing is - these sketches are all generated by clones of the same Python script, just with different scalings.
Next problem: The Sweep is now also wrong. When applying @inno 's workaround (and changing the indices as BRec seems to count differently) the rails are generated as expected again. But the sweep now associates the points in the wrong order.
Here just the two sketches and the two rail curves (the sketches are generated by the same Python script, thus same number of points drawn in the same order, just the distances are different):
And here the sweep result:
In Rhino 7 the association was still correct.
Here the updated script with the workaround (requires the Pufferfish extension now):
polymoe_body_bounding_box_to_surface_conversion_error_sweep_also_wrong.gh (79.1 KB)
P.S.: Can a mod please rename the thread to “Bounding box to surface and sweep2 regressions in Rhino 8” - don’t seem to have rights to edit the name.
^^Thanks!
P.P.S.: There is a second instance of the “tangent_loft” cluster in that graph. That one works without problems - also regarding the sweep - so you can see how the component is supposed to work. (The second copy of tangent_loft gets again four variants of the sketch from the same Python script with different parameters. The difference between those two cases is non-obvious to me. And in Rhino 7 both worked.)
as weird as it might sound, rescaling the curve produces a Flat Box for some scaling factors… so at this point I don’t think it’s necessarily a Rhino-8 thing anymore, but might be a tolerance related issue?
Hm, could it be that calculation precision was reduced in Rhino 8 in order to accelerate calculations?
I rotate the sketch (in the Python script). Technically it’s a 2D sketch, but rotating in 3D could produce non-planar points by rounding mistakes?
The original issue is caused by Rhino 8 thinking the Y domain of the bounding box isn’t actually flat (it sees Domain Start ≠ Domain End). Setting the domain bounds to a common value allows the Surface to work.
A bug, obviously.
1 Like
Hi @Ferdinand ,
Thanks for the reports. I opened the first GH file you provided and see this…
I do not find the spot which other posters are referencing here, did you replace the file? Is there a simple example that shows the regression instead? I am happy to file it as a bug but the developers will need the simplest possible reproducible example. My guess is that a component may have changed slightly to fix something else.
Please also post separate issues in separate posts to make sure nothing gets missed or confused.
This is what I see for your second GH file regarding a sweep issue… It also looks like it used Pufferfish from an initial error message as I don’t have that add-on installed.
This appears to be the same GH document but again I am not sure where to look. There’s a lot going on and a simple example is much easier to get developer attention on if you have it.
Thanks for any extra info, myself or another tech can get the issues filed once we have a clear and reproducible file to provide to the developers.
From memory, it was the group by the lowermost yellow panel.
1 Like
Hi, thanks for looking into this!
Yes, when you double click the gh file in the OP it should already be zoomed in to the relevant cluster:
When you double click it, the problematic conversion is highlighted with a text label:
The second file that I posted replaces the problematic boundingbox->surface conversion with a BoundingRect from the Pufferfish extension - so that has to be installed. The problematic sweep is in the same cluster as in the previous file (just with the previous problem fixed as described):
Sorry for posting the large files, but I thought it would be helpful to see that the same construct works without problems on several other places in this graph, so the two cases can be compared and might give a hint at what is going on. The sweep problem immediately popped up after applying the proposed workaround for problem 1, so I just continued posting - sorry, will make separate threads in the future.
Here two files for both problems where I have removed all unnecessary stuff.
I just left both usages of the cluster in - one that works without problems and the second that shows the described conversion problem in file 1 and sweep problem in file 2:
bounding box to surface conversion problem:
bounding_box_to_surface_conversion_error.gh (55.2 KB)
sweep point association problem:
wrong_point_associations_in_sweep2.gh (55.5 KB)
Hi @Ferdinand ,
The flat bounding box issue is the same in GH on v7 as it is in v8 here so I don’t think this is a regression. I found two solutions that both work here in both versions as well. You can either bake out the curve and then reference it again but this isn’t ideal! The other solution I found was to flip the direction of the curve. For some reason this gets us a flat box. I’ve filed this as https://mcneel.myjetbrains.com/youtrack/issue/RH-78284 for future reference. My hunch is that there is something in the script that created the curve that is involved here.
Regarding your second Sweep issue, I’m having trouble getting a simple reproducible example. I can see that there is a difference in the alignment after I get the bounding box working again with the same flip method I used above. I can’t tell where things get misaligned though after that as there is a lot of merging and the order of those inputs will change the order of the points etc. I’ll try again later to get a simple sweep2 GH example that shows a difference for a better bug report but in the meantime I’ve filed this as https://mcneel.myjetbrains.com/youtrack/issue/RH-78288
2 Likes
Hi @BrianJ, thanks for following up!
Have downloaded Rhino 7 again on both Mac and Windows and both problems don’t appear with Rhino 7 for me.
Here a screenshot of problem 1 (non-planar bounding box) on Windows (left: Rhino 7, right Rhino 8):
Interestingly for problem 1 I don’t get that with Rhino 8 on Mac (left: Rhino7, right Rhino 8):
Problem 2 (sweep order) worked as expected on Rhino 7 and doesn’t work on Rhino 8 on both Windows and Mac. Here a screenshot from Mac (left: Rhino 7, right Rhino 8)
Thanks @DavidRutten for the quick fix for problem 1! Question: Does that mean that the Windows version of Rhino 8 has somehow lower precision than Rhino 7 or the Mac version of Rhino 8 (If the non-planarity of the bounding box is the result of a rounding artefact)?
RH-78284 is fixed in Rhino 8 Service Release 2 Release Candidate
1 Like
@brian Regarding https://mcneel.myjetbrains.com/youtrack/issue/RH-78288, the TestableDate indicates “not testable” - is there something I still could provide from my side? Just retested the file, the problem is still existing in the current Rhino 8.3 version.
Hi Ferdinand -
Yes, RH-78288 is still “Open”, and currently on the “8.x” list.
-wim
1 Like
Still open, still relevant.