me logic produced by running the 2-d voronoi component.
From a given set of polylines we can extract the centers and this can drive both the voronoi component as well as provide the XYZ drill points for the cnc. The definition has a variety of different options. You need Lunchbox, Weaverbird, and Starling. I can't tell you how amazing these 3 tools are from a design perspective. They are extremely powerful so if you don't have these you must install them asap. You can get the tools at http://www.food4rhino.com/
This definition works by first choosing a grid type, next you choose voronoi type, and subdivision type. From the voronoi type list you can choose basic (just grid), truncation (uses truncation calculated via the image sampler), truncation dual (uses the dual of the truncated image based grid), and subdivision (takes the basic grid type and uses different subdivision shcemes). Each of these provide different patterns of polylines from which we can extract our drilling points. I am rather proud of this definition since the overall idea is one which is so simple it's easy to overlook - the idea that drilling with a ball end mill makes voronoi plots. Now when you combine that with all of these amazing tools it can go off right quick. The nice thing is the paatern you see on screen is the pattern that gets made by drilling wysiwyg cnc patterns.
VORONIO_DRILLing.gh
Here are some on screen patterns in process in the following order truncation, basic, subdivision:
here is a video moving over a machined example:
…
e chosen to dive into Grasshopper. I’m about 6 months in. If some of my comments are completely off, please take that to mean that a feature is too inaccessible to a newish user rather that it’s just missing, as I may have stated.
One of my primary pain points is this. Things that can be done in other programs are invariably easier in other programs. This is a big enough issue that I doubt there’s an easy solution that an armchair qb like myself can offer up.
The interface:
I’ve used a lot of 3D programs. I’ve never encountered one as difficult as grasshopper. What in other programs is a dialog box, is 8 or 10 components strung together in grasshopper. The wisdom for this I often hear among the grasshopper community is that this allows for parametric design. Yet PTC (Parametric Technology Corp.) has been doing parametric design software since 1985 and has a far cleaner and more intuitive interface. So does SolidWorks, Inventor, CATIA, NX, and a bunch of others.
In the early 2000's, when parametric design software was all the rage, McNeel stated quite strongly the Rhino would remain a direct modeler and would not become a parametric modeler. Trends come. Trends go. And the industry has been swinging back to direct modeling. So McNeel’s decision was probably ok. But I have to wonder if part of McNeel’s reluctance to incorporate some of the tried and proven ideas of other parametric packages doesn't have roots in their earlier declaration to not incorporate parametrics.
A Visual Programming Language:
I read a lot about the awesomeness and flexibility of Grasshopper being a visual programming language. Let’s be clear, this is DOS era speak. I believe GH should continue to have the ability to be extended and massaged with code, as most design programs do. But as long as this is front and center, GH will remain out of reach to the average designer.
Context sensitivity:
There is no reason a program in 2014 should allow me to make decisions that will not work. For example, if a component input is in all cases incompatible with another component's output, I shouldn't be able to connect them.
Sliders:
I hate sliders. I understand them, but I hate ‘em. I think they should be optional. Ya, I know I can r-click on the N of a component and set the integer. It’s a pain, and it gives no feedback. The “N” should turn into the number if set. AAAnd, sliders should be context sensitive. I like that the name of a slider changes when I plug it into something. But if I plug it into something that'll only accept a 1, a 2, or a 3, that slider should self set accordingly. I shouldn't be able to plug in a “50” and have everything after turn red.
Components:
Give components a little “+” or a drawer on the bottom or something that by clicking, opens the component into something akin to a dialog box. This should give access to all of the variables in the component. I shouldn't have to r-click on each thing on a component to do all of the settings.
And this item I’m guessing on. I’m not yet good enough at GH to know if this may have adverse effects. Reverse, Flatten, Graft, etc.; could these be context sensitive? Could some of these items disappear if they are contextually inappropriate or gray out if they're unlikely?
Tighter integration with Rhino:
I'm not entirely certain what this would look like. Currently my work flow entails baking, making a few Rhino edits, and reinserting into GH. I question the whole baking thing, btw. Why isn't it just live geometry? That’s how other parametric apps work. Maybe add more Rhino functionality to GH. GH has no 3D offset. I have to bake, offsetserf, and reinsert the geometry. I’m currently looking at the “Geometry Cache” and “Geometry Pipeline” components to see if they help. But I haven't been able to figure it out. Which leads me to:
Update all of the documentation:
I'm guessing this is an in process thing and you're working toward rolling GH from 0.9.00075 to 1.0. GH was being updated nearly weekly earlier this year. Then it suddenly stopped. If we're talking weeks before a full release, so be it. But if we're looking at something longer, a documentation update would help a lot. Geometry Cache and Geometry Pipeline’s help still read “This is the autogenerated help topic for this object. Developers: override the HtmlHelp_Source() function in the base class to provide custom help.” This does not help. And the Grasshopper Primer 2nd Ed. was written for GH 0.60007.
Grasshopper is fundamentally a 2D program:
I know you'll disagree completely, but I'm sticking to this. How else could an omission like offsetsurf happen? Pretty much every 3D program in existence has this. I’m sure I can probably figure out how to deconstruct the breps, join the curves, loft, trim, and so forth. But does writing an algorithm to do what all other 3D programs do with a dialog box seem reasonable? I'm sure if you go command by command you'll find a ton on such things.
If you look at the vast majority of things done in GH, you'll note that they're mostly either flat or a fundamentally 2D pattern on a warped surface.
I've been working on a part that is a 3D voronoi trimmed to a 3D model. I've been trying to turn the trimmed voronoi into legitimate geometry for over a month without success.
http://www.grasshopper3d.com/profiles/blogs/question-voronoi-3d-continued
I’ve researched it enough to have found many others have had the exact same problem and have not solved it. It’s really not that conceptually difficult. But GH lacks the tools.
Make screen organization easier:
I have a touch of OCD, and I like my GH layout to flow neatly. Allow input/output nodes to be re-ordered. This will allow a reduction in crossed wires. Make the wire positions a bit more editable. I sometimes use a geometry component as a wire anchor to clean things up. Being able to grab a wire and pull it out of the way would be kinda nice.
I think GH has some awesome abilities. I also think accessing those abilities could be significantly easier.
~p…
looked at autodesk simulation cfd 2015 and was optimistic because it had an export plugin from revit, which i use anyway for material takeoffs and etc, but found that it did not take solar radiation into account. This was a downer because I have heard that solar radiation could effect indoor airflow - convection - as much as 50 percent at a time.
Then I searched again and found that Hyperworks, a software by altair technology can be coupled with a radiation software. So I went through the trouble of obtaining an educational license of Hyperworks. However, though some email exchange I have found that the coupling is a one-way. The radiation analysis software was used, I think, for understanding the solar loading for a SOM project called church of light.
The support guy said : "Unfortunately our coupling with Hyperworks is really a one way coupling. We can accept H coefficients from their software in RadTherm, but they will not read in our wall temps. That said, it still can be a useful coupling in the sense that you can run the analysis in Hyperworks, send H coefficients to RadTherm, and run the analysis to better understand radiation and conduction. Most importantly, that analysis can be done for longer transient analysis, but will require much less compute time and resources."
Not only did I not understand what he means by the H coefficients, my wanting to get a CFD understanding coupled with solar radiation was again, unsatisfied. In the mean while I had to finish a presentation so I haven't had the time to try to get some result on the natural ventilation. I would probably need to look into how their solutions work before I can understand if their software would "do the job"
Thank you for letting me know about your work on this. I downloaded the Honeybee_Set EP Natural Ventilation component and made sure that it is allowed, but it does not show up in grasshopper.
You pointed out that "The component (and the corresponding equation) is mostly meant for cases where you have zones with windows that are NOT connected by an air wall (or a larger airflow network)." I wondered if you are suggesting it would be a code violation for zones to be connected by an air wall for fire safety reasons. It would be a violation I guess, like not putting an fiber insulation or some kind of smoke stop between Spandrel panels and the edge of a floor plate would be a code violation for a typical office building.
There is a project by kevin daly architects where you can see a section drawing with what seems like a cfd analysis (could be an illustration)
it was my initial visualization/simulation goals were for a facade design I am working on
1) an average air velocity across a zone at noon, for example, if a passive design strategy like this was used. for this I am guessing cfd is not entirely necessary. probably means that it could be used earlier in a design process, too. This would be more about user comfort.
2) at a later phase, like in detailing facade components, if airflow is indeed as expected for a zone that is connected to an air wall / chimney like feature (and to see if there is a proper mixing of air)
3) and a projection of energy savings, of course.
After seeing a video of simulation cfd I was optimistic, but like I said sim cfd does not take account of solar loading. I think I would probably go ahead start with one zone with sim cfd first, try three zones stacked on top of each other, then try hyperworks and try to factor in solar radiation.
For analyzing multiple zones on different levels, being able to add a chimney would be especially useful, I think. Having said that, I don't have a lot of experience of using honeybee except for the daylight component so it would take some time for me to understand the components.
I hope some of the information here is useful for you. after all, both sim cfd and hyperworks are commercial softwares and somewhat different than the e plus project you are working on, I guess but still trying to address a similar problem.
so.. in cased you missed it I was asking I downloaded the Honeybee_Set EP Natural Ventilation component and made sure that it is allowed and placed in the user object foler, but it does not show up in grasshopper. what could be the reason?
…
o express my gratitude. I've been experimenting with your definitions (and still am), but let me extend my question.
Actually what I'm trying to achieve, is to recreate another project by Andrew Kudless, the spore lamp (I mentioned the Chrysalis at the beginning just because of the animation, which wasn't included in the Spore Lamp presentation).
Basically the spore lamp seems to me to be something like a preliminary study to the Chrysalis III project (I think it's a similar approach).
Andrew stated on his site that he used kangaroo for this project, so the Spore Lamp consists in my opinion either of a relaxed voronoi 3d diagram (b-rep, b-rep intersection) on a sphere which then has been planarized, or more likely it is a sort of relaxed facet dome.
The trick is to:
1. obtain a nicely-balanced voronoish diagram (or facet dome cells)
2. keep each cell/polyline planar (or force them with kangaroo to be planar) in order to move scale and loft them later on.
Here is what I have by now. (files: matsys spore lamp attempt)
That's the closest appearance that I got so far (simple move scale and loft of facet dome cells with the amount of transformations being proportional to the power of the initial cell area: bigger cell = bigger opening etc.) - with no relaxation of the diagram. But it's obviously not the same thing as the matsys design.
Here are some of my attempts of facet dome relaxation, but well, it certainly still not the right approach, and most importantly I don't know how to keep or force the cells to be planar after the relaxation.
1. pulling vertices to a sphere - no anchor points. That obviously doesn't make sense at all, but the relaxation without anchor points gives at the beginning a pattern that is closer to what I am looking for. (files: relaxation 01)
2. pulling vertices to a sphere - two faces of the initial facet dome anchored (files: relaxation 02)
3. pulling vertices to the initial geometry (facet dome) no anchor points (files: relaxation 03)
The cell pattern of the lamp kinda looks like this:
you can find it here: http://www.grasshopper3d.com/forum/topics/kangaroo-0-095-released?g...
Done with Plankton (of course without the "gradient increase" appearance), but in fact not, I took a look at Daniel Parker's Plankton example files, and it's not quite the same thing. Also the cells aren't planar...
The last problem is that during the relaxation attempts that I did, the biggest initial cells became enormous, and it's not like that in the elegant project by Andrew Kudless, that I'd like to achieve.
So to sum up:
Goal no 1: Obtain an elegant voronoi /facet dome cell pattern on a sphere (or an ellipsoid surface, whatever).
Goal no 2: Keep the cells planar in order to be able to loft them later and obtain those pyramidal forms, and assemble easily
Any ideas? Or maybe there's a completely different approach to that?…
les automatically at the right angle to form the cap of an icosahedron.
To complete the full icosahedron, we consider just the six points we already know, the five pentagon vertices and the raised pyramid tip and reorient one of the vertices using three-point transformation so it obtains the exact same relationship between vertices only one more stage beyond our little cap pyramid, and we do a five-fold polar array:
I used a password-protected cluster I ran into one the forum somewhere to reproduce Rhino's 3-point orient command:
A final 3-point orientation transforms in space the original pyramid tip down to the bottom:
Now we can create a convex hull which gives an icosahedron mesh:
So that's how you build an icosahedron in Rhino from scratch, only using rather long winded Grasshopper.
Now we use the Weaverbird plug-in to subdivide the faces and then project the vertices out onto a sphere via finding the closest points to a sphere and then recreating a convex hull to make a geodesic dome mesh:
Subdividing two times works fine but 3 times blows up convex hull, so I'll just have due with the the subdivision step and leave out projecting back to a sphere, since the algorithm already gives a nice spherical result that you can see inside this disaster:
Now you know what a standard geodescic dome is, just an icosahedron with faces divided into smaller triangles, projected out to a sphere.
Actually, the mere subdivision is just a bit blobby instead of a sphere, damn it, so I'll have to topologically recreate the mesh after projecting the points indeed back onto our sphere.
Using a subdivision plug-in may be slightly throwing the perfect result off, so manually creating subdivision points on each mesh face may be in order, doing them flat against each icosahedron face:
You can also start with the two other triangulated Platonic solids but those give less regular triangles:
…
ree..
First-End List Component cannot manage branches inside every dimensions..
"Smart T8" Component is developed for managing the multi dimensional data tree with first-end algorithm.
It works with path index location..
"-1" or negative numbers mean the location of item..
"0" means the location of the last path index..
positive numbers mean the location from the back..
----
Now look at this example.. a simple 3-dimensional boxes..
In the data tree.. of {0;0;i;j} (k)
"k" is the item index.. Y direction..
"j" is the last path.. X direction..
and "i" is the level.. Z direction..
----
When index < 0 (i.e. "-1" or negative)
"Smart T8" performs like the First-End Item Component..
It selects first items in each list and puts them out to "F"..
and in this example.. they are boxes with same Y coordinate(=0)..
In the below image..
F(Red) M(Transparent Green) E(Blue) are classified by Y coordinates..
----
When index = 0
"Smart T8" focuses on the last path index..
It selects first list of every {0; 0; i; *} set of lists.. (i.e. every levels)
In this example.. they are boxes with same X coordinate(=0)..
because the last path means X grid..
In the below image..
F(Red) M(Transparent Green) E(Blue) are classified by X coordinates..
----
When index = 1
"Smart T8" focuses on the third path index.. (i.e. 1 step from the back)
It selects first list of every {0; 0; *; j} set of lists..
Actually in this case.. they are first levels of every YZ planes..
In this example.. they are boxes with same Z coordinate(=0)..
because "Smart T8" manages levels now (index=1)..
In the below image..
F(Red) M(Transparent Green) E(Blue) are classified by levels..
----
When index > 1.. (if it is meaningless index or out of range..)
It performs First-End List Component..
It selects only the first and end list of all lists..
----
The "Smart T8" component works with 3 or more dimensional data tree well..
Please control the focusing index and enjoy it.. :)
…
a problem with SSL. Any Ideas? I am using the following code:
import json,httplib connection = httplib.HTTPSConnection('api.parse.com', 443) connection.connect() connection.request('GET', '/1/classes/MY-CLASS', '', { "X-Parse-Application-Id": "MY-APP-ID", "X-Parse-REST-API-Key": "MY-REST-API-KEY" }) result = json.loads(connection.getresponse().read()) print result
I Get the Following Messages:
Runtime error (IOException): Authentication failed because the remote party has closed the transport stream. Traceback: line 280, in do_handshake, "C:\Program Files\Rhinoceros 5.0 (64-bit)\Plug-ins\IronPython\Lib\ssl.py" line 120, in __init__, "C:\Program Files\Rhinoceros 5.0 (64-bit)\Plug-ins\IronPython\Lib\ssl.py" line 336, in wrap_socket, "C:\Program Files\Rhinoceros 5.0 (64-bit)\Plug-ins\IronPython\Lib\ssl.py" line 1156, in connect, "C:\Program Files\Rhinoceros 5.0 (64-bit)\Plug-ins\IronPython\Lib\httplib.py" line 3, in script Any help would be greatly appreciated! Thanks in advance! -Zach…