Grasshopper

algorithmic modeling for Rhino

Hello!

i am trying to make an intersection line between 2 different Geodesic Domes with 2 different radius factors, without "braking" any module.

-i used the GGgeoDome on two spheres (trying to make the triangles as similar as possible)

-made a boundary surface of them

-and then took the list of intersection points between each dome (curves) with the the surface of the other.

- then on each GeoDome i found the closest points to the points found in the intersection

Now i have two lists of points and i am planning to make a polyline out of each of them.

is there a way to merge these points into one (beautiful) polyline that would define the intersections, and that would stay on the edges of the module without going through the surfaces??

or maybe easier- to just make the 2 Polylines (that i am going to make) as close as possible to each other.

 

would be v e r y helpful!

thanks

Views: 1746

Attachments:

Replies to This Discussion

Perhaps you meant to say 'without "breaking" any module' (not "braking")?

I don't have ggGeoDome installed so can't use your code.  Maybe you can internalize the two dome surface outputs so we can focus only on their intersection?

yes, breaking, sorry for my English, 

I baked the surfaces and piped the lines that go through the edges. 

is that what you meant?

thanks

Attachments:

Well, this is interesting!  I'm not interested in pipes or the intersection you found, only the surfaces.  By "internalize", I meant to use the "Internalize Data" feature for geometry imported from Rhino so the Rhino file isn't needed.

But baking portions of the two domes on separate layers allowed me to get what I wanted.

  1. I right-clicked on 'Layer 02', clicked 'Select Objects', then 'Join' to create a polysurface.
  2. Did the same thing for 'Layer 03'.
  3. Then I assigned them to the two 'Brep' params in my code and used 'Internalize Data' so they are saved in the attached GH file.

Didn't change anything in my code and got some pretty good results, though two issues are evident:

  • My code split the intersecting surfaces as expected but did nothing to eliminate the unwanted surfaces that aren't touched by the intersection.
  • One piece of each Brep has a clean edge at the intersection but they are both on the same side of the divide instead of one on each side.

For clarity, the following shows copies of the two "good" pieces dragged off to the right:

I'm not quite sure what's going on or how to fix this...  Might need to sleep on it.  :)

OH!  Wait...  The second problem is fixed by choosing the other one of two surfaces resulting from the split - see red arrow below:

Result:

Now to eliminate the unwanted surfaces...  Oh!  That's simple too.  We can sort the output of the two Brep 'Join' components by area and choose the largest one.  In this case, it happens to be the first one in the list in both cases, though that might not always be true.  In fact, I suppose keeping the one with the largest area might not always be true either?

BINGO!!!

P.S.  Again, no Rhino file needed.

Attachments:

thank you so much for your answers, i think i meant something a bit different.

my goal is to find an optimal rearrangement of the parameters of the 2 spheres: the location / the size / the panels size, in order for them to find one common polyline

resulting: having panels on both spheres rearranged according to a common edge

Since the geodesic spheres are projections onto true spheres, might it make more sense to look at the circular intersection of the two enveloping spheres and then at the intersections of each of the geodesic spheres with that circle?

Intersection between two spheres is relatively simple because it's only two surfaces.  Geodesic domes each consist of many surfaces joined as a polysurface (Brep) so splitting is more complicated.  I would suggest that what you want to do is very similar to two cubes intersecting at arbitrary angles - like this:

If you're lucky, you could replace the two breps in this code with your two geodesic domes and it might work?  But... this was harder than I expected, the code isn't very elegant, and I had to move one of the cubes (the yellow one) up slightly to prevent a situation where one of its surfaces was split into three pieces instead of two.  You might find similar problems with domes.

Attachments:

Yes it make sense,

do you have any suggestions of how to take that circular intersection and create the panels accordingly?

because the Geodomes are made with the ggGeoDome feature can't think of a way to do that

thank you :)

Looking at your other reply, if you want to have the two geodesic spheres share a common circle then it seems to me you need them to be of the same radius AND frequency, otherwise, the edges will never line up properly.

OK i see, 

if i still need them to have different radius, even if the edges will never line up on the exact same line, is there a way to make optimization so they will get the closest as possible? 

let's say if i give both spheres a minimum an maximum radius parameters , and allow them to move a  maximum distance. can i optimize these parameters so the gap will have the  smallest area?

RSS

About

Translate

Search

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service