INQUIRE: Bounding box control points behavior

Grasshopper
1

Hello again forum,

While working I came upon the following bounding box behavior:

image
image1469Ɨ796 6.64 KB

As you can see in the picture the control points in the lower left box created via Bounding Box does not follow the same pattern as the rest of the boxes. Yes, the order is the same (counterclockwise), but the starting point is not.

During my course at the university we ran into a similar situation and though we tried to fix it but were unable to. Is there a logical explanation for this or is it just a software issue?

210729 - BBX_issue.gh (10.8 KB)

2

Hah! Software issues usually have logical explanations. You didnā€™t internalize your curves but a wild guess would be that one of the curves is flipped, going the opposite direction from the others?

You can use Flip Curve with a guide curve (a circle will do) to make them all the same.

3

Shoot! I forgot to internalized again. Well I tried Flip Curve with no positive results you and some others suggested here:

210729 - BBX_internalized.gh (202.6 KB)

4

OK, I really must read these things more carefully. Flipping curves only affects their direction, not their starting point. I would have applied Flip Curve at the very beginning instead of later, as you did, after BBox. CAUTION: Control Points gives you five points by duplicating the start/end point whereas Discontinuity gives you four points, no duplicates.

Looking very carefully now, I see one plane from your C# component that has its X direction wrong:

BBox_2021_Jul29a
BBox_2021_Jul29a1131Ɨ615 46.9 KB

BBox_2021_Jul29a.gh (207.4 KB)

I tried many tricks to replace your C# component but failed because these curves have too many fragments and discontinuity points.

5

I appreciate the effort Joseph. Also thanks for explaining the difference between Discontinuity and Control Points.

Well in the end if I do not manage I thought I could just run the whole definition in the blocks that are working funky. Is not an elegant solution but works for the time being.

Thanks again.

6

It looks like you just need something like this:
image

1 Like
7

Thanks for the solution @Adam_M . This is actually a Script that was given to us by my university as part of our classes. Since a lot of things are still in development they might have some issues but this just solved, at least my problem.

thank you.

8

Does this change the start point of the resulting curve?

I wondered about that loop. Why this?

for(int j = 1; j < 361 ; j++){

instead of this?

for(int j = 0; j < 360 ; j++){

Or for that matter, only 180 or 90? Both appear to give the same results for these curves.

for(int j = 0; j < 90 ; j++){

9

It looks like it orders the bounding box points counterclockwise from the upper leftmost point, based on the orientation of the plane.

I thought the same with regards to the j value.

10

The start points were sometimes mixed up when I checked from 0 to 90 degrees but got fixed when I changed to -45 to +45 degrees.

Doing that in the C# code would make it substantially faster (~4 times faster?).

11

Iā€™m a bit late posting here - been busy the past couple of days.

From the original code in your C# component:

001
0011434Ɨ697 89.4 KB

Changing the for loop in line #6 to start at 0 instead of 1 fixes the problem:
for (int j = 0; j < 361 ; j++){

Since you are dividing the j value by 4 in line #8 and line #19 the code is actually looping from 0 to 90 degrees in 0.25 degree steps. The intent of the code could be made more clearly understandable by changing line #6 to:
for (double j = 0; j < 90 ; j+=0.25){

This will loop from 0 to 89.75 degrees in 0.25 degree steps. To accommodate this change, you need to remove the divisions by 4 from lines #8 & #19. (There is no need to check the area at 90 degrees as it is exactly the same as the area at 0 degrees.)

There is also no need to create Point3D objects in lines #10 & #11. The BoundingBox object provides a Diagonal property provides these values in a vector.

002
0022010Ɨ118 24.2 KB

This is the final code with the changes from above:

003
0031468Ɨ657 81.4 KB

210729 - BBX_internalized_re_001.gh (217.1 KB)

Iā€™m suprised how much faster this C# script is compared to doing this with native grasshopper components.

I did some comparisons using the Anemone loop from the script linked in the post above from @Joseph_Oster. Just comparing the time from the Fast Loop End component to the C# Script component the script is ~23.5 times faster when doing 360 loops (0 to 89.75 degrees, 0.25 degree steps). I may look into this further when I have time.

-Kevin

2 Likes
12

(approx. 1 minute)

My Profiler says the C# loop is four times faster than the Anemone loop (both doing 360 iterations).
C# is 2.5 secs. vs. Anemone at 9.9 secs.

The C# could be changed to this: (-45 to 45 degrees)

for (double j = -45; j < 45; j += 0.25){

Also, I wonder if the C# could be faster if all the rotated planes are created just once, outside the ā€˜forā€™ loops, as I did in the orange group? That code is executed only once. They would be accessed by index.

13

Strangeā€¦

When I was running this script earlier today Iā€™m certain that the Anemone Loop was reporting ~57.5 seconds, I ran it several times to compare results.

Now when I run it, the C# script is reporting 2.2 seconds and the Anemone Loop is reporting 17.7 seconds. I did close and re-start Rhino since I was looking at this before but the script hasnā€™t changed.

Iā€™ve never done any C# coding before so I was trying to be careful as I was working through this. I do have a little experience with plain C and C++ but havenā€™t used it much in the past 20 years.

-Kevin

14

Thatā€™s twice the time I am seeing (big difference!), even though the C# benchmark is nearly the same.

Strangeā€¦ :thinking: Wonder why?

15

Donā€™t know, but the difference might have something to do with the fact that Iā€™m on a Mac.

-Kevin

16

Iā€™m running R6 on Windows 10.

|Processor|Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz   2.80 GHz|
|Installed RAM|16.0 GB|
|System type|64-bit operating system, x64-based processor|

Also donā€™t have this:

missing

Might be interesting to benchmark other examples of Anemone loops with similar run times?

17

According to this, gradient and transparent hatches are new in Rhino 7.

I guess the component is only available in grasshopper on Rhino 7?

These are the only 3rd-party components reported by Pancake ā†’ Portability Report

3rd-party components
    Fast Loop End: From third-party: Anemone
    Fast Loop Start: From third-party: Anemone

This is the display with gradient hatches from the OP file:

004
0041087Ɨ919 83.5 KB

You can quickly see that one of the surfaces is oriented differently than the rest.

-Kevin

18

Updated Rhino on my PC and loaded Anemone (Iā€™m on the Mac most of the time, the wife & kids use the PC).

Looks more similar to what youā€™re seeing: the Anemone loop takes 5.5 seconds and the C# script takes 1.8 seconds.

-Kevin

1 Like
19

I havenā€™t updated Pancake for a while to include those latest components. Will update.

20

Hi all!
A small fix that we can do is to let curve enters the c# script.
There was like 400ms wasted to convert the curves to brep because of the input type hint.

Done thatā€¦ but I wasnā€™t able to measure the difference in execution.

Currently the c# does the job in 20ms on my pcā€¦
Maybe the BBox calculation is much heavier if done on surfaces/brep objects.

See the bottom/last script.
BBoxV5_Aug1a.gh (215.8 KB)

1 Like