ndard length elements without any cutting, and using only simple connections, such as cable ties or scaffold swivel couplers.
To summarize the approach I present here:
Design an initial shape
Remesh this form so that the edges are all roughly the length of the tubes we will use to build the structure
Rotate and extend the edges of this mesh to create the crossings
Apply a relaxation to optimize the positions of the tubes for tangency
demo_reciprocal_structures.gh
Initial form
In this example I show how to apply this system to a simple sphere. You can replace this with any arbitrary shape. It can be open or closed, and have any topology.
Remeshing
The new ReMesher component takes an input mesh, and a target edge length, and iteratively flips/splits/collapses edges in order to achieve a triangulated mesh of roughly equal edge lengths.
Press the Reset button to initialize, then hold down the F5 key on your keyboard to run several iterations until it has stabilized. (F5 just recomputes the solution, and this can be a quick alternative to using a timer)
Once the remeshing is complete, bake the result into Rhino and reference it into the next part of the definition (I recommend doing this rather than connecting it directly, so that you don't accidentally alter the mesh and recompute everything downstream later).
Alternatively you can create your mesh manually, or using other techniques.
Rotate and Extend
We generate the crossings using an approach similar to that described by Tomohiro Tachi for tensegrity structures here:
http://www.tsg.ne.jp/TT/cg/FreeformTensegrityTachiAAG2012.pdf
Using the 'Reciprocal' component found in the Kangaroo mesh tab, each edge is rotated about an axis through its midpoint and normal to the surface, then extended slightly so that they cross over.
By changing the angle you can change whether the fans are triangular or hexagonal, and clockwise or counter-clockwise.
Choose values for the angle and scaling so that the lines extend beyond where they cross, but not so far that they clash with the other edges.
Note that each rod has 4 crossings with its surrounding rods.
There are multiple possibilities for the over/under pattern at each 'fan', and which one is used affects the curvature:
A nice effect of creating the pre-optimization geometry by rotating and extending mesh edges in this way is that the correct over/under pattern for each fan gets generated automatically.
Optimization for tangency
We now have an approximate reciprocal structure, where the lines are the centrelines of our rods, but the distances between them where they cross vary, so we would not actually be able to easily connect the rods in this configuration.
To attach the rods to form a structure, we want them to be tangent to one another. A pair of cylinders is tangent if the shortest line between their centrelines is equal to the sum of their radii:
Achieving tangency between all crossed rods in the structure is a tricky problem - if we move any one pair of rods to be tangent, we usually break the tangency between other pairs, and because there are many closed loops, we cannot simply start with one and solve them in order.
Therefore we use a dynamic relaxation approach, where forces are used to solve all the tangency constraints simultaneously, and over a number of iterations it converges to a solution where they are all met. The latest Kangaroo includes a line-line force, which can be used to pull and push pairs of lines so that they are a certain distance apart. Each rod is treated as a rigid body, so forces applied along its length will cause it to move and rotate.
The reciprocal component uses Plankton to find the indices of which lines in the list cross, which are then fed into the force for Kangaroo. We also use springs to keep each line the same length.
If the input is good, when we run the relaxation (by double clicking Kangaroo and pressing play), the rods should move only a little. We can see whether tangency has been achieved by looking at the shortest distance between the centerlines of the crossing rods. When this is twice the rod radius, they are tangent. Wait for it to solve to the desired degree of accuracy (there's no need to wait for 1000ths of a millimeter), and then press pause on the Kangaroo controller and bake the result.
The radius you choose for the pipes, curvature of the form and length of the edges all affect the result, and at this stage you may need to tweak these input values to get a final result you are happy with. If you find the rods are not reaching a stable solution but are sliding completely off each other, you might want to try adding weak AnchorSprings to the endpoints of the lines, to keep them from drifting too far from their original positions.
For previewing the geometry during relaxation I have used the handy Mesh Pipe component from Mateusz Zwierzycki, as it is much faster than using actual surface pipes.
To actually build this, you then need to extract the distances along each rod at which the crossings occur, and whether it crosses over or under, mark the rods accordingly, and assemble (If there is interest I will also clean up and post the definition for extracting this information). While this technique doesn't require much equipment, it does need good coordination and numbering!
There is also a ReciprocalStructure user object component that can be found in the Kangaroo utilities tab, which attempts to apply steps 3 and 4 automatically. However, by using the full definition you have more control and possibility to troubleshoot if any part isn't working.
The approach described here was first tested and refined at the 2013 Salerno Structural Geometry workshop, lead by Gennaro Senatore and myself, where we built a small pavilion using this technique with PVC tubes and cable ties. Big thanks to all the participants!
Finally - this is all very experimental work, and there are still many unanswered questions, and a lot of scope for further development of such structures. I think in particular - which of the relative degrees of freedom between pairs of rods are constrained by the connection (sliding along their length, bending, and twisting) and how this affects the structural behaviour would be interesting to examine further.
Steps 3 and 4 of the approach presented above would also work with quad meshes, which would have different stability characteristics.
There is also the issue of deformation of the rods - as the procedure described here solves only the geometric question of how to make perfectly rigid straight cylinders tangent. The approach could potentially be extended to adjust for, or make use of the flexibility of the rods.
I hope this is useful to somebody. Please let me know if you do have a go at building something using this.
Any further discussion on these topics is welcome!
Further reading on reciprocal structures:
http://vbn.aau.dk/files/65339229/Three_dimensional_Reciprocal_Structures_Morphology_Concepts_Generative_Rules.pdf
http://www3.ntu.edu.sg/home/cwfu/papers/recipframe/
http://albertopugnale.wordpress.com/2013/04/05/form-finding-of-reciprocal-structures-with-grasshopper-and-galapagos/
…
can toggle these modes from either the Canvas Toolbar, the Remote Control Panel or via shortcuts Ctrl+1,2 or 3
These are pretty self explanatory so I will keep it brief:
No Preview will completely switch off the preview of the Grasshopper Objects in the Rhino Viewports.
Wireframe Preview similar to Disable Meshing will disable any render meshes but keep any curves or Edges visible.
Shaded Preview will shade the preview...
There are two more Icons in this section of the Display Menu:
Selected Only Preview
Preview Settings
Also available on the Canvas Toolbar.
Selected Only Preview is a useful feature for following what your definition is doing at stages along the process without having to switch all previews off and manually turning individual ones back on as you go.
Without Selected Only Preview Toggled
With Selected Only Preview Toggled:
Preview Settings is the area within Grasshopper where you can modify the colours - including transparency - Grasshopper uses to display objects in the Rhino Viewport.
The first thing you should do before altering any settings is to Drag the Default Colours onto the green plus sign to add them to the Presets. This will enable you to restore them easily.
For future reference the default settings are:
Normal = Hue: 0º, Sat: 100, Val: 59, A:100
Selected = Hue: 120º, Sat: 100, Val: 59, A:100
Apart from accounting for taste this feature is particularly useful for anyone that is colour blind[2]:
The way to restore a colour from the preset list is to drag it from the right hand panel to either the Normal or Selected option on the Left
[2] There is a very interesting discourse topic on the McNeel Forums about Red/Green Colour Blindness.
work carried out by Jørgen Holo
…
or a couple of thingies.
Pattern.gh
I defined parametrically a triangle which I then smoothed out to become more like a blob shape. After that I created a pretty simple pattern that I had in my mind (costed me a lot of time to make this in GH) and finally wanted to rotate each element as it goes higher . The dispatching part seems to be working pretty slow, so it might need an optimization, but I’m still happy with the result as it shows exactly what I wanted, so this is a minor issue in my case.
I then decided to try tessellating my extrusions. You’ll see the voronoi script which is a blob-group in the same Pattern.gh:
I had an idea of something and started the code from scratch, then decided to watch tutorials and implement the code shown there. I somehow coped to combine my code with this in the tutorials, but since my knowledge of Grasshopper is zero to basic my code seems to be very unoptimized and lagging.. When dragging the sliders, it takes a lot of time to compute the changes, although, I’m working on a 24gigs 6th gen i7 machine. It might also need optimization.
Here comes the first tricky part that I couldn’t sort out in an elegant way neither in Grasshopper nor in Rhino. I want a smooth transition between the wall and the ceiling, so that the voronoi tessellation doesn’t get interrupted. If I was to do it in Rhino I’d make a curve with a filleted edge which I’d then revolve/sweep along a rail.
Pattern.gh:
Second thing is – I’ve defined a shape which I want to rotate at a certain degree as it goes higher, however, I don’t have the knowledge to make this happen automatically and just copy the script over and over again. Is there a chance to somehow “loop” the code and parametrically define the degree of rotation and amount of units in the loop?
Next thing is I want to somehow be able to rotate each “6-storey-building” dependently on its surrounding buildings, so that their “terraces” never overlap. I’m using quotes, since they’re still some silly shapes that have nothing to do with buildings and terraces. The principle has to be something like gear wheels or the so-called rack wheels . There has to be some pace which I could set parametrically, but I’m still unsure how to do that in Grasshopper.
The pre-last thing is that I want to control the height of each “building” based on let’s say a topography. I presume this could be done somehow with height maps or some gradient mapper connected to curvature analysis. Not really sure how something like this would work, but I’ve seen such codes that control height depending on a variable.
The last one is more or less similar to the previous. I want to be able to “dissolve” the pattern that I initially created and make it irregular. I suppose this could be done with attractor curve, but again this is just a guess. Please note that this is a top view and the shapes on the upper-left corner have got more "wings" which means there is more floors in the according building. Let's say the buildings in the upper-left corner are 6-7 floors high, in the middle are 4-5 and to the right they're only 3 floors high.
Sorry for that many questions in a single thread. Please let me know if I have to split them in separate threads. All this information is needed for learning purposes. I’m now preparing myself for my bachelor thesis and try as much things as I could, so that I’ll be ready for the final stage of my bachelor’s degree.
Many thanks in advance! Cheers!…
ger work.
Be aware, this release breaks file-forwards compatibility. You will not be able to open gh and ghx files saved with 0.8.0050 on previous versions, though of course you should be able to open old files without problems. If this is not the case, please yell loudly.
If you're having trouble loading Grasshopper, note that you must have the latest Microsoft C++ Runtimes installed on your machine. They can be downloaded from the microsoft website.
The new release can be downloaded from the usual location.
Here's a list of changes, additions and fixes since 0.8.0013:
File format forwards compatibility has been broken. You will not be able to open files saved with 0.8.0050 on earlier versions.
This release contains many breaking changes and GHA libraries compiled for older version may not work anymore.
Grasshopper Binary files (*.gh) are now saved as compressed data.
Grasshopper Binary files (*.gh) are now the default format.
Support for ancient versions of the Text Panel (still called Post-It from back then) has been removed.
Support for ancient versions of the Path Mapper (still called Path Lexer from back then) has been removed.
Placeholders for ancient versions of the Graph Mapper have been removed.
Gradient input parameters now show state tag icons (Reversed, Flatten etc.).
Geometry Cache name changes are now updated on every key press.
Geometry Cache name changes can now be cancelled with Escape.
Geometry Cache name changes can now be undone.
Mesh|Mesh intersection component now uses a different algorithm. The old behaviour is still available from the component menu.
Warning and Error balloons are now drawn as part of a Canvas Widget and will no longer show up in the Hi-Res image export.
Galapagos now accepts multiple fitness values. The true fitness will be the average of the collection.
Galapagos wires are drawn much fainter when the Galapagos object is unselected.
Medium fast redraw mode in Galapagos now immediately redraws instead of at the end of each generation.
Redesigned all Grasshopper file format icons and added larger size icons for high-dpi explorer views.
Redesigned the Most Recently Used files menu, it should now display much quicker.
Compass widget has been rewritten in an attempt to increase display performance.
Added preferences section for Compass widget.
Added preferences section for Align widget.
Added preferences section for Default Preview colours.
Added preferences section for Document Preview colours.
Added preferences section for the Most Recently Used files menu.
The Area component now accepts Breps, Meshes and Planar Closed Curves.
The Area Centroid component now accepts Breps, Meshes and Planar Closed Curves.
The Volume component now accepts Breps and Meshes.
The Volume Centroid component now accepts Breps and Meshes.
Added Merge Faces component (Surface.Util panel).
Added a Mesh Smooth component (Mesh.Util panel).
Added a Curve Seam component (Curve.Util panel).
Added Interpolate Curve With Tangents component (Curve.Spline dropdown).
Added GrasshopperFolders command to open Settings, Components and UserObject folders without loading the core plugin.
The window that reports on certain Loading Errors now has a Copy button.
Added Simplify post-process filter to parameters (in addition to Reverse, Flatten and Graft).
Parameter post processes (Reverse, Flatten, Graft & Simplify) can now also be assigned to output parameters.
Version History window now has formatting (not happy with this, I'm working on something better).
The Process Info window is gone.
Main menu has been redesigned.
Canvas toolbar has been redesigned.
Canvas context menu has been replaced by a Radial Menu.
Canvas now has a radial menu which will pop up on Middle Mouse Button clicks.
It's possible to switch between Radial and Legacy menus in the Preferences (Interface.Canvas section).
'Save As Copy' feature has been replaced by 'Save Backup' which is a GUI-less save including date+time stamp.
Added a 'Show in Folder' item to the File menu.
AutoSave settings are no longer available from the File menu, you now need to use the Preferences.
Selection shifts now also modify the view so you can use Ctrl+Left and Ctrl+Right to navigate up and downstream.
Mesh Edge display can now be toggled with Ctrl+M.
Preview modes now have shortcuts (Ctrl+1 = no preview, Ctrl+2 = wireframe, Ctrl+3 = shaded).
Solution States now have a default name.
Data Viewer window now responds to all required events.
Data Viewer window can now handle input and output parameters as well.
Canvas Navigation pane can now be dragged using the icon in the upper left corner.
The Persistent Data Editor has been redesigned.
It's now possible to select multiple items in the Persistent Data Editor list and edit their properties.
It's now possible to drag multiple items at the same time in the Persistent Data Editor list.
Item addition to the Persistent Data Editor is much improved.
The Persistent Data Editor is now non-modal.
The Canvas would remain black upon maximizing the Rhino window, this is fixed.
Sliders would cause multiple updates under certain conditions, this is fixed.
Digit Scrollers would cause multiple updates under certain conditions, this is fixed.
Pipes were inside out. This is fixed.
The curve component would not adjust invalid nurbs degrees, this is fixed.
Curves referencing Brep edges failed to load, this is fixed.
Points referencing Brep edges failed to load, this is fixed.
Referenced dlls in the VB/C# components sometimes resulted in invalid imports statements, this is fixed.
Pasting geometry in Rhino would cause a recompute of the Grasshopper solution, this is fixed.
Importing a file into the Rhino document would cause a recompute of the Grasshopper solution, this is fixed.
Galapagos would trigger superfluous solutions, this is fixed.
Mesh Solid Difference had a wrong name and description, this is fixed.
Several menu items were not greyed out despite not being usable, this is fixed.
The position and size of the Grasshopper window failed to get stored on Rhino shutdown, this is fixed.
The Persistent Data Editor would crash on parameters that did not support data proxies, this is fixed.
I'll add some additional information regarding some of the new UI features in subsequent posts.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
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…
re are major changes and enhancements.
HONEYBEE
More Flexible Workflow - Many small modifications were made to support a more flexible workflow, such as the ability to separate a zone created with masses2Zones into editable HBSrfs that can be recombined. For the energy components, it is now possible to plug custom constructions directly into the components that set the zone constructions without writing them first into the library. For the daylighting components it is now possible to change all of the materials of specific surface types at once.
Support for Complex Geometry - Many small bugs for complex geometry have been fixed including the ability to import energy results correctly for curved NURBS surfaces as well as unconventional window configurations. Also, the intersectMasses component now almost always succeeds in splitting all of the surfaces of adjacent zones, no matter how complex the intersection is.
Automatic Download Issues Fixed - Many users who faced issues with not having “gendaymtx.exe” or who had trouble syncing with our github know that we faced an issue with automatic background downloads.
Air Walls - Honeybee EnergyPlus models now officially support air walls (or virtual partitions) in a basic implementation. Now, any time that you use the air wall construction or set a surface type to “air wall,” the air between adjacent zones will be automatically mixed. At present, this mixing is just a constant flow based on the surface area between zones connected by air walls multiplied by an adjustable “flow factor.” It is important to stress that this basic air mixing is not with the EnergyPlus Airflow Network, although the groundwork laid in this release will eventually allow for the implementation of the Airflow Network in future releases. As such, this present air mixing is only suitable for multi-zone conditions where there is not significant buoyancy-driven flow between zones.
Natural Ventilation - To go along with the new potential introduced by air walls, there has been a basic implementation of EnergyPlus’s natural ventilation objects in a new component called “Set EP Airflow”. The current setup allows for three possible types of natural ventilation: 1) natural ventilation through windows (with auto-calculated flow based on window area, outdoor wind speed/direction, and stack effects), 2) custom wind and stack objects that can be used to model things such as chimneys off of single zones, and 3) constant, fan-driven natural ventilation.
Additional Thermal Mass - The capability to add additional thermal mass to zones has been added. This is useful for factoring in the mass of indoor furniture or heavy interior objects such as chimneys.
New Utility Components - Abraham has added a couple of useful components to help calculate lighting loads based on bulb types and target lighting levels as well as a converter from ACH to the m3/s-m2 that the other HB components accept. Along this vein, there is also a component for adding in the resistance of Air Films to HB constructions.
Improved and Editable Ideal Air Loads System - The EnergyPlus Ideal Air System now goes through an automatic sizing period at the start of the simulation based on the extreme weeks of the weather file. Furthermore, the ability to adjust many of the parameters of the ideal air loads system have been added with a new “Set Ideal Air Loads Parameters” component. The component allows you to add in heat recovery, air side economizers and demand-controlled ventilation.
OpenStudio Export Update - The OpenStudio workflow is still largely under development but this release includes a version with a working VAV and PTHP system template for those curious with experimenting. Note that not all of the new features available for the basic “Run Energy Simulation” component are available for the OpenStudio component (such as air walls, natural ventilation, or additional thermal mass).
Microclimate/Indoor Comfort Maps - Blossoming from initial experiments with the radiant temperature map, a workflow for looking into sub-zone microclimate and indoor comfort has been initiated. All components for this are presently under the Honeybee WIP tab but, over the next month, they will be completing their development phase and moving into the rest of the tabs. If you are interested in testing when they are ready, please let Chris know. For a teaser video of the intended capabilities, see this video: (https://www.youtube.com/watch?v=fNylb42FPIc&list=UUc6HWbF4UtdKdjbZ2tvwiCQ)
LADYBUG
Monthly Bar Chart - After much demand from multiple parties, a new component to create monthly bar and line charts has been added. The component is particularly useful for plotting the outputs of the “Average Data” component like monthly EPW data or averaged monthly-per hour data. It also supports daily data and any type of Energy simulation results.
Wind Profile - To go along with the new capabilities of natural ventilation in Honeybee, Ladybug now has a fully fleshed-out Wind Profile component that allows you to visualize how wind speed changes with height in relation to your building geometry. The component is geared to understanding the conditions of prevailing wind and will be useful in the future for setting up CFD models. Credit goes to Djordje Spasic for adding in all of the new capabilities. In a similar vein, the appearance of the wind rose has also been improved thanks to suggestions from Alejandra Menchaca.
Faster Solar Adjusted Temperature - Thanks to the SolarCal method from the Center for the Built Environment at UC Berkeley (http://escholarship.org/uc/item/89m1h2dg), the solar adjusted temperature component now includes an option for a much faster calculation that produces results that are very close to those originally obtained with the genCumSky component. Instead of using the cumulative sky, the component can now accept the direct and diffuse radiation from the ImportEPW component. Over a whole year, this essentially takes a calculation that used to be a half-hour and shrinks it down to 10 seconds. Thanks again to those at UC Berkeley for keeping their work open source!
Instructions - Last but not the least, [It took me almost two years to understand this but finally] we have a text file that describes the installation step by step and is way easier to modify than a video. You can find it in the zip file. Credit goes to Chris!
We also want to welcome Anton, Patrick and Sandeep to the team. Anton has kicked off his development by working on a component to import and visualize epw ground temperature data and he will be continuing to develop components to bring in reliable precipitation data to Ladybug. With this basis, he will continue to implement Honeybee components for ground heat storage, earth tubes, rain collection and hot water systems. Patrick and Sandeep are working on integration of Honeybee to Energy Performance Calculator.
As always let us know your comments and suggestions.
Enjoy!…
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:
…
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…
u might already noticed.
Second great thing is that is quite fast, precise and versatile (for this kind of things); also is way OPEN (meaning you can attach and or interface it with almost anything you can imagine, meaning hardware, and other sw components, etc (like a CNC machine (additive manufacturing toys..) or any sw like C# component)) making a GREAT HUGE difference with almost any other CAD (and CAM sw i must say)
i made a simple fully functional CAM component - highly powerful ! - in a couple of days...
also tested an arduino interface (meaning control over almost any elctronic device out there)... in a matter of hours...
and saw and can easily think about lots and lots of extremely cool usages of this great tool in almost any area ...
So that's why i would suggest - and will do something about for - it (or similar tools) to be teached at first stages of education !
But power comes with responsability. and is far better exploited when your are smart ;)
I think people that uses GH will be n-times as good when they don`t forget manufacturing.
This includes teachers btw....
Interesting thing to account is that all things that GH is great at (a LOT) means reducing dramatically the time spent to model almost anything...
But usually the purpose (unless the objective is just learning or doing some kind of virtual art (both legal stuff btw...;) but guess it might not be your case now and after graduating..)) is to end up by actually building some real 3D stuff...
So what Joseph is poining is key...
If you have a good teacher.. i guess it should pay more and more attention not just at your gh skills but rather the way in which you use the power, versatility and extra time gh (and additive manufacturing tech) saves, to think about how to design the stuff focusing on the ultimately relevant stuff...
optimisation...
So..
I would say that any heat interchanger like the one involved in your thesis, has to deal with fluids.. have to account for some sort of life span (involving cheaper an ideally no maintenance needed along its life...), and of course also critical the costs of manufacturing.
so... be the best one...
use GH smartly ! ie...
account for different profile paths for oil and water.. they're different fluids meaning they have different specific heat, viscosity, blah... and so... they might not even traverse the interchanger at same flow ratio, etc.
So... maybe you want to start by reshaping the grid... (parametrically...!) so you can arbitrarily and dynamically modify and get to see interactively in your definition the areas ratio of sections so as to finaly get to set the "ideal" (meainng optimum) relative areas (sections) ratio of oil to water paths... (or whatever other fluids could be !), and the material also...
Secondly you might also consider that triangles might not be well suited for the conduit sections because are not the best shape to carry most fluids... (hoses are of circular sections...worst case are kinda rectangular with rounded corners..;) not only because the're easy to manufacture but also because they minimise (optimize) flowing energy losses AND are less prone to (ie salt or debree deposits in the interior) ). so think about rounded shapes, of if you want some regular polygons stuff but 5 or more faces...kinda circular...got it ?
I love bees by the way..
and if you happen to need more interchange area (obviously another (and probably the #1 key one) figure you should be displaying interactively in your definition ) you can always add some more extrusion length...
third... the twisting stuff is cool... (artistically ;)) but i 100% agree with Joseph is far likely to involve higer costs for manufacturing with no clear benefit on surface maximization... and most probably some other losses in added friction to the flow of fluids (meaning higher costs for pumping, etc...)...
fourth...
consider the area, (then the volume!) of the "building material"... you should optimise that too ! so this could be another one of your interactive displays...
in this case... you not only can see optimisation by reducing the amount of materials to build your interchanger...
but you can also notice that if the "building tech" involves the well and common additive manufacturing process of extrusion deposits... that surface area, and that extrusion length, meaning volume and cost of raw material, also mean TIME to manufacture... and i guess you teacher will find good for you to consider and mention that one too...
fifth...
finally (for now hehe), and globally most important in the short term :)
if the objective of yor teacher is for you just to learn GH and impress him and the rest of the world then, ok, do the twist the swirl and imagine all kind of sea star and or ondulated conduit sections (maybe some recursive forms (fractals...) like snowflakes... or any n-arms (mutant !) starfishes shapes) but make sure you first get to know and validate what it will be the objectives of your evaluator...
.. in the near end this is all about passing your thesis while learning GH while having fun.. isn't it ?
go for it and best of luck !
ps: for the mid and long term.. some day take a look at linear optimisaton if you already didn't.
i think GH is a great tool to try out some linear optimisation stuff directly linking geometry related figures (areas, volumes...) along with costs figures !...
I haven't seen anything like that yet (but since i'm only a few months old in gh, i think is likely to already be something or this stuff out there. )
If not... well you can always be the first !
(and this particular case of your thesis is a great example (few key variables) to try out "automatic optimisation")
https://en.wikipedia.org/wiki/Simplex_algorithm
that... by the way...has lots to do with spatial geometry...
…
e a fundamental failure on my part. On the other hand, Grasshopper isn't supposed to be on a par with most other 3D programs. It is emphatically not meant for manual/direct modelling. If you would normally tackle a problem by drawing geometry by hand, Grasshopper is not (and should never be advertised as) a good alternative.
I get that. That’s why that 3D shape I’m trying to apply the voronoi to was done in NX. I do wonder where the GUI metaphor GH uses comes from. It reminds me of LabVIEW.
"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."
Grasshopper ships with about 1000 components (rounded to the nearest power of ten). I'm adding more all the time, either because new functionality has been exposed in the Rhino SDK or because a certain component makes a lot of sense to a lot of people. Adding pre-canned components that do the same as '8 or 10 components strung together' for the heck of it will balloon the total number of components everyone has to deal with. If you find yourself using the same 8 to 10 components together all the time, then please mention it on this forum. A lot of the currently existing components have been added because someone asked for it.
It’s not the primary components that catalyzed this thought but rather the secondary components. I was toying with a component today (twist from jackalope) that made use of three toggle components. The things they controlled are checkboxes in other apps.
Take a look at this jpg. Ignore differences; I did 'em quickly. GH required 19 components to do what SW did with 4 commands. Note the difference in screen real estate.
As an aside, I really hate SolidWorks (SW). But going forward, I’ll use it as an example because it’s what most people are familiar with.
"[...] has a far cleaner and more intuitive interface. So does SolidWorks, Inventor, CATIA, NX, and a bunch of others."
Again, GH was not designed to be an alternative to these sort of modellers. I don't like referring to GH as 'parameteric' as that term has been co-opted by relational modellers. I prefer to use 'algorithmic' instead. The idea behind parameteric seems to be that one models by hand, but every click exists within a context, and when the context changes the software figures out where to move the click to. The idea behind algorithmic is that you don't model by hand.
I agree, and disagree. I believe parametric applies equally to GH AND SW, NX, and so forth, while algorithmic is unique to GH (and GC and Dynamo I think). Thus I understand why you prefer the term. I too tend to not like referring to GH as a parametric modeler for the same reason.
But I think it oversimplifies it to say parametric modelers move the clicks. SW tracks clicks the same way GH does; GH holds that information in geometry components while SW holds it in a feature in the feature tree. In both GH and SW edits to the base geometry will drive a recalculation, but more commonly, it’s an edit to input data, beit equations or just plain numbers, that drive a recalculation.
I understand the difference in these programs. What brought me to GH is that it can create a visual dialog that standard modelers can’t. But as I've grown more comfortable with it I’ve come to realize that the GUI of GH and the GUI of other parametric modelers, while looking completely different, are surprisingly interchangeable. Do not misconstrue that I’m suggesting that GH should replace it’s GUI with SW’s. I’m not. I refrain from suggesting anything specific. I only suggest that you allow yourself to think radically.
This is not to say there is no value in the parametric approach. Obviously it is a winning strategy and many people love to use it. We have considered adding some features to GH that would make manual modelling less of a chore and we would still very much like to do so. However this is such a large chunk of work that we have to be very careful about investing the time. Before I start down this road I want to make sure that the choice I'm making is not 'lame-ass algorithmic modeller with some lame-ass parametrics tacked on' vs. 'kick-ass algorithmic modeller with no parametrics tacked on'.
Given a choice, I'd pick kick-ass algorithmic modeller with no parametrics tacked on.
2. Visual Programming.
I'm not exactly sure I understand your grievance here, but I suspect I agree. The visual part is front and centre at the moment and it should remain there. However we need to improve upon it and at the same time give programmers more tools to achieve what they want.
I'll admit, this is a bit tough to explain. As I've re-read my own comment, I think it was partly a precursor to the context sensitivity point and touched upon other stated points.
This now touches upon my own ignorance about GH’s target market. Are you moving toward a highly specialized tool for programmers and/or mathematicians, or is the intent to create a tool that most designers can master? If it’s the former, rock on. You’re doing great. If it’s the latter, I’m one of the more technically sophisticated designers I know and I’m lost most of the time when using GH.
GH allows the same freedom as a command line editor. You can do whatever you like, and it’ll work or not. And you won’t know why it works or doesn't until you start becoming a bit of an expert and can actually decipher the gibberish in a panel component. I often feel GH has the ease of use of DOS with a badass video card in front.
Please indulge my bit of storytelling. Early 3D modelers, CATIA, Unigraphics, and Pro-Engineer, were unbelievably difficult to use. Yet no one ever complained. The pain of entry was immense. But once you made it past the pain threshold, the salary you could command was very well worth it. And the fewer the people who knew how to use it, the more money you could demand. So in a sense, their lack of usability was a desirable feature among those who’d figured it out.
Then SolidWorks came along. It could only do a fraction of what the others did, but it was a fraction of the cost, it did most of what you needed, and anyone could figure it out. There was even a manual on how to use it. (Craziness!) Within a few short years, the big three all had to change their names (V5, NX, and Wildfire (now Creo)) and change the way they do things. All are now significantly easier to use.
I can tell that the amount of development time that’s gone into GH is immense and I believe the functionality is genius. I also believe it’s ease of use could be greatly improved.
Having re-read my original comments, I think it sounded a bit snotty. For that I apologize.
3. 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."
Unfortunately it's not as simple as that. Whether or not a conversion between two data types makes sense is often dependent on the actual values. If you plug a list of curves into a Line component, none of them may be convertible. Should I therefore not allow this connection to be made? What if there is a single curve that could be converted to a line? What if you want to make the connection now, but only later plan to add some convertible curves to the data? What you made the connection back when it was valid, but now it's no longer valid, wouldn't it be weird if there was a connection you couldn't make again?
I've started work on GH2 and one of the first things I'm writing now is the new data-conversion logic. The goal [...] is to not just try and convert type A into type B, but include information about what sort of conversion was needed (straightforward, exotic, far-fetched. etc.) and information regarding why that type was assigned.
You are right that under some conditions, we can be sure that a conversion will always fail. For example connecting a Boolean output with a Curve input. But even there my preferred solution is to tell people why that doesn't make sense rather than not allowing it in the first place.
You bring up both interesting points and limits to my understanding of coding. I’ve reached the point in my learning of GH where I’m just getting into figuring out the sets tab (and so far I’m not doing too well). I often find myself wondering “Is all of this manual conditioning of the data really necessary? Doesn’t most software perform this kind of stuff invisibly?” I’d love to be right and see it go away, but I could easily be wrong. I’ve been wrong before.
5. 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."
I was thinking of just zooming in on a component would eventually provide easier ways to access settings and data.
I kinda like this. It’s a continuation of what you’re currently doing with things like the panel component.
"Could some of these items disappear if they are contextually inappropriate or gray out if they're unlikely?"
It's almost impossible for me to know whether these things are 'unlikely' in any given situation. There are probably some cases where a suggestion along the lines of "Hey, this component is about to run 40,524 times. It seems like it would make sense to Graft the 'P' input." would be useful.
6. Integration.
"Why isn't it just live geometry?"
This is an unfortunate side-effect of the way the Rhino SDK was designed. Pumping all my geometry through the Rhino document would severely impact performance and memory usage. It also complicates the matter to an almost impossible degree as any command and plugin running in Rhino now has access to 'my' geometry.
"Maybe add more Rhino functionality to GH. GH has no 3D offset."
That's the plan moving forward. A lot of algorithms in Rhino (Make2D, FilletEdge, Shelling, BlendSrf, the list goes on) are not available as part of the public SDK. The Rhino development team is going to try and rectify this for Rhino6 and beyond. As soon as these functions become available I'll start adding them to GH (provided they make sense of course).
On the whole I agree that integration needs a lot of work, and it's work that has to happen on both sides of the isle.
You work for McNeel yet you seem to speak of them as a separate entity. Is this to say that there are technical reasons GH can only access things through the Rhino SDK? I’d think you would have complete access to all Rhino API’s. I hope it’s not a fiefdom issue, but it happens.
7. Documentation.
Absolutely. Development for GH1 has slowed because I'm now working on GH2. We decided that GH1 is 'feature complete', basically to avoid feature creep. GH2 is a ground-up rewrite so it will take a long time until something is ready for testing. During this time, minor additions and of course bug fixes will be available for GH1, but on a much lower frequency.
Documentation is woefully inadequate at present. The primer is being updated (and the new version looks great), but for GH2 we're planning a completely new help system. People have been hired to provide the content. With a bit of luck and a lot of work this will be one of the main selling points of GH2.
It begs the question that I have to ask. When is GH1.0 scheduled to launch? And if you need another person to proofread the current draft of new primer.
patrick@girgen.com
I can’t believe wikipedia has an entry for feature creep. And I can’t believe you included it. It made me giggle. Thanks.
8. 2D-ness.
"I know you'll disagree completely, but I'm sticking to this. How else could an omission like offsetsurf happen?"
I don't fully disagree. A lot of geometry is either flat or happens inside surfaces. The reason there's no shelling (I'm assuming that's what you meant, there are two Offset Surface components in GH) is because (a) it's a very new feature in Rhino and doesn't work too well yet and (b) as a result of that isn't available to plugins.
I believe it’s been helpful for me to have figured this out. I recently completed a GH course at a local Community College and have done a bunch of online tutorials. The first real project I decided to tackle has turned out to be one of the more difficult things to try. It’s the source of the questions I posted. (Thanks for pointing out that they were posted in the wrong spot. I re-posted to the discussions board.)
I just can't seem to figure out how to turn the voronoi into legitimate geometry. I've seen this exact question posted a few times, but it’s never been successfully answered. What I'm showing here is far more angular than I’m hoping for. The mesh is too fine for weaverbird to have much of an effect. And I haven't cracked re-meshing. Btw, in product design, meshes are to be avoided like the plague. Embracing them remains difficult.
As for offsetsurf, in Rhino, if you do an offsetsurf to a solid body, it executes it on all sides creating another neatly trimmed body thats either larger or smaller than the original. This is how every other app I know of works. GH’s offsetsurf creates a bunch of unjoined faces spaced away from the original brep. A common technique for 3D voronois (Yes, I hit the voronoi overuse easter egg) is to find the center of each cell and scale them by this center. If you think about it, this creates a different distance from the face of the scaled cell to the face of the original cell for every face. As I've mentioned, this project is giving me serious headaches.
Don't get me wrong, I appreciate the feedback, I really do, but I want to be honest and open about my own plans and where they might conflict with your wishes. Grasshopper is being used far beyond the boundaries of what we expected and it's clear that there are major shortcomings that must be addressed before too long. We didn't get it right with the first version, I don't expect we'll get it completely right with the second version but if we can improve upon the -say- five biggest drawbacks (performance, documentation, organisation, plugin management and no mac version) I'll be a happy puppy.
--
David Rutten
Thank you for taking the time to reply David. Often we feel that posting such things is send it into the empty ether. I’m very glad that this was not the case.
And thank you for all of the work you've put into GH. If you found any of my input overly harsh or ill-mannered, I apologise. It was not my intent. I'm generally not the ranting sort. If I hadn't intended to provide possibly useful input, I wouldn't have written.
Cheers
Patrick Girgen
Ps. Any pointers on how to get a bit further on the above project would be greatly appreciated.
…