Is grasshopper the right tool for this and if so where should I start?

Replies to This Discussion

Permalink Reply by Joseph Oster on July 10, 2016 at 4:58pm

Yes, GH is a good tool for this but...  Simply designating a percentage for each of the four sides doesn't define the polygon shapes.  Polygons on the left and back sides touch all four edges while polygons on the front and right sides touch only three edges.  The back and left sides each have one polygon vertex that is not on one of the edges, the right side has three vertices not on edges.

It wouldn't be too difficult to create a GH model that would allow you to set all these vertices manually and show you the percentage of each side covered by the resulting polygons.  But there are surely many possibilities for achieving the percentages you want - an iterative process without a unique solution.

Permalink Reply by Dustin Blalock on July 10, 2016 at 6:41pm

Thanks Joseph!  I was thinking by creating a set of rules for the area of each surface of the cube while requiring a minimum shared edge length you could test a variety of forms that could fit within the cubes boundary. 

So the parameters I've thought of so far would be:

1) a minimum edge distance for all sides of the cube's surfaces

2) a percentage coverage

I would rather not set the vertices manually because that project is less about creating a specific form and more about testing the potential for this idea through multiple varieties.What I'm predicting that may happen is that by changing the area of the surface you end with a surface that may have 8 plus vertices.

The idea seems very simple to me but creating a definition seems very complex. Thanks for the help.

Permalink Reply by Joseph Oster on July 10, 2016 at 10:38pm

This forum server has become so unresponsive for me it's nearly impossible to use.  Lost and duplicate posts, endless waiting for page loads.  Ugh.

I immediately tried to edit my previous post with a bit of sudden insight but the whole paragraph was lost.  So I've been writing code instead.

The insight was that by defining the front and back polygons first, many points for the left and right polygons are determined too.  I placed my points manually using 'MD Sliders', treating each of the four sides as an X/Y surface (X=horizontal, Y=vertical).  Zero to one for both values so the cube can be sized independently.  Percentages of surface area are calculated for each polygon/face.

Capping the top and bottom was more troublesome than the sides!  There must be a plugin that will do that, given the top and bottom edge curves of the joined polygon sides?

I'm going to sleep on the code before posting it but here are the results:

Permalink Reply by Joseph Oster on July 11, 2016 at 7:34am

WARNING!!!  These links are nothing but spam.

Permalink Reply by David Rutten on July 11, 2016 at 8:17am

Thanks Joseph, I banned them.

Permalink Reply by Joseph Oster on July 11, 2016 at 11:23am

Would you mind giving us some background on this project?  Is it for a class?  Who created the 3D model shown in your .pdf file?  What are your target percentages for each side of the cube?

The idea seems very simple to me but creating a definition seems very complex.

So far, your description of any algorithm sounds naive and simplistic, like you've never done any programming?  Even with constraints such as those imposed by some manually defined vertices, there would seem to be an infinite number of solutions.

The GH model I've created so far duplicates the four polygons in your .pdf with specific controls for each point/vertex.  Adding or removing points requires re-wiring of the GH code.  It's not exactly simple and contains no automated "solver" to re-arrange points.

I see a way forward like this:

• Manually arrange points for all four polygons as I have done, noting that front and back faces predetermine some of the points used by the left and right polygons.
• Pick ONE POINT/VERTEX each on the front and back polygons to be moved by a "solver" to achieve a target percentage, perhaps moving in only one direction (horizontal or vertical, not both).
• Then pick ONE POINT/VERTEX each on the left and right polygons for a "solver" to move, avoiding the fixed points defined by front and back; in fact, my GH model has no manual controls for those points.  This point on the left and right polygons might be one of the "floater" points (one on the left, four on the right) or an edge point (three on the left, two on the right).

Front and back polygons must be defined and "solved" first, before solving the left and right.

My method for creating top and bottom surfaces consists of manually edited sequences of point numbers (indexes) to create triangular sections.  It adapts to polygon changes but I'm curious if there is another way to do that?

The attached Rhino file has the top and bottom edges of the joined polygons on 'Layer 03', in blue.  I used 'Disc (Discontinuity)' to get the points I used to make the triangles:

The top and bottom surfaces are on 'Layer 04', in yellow:

Can anyone suggest a method for creating the yellow surfaces from the blue lines without manually editing point sequence lists?

Permalink Reply by Joseph Oster on July 11, 2016 at 1:32pm

Trying for hours to load a GH forum page is a mind killer...  Until Ning.com and/or my ISP (mediacom) resolve their recurrent DNS issues for my northern California location, I can't use this forum effectively.  Or any Ning.com site, for that matter.  Past efforts to work with both companies' support techs (Ping, TraceRt, etc.) showed the problem clearly but it still comes and goes, a year later.  Too bad for me.

In Rhino, there is a command "Mesh | From Closed Polyline" that does exactly what I want using the blue edge lines posted above in the Rhino file.  Unfortunately, I haven't found a way to convert that mesh or its edges into a Brep, which is needed to make the whole thing a "solid" (Closed Brep).

Permalink Reply by Laurent DELRIEU on July 11, 2016 at 3:35pm

My 2 cents on this problem. I begin by subdividing each bottom/top edges by an integer, I make a random height calculation. I get 2 polylines, joined y loft, the top and bottom are just meshed by Delaunay triangulation. This is not/bad working if there are vertical parts on polylines. But I hope this could help a bit. 

Attachments:

• test_cube_axe_cut.gh, 20 KB

Permalink Reply by Joseph Oster on July 11, 2016 at 5:11pm

Thanks Laurent, but I don't have the 'MeshEdit' plug-in. Looks like you didn't use my edge curves? Did a lot of work to create your own instead? And your result appears to be meshes, not Breps? Not what I'm looking for but thanks anyway.

Permalink Reply by Dustin Blalock on July 11, 2016 at 8:37pm

Joseph, thanks for taking the time to help. This project is just a personal project. Post graduate life is pretty boring and this just keeps my mind busy. I am probably being pretty naive and the project does need some development and refinement but I just felt Like I needed to get started somewhere.

I'm going to digest everything and learn some more and I'll reply back with what happens.

Permalink Reply by Joseph Oster on July 11, 2016 at 5:07pm

I found a way to convert a mesh to a Brep surface, in the orange group (attached).

No luck yet in replicating the Rhino "Mesh | From Closed Polyline" feature in GH.  So must bake the top and bottom 'Edge Curves' from the joined polygons, use the feature in Rhino, then bring them back into GH (internalized in attached GH file).

But there is a little problem with that mesh, illustrated in the red "Face Problem" group.  Two yellow faces are "out" instead of "in", so that one of the faces is co-planar with the polygon on that side, which isn't what we want.

The 'Del (Delaunay Mesh)' component using discontinuities in the two 'Edge Curves' is as close as I've come to a purely GH solution but the results are not satisfactory.

Attachments:

• polygon_cube_2016July11b.gh, 22 KB