INQUIRE: Bounding box control points behavior

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.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.

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.

It looks like you just need something like this:
image

1 Like

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.

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++){

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.

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?).

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

From the original code in your C# component:

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.

This is the final code with the changes from above:

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

(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.

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

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

Strange… :thinking: Wonder why?

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

-Kevin

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?

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:

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

-Kevin

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

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

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

Wow! Of course, that Parallel.For() loop helps too, eh? Two of them!

The Nurbs curves look very weird though, better to use the DeBrep ‘E’ (Edges). Or PLine (Polyline) with inverted ‘C’ (Closed) input.

P.S. This ‘out worldXY_bbox’ is interesting too?

BoundingBox pln_bbox = crv[i].GetBoundingBox(planes[j], out worldXY_bbox);

As we discussed in PMs, that returns actual box geometry, though the distinction is still fuzzy for me.

https://developer.rhino3d.com/api/RhinoCommon/html/M_Rhino_Geometry_GeometryBase_GetBoundingBox_1.htm

Yeah, it is still not fully clear to me too…
It feels like a BoundingBox object is only a domain/interval triplet, even its vertexes are coordinates relative to the used plane.
Instead, the Box object is an actual geometry, oriented and placed in space.
Can anyone light things up?

Thanks a lot for yet another solution to the problem.
I used this on my original work file to check on the speed and the C# script reports 5.1s for 339 elements. This might just my computer or the fact that I am running multiple times the script:

339 elements = 5.1s
45 elements = 862 ms
52 elements = 438 ms
67 elements = 611 ms

Meanwhile @maje90 C# Script v5 runs at 342 ms for 339 elements. Well he basically got rid of the 594 ms used to transform all curves into surfaces.

Once I am done with all this I am so going to explore the software way more.

1 Like