n fact) according a vast variety of "modes" PLUS the required clash detection (ALWAYS via trigonometry). In plain English: outline any collection of Breps and "apply" a truss that is topologically sound (planarization in case of quads etc is an added constrain). PLUS outline/solve what comes "next" after that truss (like the planar glazing "add-on" brackets of yours [ the ones that need redesign, he he], or some roofing/facade skin system [secondary supports, corrugated sheet metal, insulation, final cladding, dogs and cats])
2. Imaging doing this in real life (nothing to do with "abstract" formations of "lines" or "shapes" or whatever). This means primarily adopting a BIM umbrella: in plain English AECOSim, Revit or Allplan (I'm a Bentley man so I use AECOSim + Generative Components). This also means using "in-parallel" a top MCAD app for 1:1 details, FEA/FIM and the vast paraphernalia required for real-life studies destined for real-life projects (made with real-life money by real-life people). My choice: CATIA/Siemens NX.
3. What to send to Microstation (if not using Generative Components, that is) and/or CATIA? In what "state"? To do what exactly? For instance even if you could design this feature driven tensile membrane anchor custom node in Rhino (you can't) it could be 100% useless in CATIA:
4. Imaging masterminding ways to send them nested instance definitions of ... er ... a coordinate system (all what you need). In plain English: since is utterly pointless to send them nested blocks that can't been parametrically controlled (variations/modifications/PLM management/BOM/specs etc etc)... send them simply the "instructions" to place coordinate systems of components that ARE parametrically designed within Microstation and/or CATIA (classic feature driven design approach blah blah). So GH solves topology et all (working on data imported via, say, Excel sheets related with sizes of components etc etc) and sends to Microstation simply this (a myriad of "this" actually):
I do hope that the gist of the "method" (the ONLY way to invite GH to the party) is clear.
best, Peter…
I tell you what I had to do and how I did it.
I have the following situation. A urban context with a square plot 40m x 40m surrounded by buildings.
If I extrude the plot I get 4 surfaces and I need to calculate the minimum daily quantity of direct sunlight hours each test point receives in the period from 22nd of April to 22nd of August. For example for the test point at index 21 of surface with index 1 (I am just creating these numbers in my mind) the minimum is on 27th of April and the test point receive 8 hours (this is also invented for the sake of the example) of direct sunlight. All the other days it receives more. So the values I have to found are these minimums for all the test points. Now how to calculate these minimum quantities is a different issue of the topic of this post and actually I manage it.
Continuing with the explanation of what I had to... so I have only the initial plot that generate 4 surfaces, then I want to test smaller plots generated by an offset of 4 m of the original one, and the relative 4 surfaces for each smaller plot.
So in this case I think I cannot use your suggestion because the object don't exist yet.
I managed creating a loop with Anemone, the loop generate an offset starting from the original at 0 until 4 (then I multiply it by 4 to obtain the offset at 0, 4, 8, 12 and 16. Then I did like you also suggest I record every time the result with the DataRecorder and I create for each result a different branch with the index coming from the loop (0, 1, 2, 3 and 4) with the Flatten component.
In this image you can see all the surfaces saved in the same way as described above and in white the test points that receive minmum or equal than 2.5 hours per day of direct sunlight in the period from from 22nd of April to 22nd of August and in dark gray the test points that receive less.
The main point of this discussion is just the fact that instead use this tricky way I used, or the one you suggest, to analyze separately (because they shade each other) 20 geometries (in this case 20 they could be many more) it would be good if it would be possible just to input all the geometries at the same time and they would not shade each other so to get directly all the results with one run and in a more simple way.
Francesco
…
requires four weather data inputs: air temperature (_dryBulbTemperature), relative humidity (relativeHumidity_), wind speed at 1.1 meters from the ground (windSpeed_) and mean radiant temperature (meanRadiantTemperature_).You can add values to the first three inputs from the Ladybug "Import Epw" component. For the last (meanRadiantTemperature_), you can add it from Ladybug's "Outdoor Solar Adjusted Temperature Calculator" component, or let "Thermal Comfort Index" component to calculate it. Both use different methods to calculate the final values.
I attached an example file below with second option.For more precise calculations you can use Honeybee and Chris' microclimate maps.An icing on the cake for the end: one of Ladybug developers yesterday released a set of Ladybug components for modelling in ENVI-met application. ENVI-met is cutting-edge microclimate software, which can be downloaded for free. It opens a number of advanced new analysis in outdoor domain, which couldn't have been done with the current Ladybug+Honeybee tools. So you can perform the simulation in ENVI-met 4 free software, and then add mean radiant temperature values from ENVI-met simulation to "Thermal Comfort Indices" component. Here is an example file.If you would like to go with the last approach, then the best would be to post a question about it in this topic.
1) You can make a polygonized tree.I haven't subtracted the trunk from the crown, but I guess it makes sense that it can be done.2) In most solar related simulations, a default albedo value of 0.2 is used. This corresponds to average albedo value taken from materials surrounding the urban or countryside location (concrete, grass, gravel, sand, asphalt...). However the presence of snow can significantly magnify the average albedo value several times. "Sunpath shading" components albedo_ input has an ability to calculate albedo due to presence of snow, if nothing is added to it (to albedo_ input). As you are performing the analysis of PET in a horizontal plane, it will not affect your calculations.3) Most thermal comfort indices will require performing analysis at 1.1 meters above the ground. This is considered to be height of standing person's gravity center.The same goes for PET index. So you are correct: you should place the analysis grid at 1.1 meters above the ground before adding it to the "Sunpath Shading" component.It is worth mentioning that "Thermal Comfort Indices" component used in this topic's PET_on_Grid2.gh and PET_on_Grid3.gh files is from last year, and much slower than the newest one (VER 0.0.64 MAR 18 2017) used in the example attached below. Just a remainder if you have been using older version of this component.Let me know if I misunderstood some of your questions, or if I missed to answer some of them.
EDIT: sorry for posting a double reply. When I posted it the first time, I only got links visible, with no text. Something has been wrong with grasshopper ning forum for the last couple of months.…
search for residential type and surprisingly there are none. This can be, but i'm surprised.
The location in example is the Financial District of Manhattan. I assume there might not be too many purely residential buildings there. If you increase the radius to 300meters it will find one.The OSMobject "Residential building" will look for mostly purely residential buildings. For example those in Chinatown or Lower East Side.However most of the time a building might be a multi-purpose: shops on the ground floor, offices above, and above them residential apartments. Users can sometimes avoid tagging these kind of buildings, and may just tag them with "buildings"="yes", not the type of the building too (for example: "building"="multiuse"). So this may be the problem why you might not get too many residential buildings.I guess the only solution to this issue is to add these tags by yourself. Then Gismo will instantly make use of them.I mentioned previously that I will create a couple of video tutorials, but I seemed to never found enough time. I apologize for that. The process is actually quite simple.
Here is small step by step tutorial on how to do that. It may take you about 2 minutes to tag your building and use that tag in Gismo.
Also office buildings. I imagine this is not up to you, but can be kind of disappointing. I wanted for example to do some Ladybug analysis only on residential or office buildings ... pitty.
"Office building" has not been added to "OSMobjects" dropdown list. I have just added it.However, whenever some sort of object is not defined in "OSMobjects" dropdown list, one can use the _requiredKey and requiredValues_ inputs of the "OSM tag" component:
I just tried looking for office building for the same location we have in the create_legend_example.gh file and it found 3 of them. There would probably need to be more, but it may be that nobody tagged those with "building"="office"
The legend is nice, though i think is not completely synchronized with the LegendBakeParameters: You need to provide a point for the LegenPlane input and another for the titleOriginPt output of the CreateLegend.
Unlike Ladybug, Gismo threats the title and the legend separately. So the legend's color bar would have its own starting point (plane) while the title will have its own. I found myself puzzled sometimes in Ladybug, why this wasn't possible.Or did I misunderstand you?…
Added by djordje to Gismo at 12:33pm on May 8, 2017
hope this number will grow in future. Currently available features are:
1) Creation of 2d or 3d context for any kind of building related analysis: automatically generate the 2d/3d surrounding buildings for the location where you would like to perform visibility, solar radiation, cfd or any other type of analysis. You need some other plugin for the last three, like Ladybug. It only creates the context=surroundings! The "automatic generation" process also includes creation of the local topography (terrain) along with buildings.
2) Identification of certain 2d or 3d elements in the created context. For example: selection of all hotels, parks, hospitals, restaurants, residential buildings etc.
3) Performing direct terrain analysis (hillshading, slope, ruggedness, roughness, water flow...)
4) Creation of terrain shading masks and horizon files for further solar and photovoltaics analysis.
Gismo will be very grateful if he could get any suggestions, improvements, bug reports and testing in the following period. In case you are willing to provide any of these, the requirements, installation steps and .gh example files can be found here, here and here.
Thank you in advance !!…
Added by djordje to Gismo at 9:10am on January 29, 2017
and export the geometry out to VVVV to render it LIVE! RawRRRR. In this case, a digital audio workstation Ableton Live, a leading industrial standard in contemporary music production.
the good news is that VVVV and ableton live lite is both free.
https://www.ableton.com/en/products/live-lite/
i am not trying to use ipad as a controller for grasshoppper. I wanted to work with a timeline (similar to MAYA or Ableton or any other DAW(digital audio workstation)) inside grasshopper in an intuitive way. Currently there is no way of SEQUENCING your definition the way you want to see that i know of.
no more combersome export import workflows... i dont need hyperrealistic renderings most of the time. so much time invested in googling the right way to import, export ... mesh settings...this workflow works for some, for some not ...that workflow works if ... and still you cannot render it live nor change sequence of instruction WHILE THE VIDEO is played. and I think no one wants to present rhinoceros viewport. BUT vvvv veiwport is different. it is used for VJing and many custom audio visual installation for events, done professionally. you can see an example of how sound and visuals come together from this post, using only VVVV and ableton. http://vvvv.org/documentation/meso-amstel-pulse
I propose a NEW method. make a definition, wire it to ableton, draw in some midi notes, and see it thru VVVV LIVE while you sequence the animation the WAY YOU WANT TO BE SEEN DURING YOUR PRESENTATION FROM THE BEGINNING, make a whole set of sequences in ableton, go back change some notes in ableton and the whole sequence will change RIGHT INFRONT of you. yes, you can just add some sound anywhere in the process. or take the sound waves (sqaure, saw, whateve) or take the audio and influence geometric parameters using custom patches via vvvv. I cannot even begin to tell you how sophisticated digital audio sound design technology got last ten year.. this is just one example which isn't even that advanced in todays standard in sound design ( and the famous producers would say its not about the tools at all.) http://www.youtube.com/watch?v=Iwz32bEgV8o
I just want to point out that grasshopper shares the same interface with VVVV (1998) and maxforlive, a plug in inside ableton. audio mulch is yet another one that shares this interface of plugging components to each other and allows users to create their own sound instruments. vvvv is built based on vb, i believe.
so current wish list is ...
1) grasshopper recieves a sequence of commands from ableton DONE
thanks to sebastian's OSCglue vvvv patch and this one http://vvvv.org/contribution/vvvv-and-grasshopper-demo-with-ghowl-udp
after this is done, its a matter of trimming and splitting the incoming string.
2) translate numeric oscillation from ableton to change GH values
video below shows what the controll interface of both values (numbers) and the midi notes look like.
https://vimeo.com/19743303
3) midi note in = toggle GH component (this one could be tricky)
for this... i am thinking it would be great if ...it is possible to make "midi learn" function in grasshopper where one can DROP IN A COMPONENT LIKE GALAPAGOS OR TIMER and assign the component to a signal in, in this case a midi note. there are total 128 midi notes (http://www.midimountain.com/midi/midi_note_numbers.html) and this is only for one channel. there are infinite channels in ableton. I usually use 16.
I have already figured out a way to send string into grasshopper from ableton live. but problem is, how for grasshopper to listen, not just take it in, and interpret midi and cc value changes ( usually runs from 0 to 128) and perform certain actions.
Basically what I am trying to achieve is this : some time passes then a parameter is set to change from value 0 to 50, for example. then some time passes again, then another parameter becomes "previewed", then baked. I have seen some examples of hoopsnake but I couldn't tell that you can really control the values in a clear x and y graph where x is time and y is the value. but this woud be considered a basic feature of modulation and automation in music production. NVM, its been DONE by Mr Heumann. https://vimeo.com/39730831
4) send points, lines, surfaces and meshes back out to VVVV
5) render it using VVVV and play with enormous collection of components in VVVV..its been around since 1998 for the sake of awesomeness.
this kind of a digital operation-hardware connection is usually whats done in digital music production solutions. I did look into midi controller - grasshopper work, and I know its been done, but that has obvious limitations of not being precise. and it only takes 0 o 128. I am thinking that midi can be useful for this because then I can program very precise and complex sequence with ease from music production software like ableton live.
This is an ongoing design research for a performative exhibition due in Bochum, Germany, this January. I will post definition if I get somewhere. A good place to start for me is the nesting sliders by Monique . http://www.grasshopper3d.com/forum/topics/nesting-sliders
…
what they really mean by that, as in what buttons to push, so I assume it's a Windows Path entry?
2.) Modify PATH
Add the install location on the path, this is usually: C:\Program File\IronPython 2.7
But on 64-bit Windows systems it is: C:\Program File (x86)\IronPython 2.7
As a check, open a Windows command prompt and go to a directory (which is not the above) and type:
> ipy -V PythonContext 2.7.0.40 on .NET 4.0.30319.225
Tutorial on setting a Windows environmental variable (path):
http://www.computerhope.com/issues/ch000549.htm
But this fails to point out that path contains many entries already separated by semicolons so if I merely add a new variable called "path" it's likely that I will destroy existing program function. There's no info on how to just tack on another entry, and the Windows 7 edit box doesn't even show the whole collection, but one item (!), so I copied the existing path into a text editor to see the whole collection successfully and added the C:\Program Files (x86)\IronPython 2.7 entry after an added semicolon, correcting for an Enthought page typo of no 's' on the end of "Program Files". I also checked the others and many pointed to old missing directories so I deleted those entries.
...and the test fails and "ipy" is not recognized as a command, even though the path now shows up using "path" in the Windows CMD window, that is if I copy all by right clicking and pasting the stuff into a text editor to really view it all. I can run it from the source directory just fine.
The rabbit hole was indeed deep. Using the Task Manager (control-alt-delete) to kill Explorer and then Run in the menu to restart "Explorer," along with restarting the Windows CMD window however, worked. I can now invoke Iron Python ("ipy") via command line from any directory. For the "path" I edited path in the System Variables and not the User Variables. No, you don't have to type that whole crazy line above just to test the path variable, just "ipy" (and control-Z to quite IronPython) in the CMD window invoked by typing "cmd" into the Start menu search box.
From the CMD line this step did work fine:
3.) ironpkg
Bootstrap ironpkg, which is a package install manager for binary (egg based) Python packages. Download ironpkg-1.0.0.py and type:
> ipy ironpkg-1.0.0.py --install
Now the ironpkg command should be available:
> ironpkg -h(some useful help text is displayed here)
But of course Step 4 fails, giving pages of what seem to be error messages;
C:\Users\Nik>ironpkg scipy
Traceback (most recent call last):
File "C:\Program Files (x86)\IronPython 2.7\lib\site-packages\enstaller\utils.
py", line 92, in write_data_from_url
File "C:\Program Files (x86)\IronPython 2.7\Lib\urllib2.py", line 126, in urlo
pen
File "C:\Program Files (x86)\IronPython 2.7\Lib\urllib2.py", line 397, in open
File "C:\Program Files (x86)\IronPython 2.7\Lib\urllib2.py", line 509, in http
_response
...
Why can't I just download Numpy as a normal file and thus also have it easy for other users to install it when they use my scripts? This is just crazy and lazy. The Enthought developer has turned this into a computer game, with a missing registration link and then the last step spits out errors with utterly no information on how to fix it manually.
This Step 4 error is covered here:
http://discourse.mcneel.com/t/trying-to-import-numpy-in-rhino-python-but-im-getting-this-error-cannot-import-multiarray-from-numpy-core/12912/16…
Added by Nik Willmore at 2:36pm on October 11, 2015
he example file to this file so you can give it a try with any version of Honeybee that you're already using. The only requirement is to have OpenStudio installed as the component is using OpenStudio libraries to parse gbXML files. If you're using the latest version available on github the component is also available under WIP tab.
Why?
The main purpose of developing this component is to save time and effort for importing Revit models for energy and daylight analysis. It bothers me to see a lot of smart people spend a lot of time to just come up with solutions just to get the geometry from Revit to Honeybee for analysis. This component is not solving all the issue but is a first step forward. In an ideal world, the future version of Honeybee, which works both under DynamoBIM and Grasshopper should address this issue but that can take some time to be fully ready!
How?
To use this component you need to Export your Revit model as gbXML and then use the file path to load the file into Grasshopper. There are several resources available online on how to prepare the analytical model in Revit and export the gbXML file. Here is an image for importing the Revit 2017 sample model using the default settings. As you can see the model will be just as good as what your original gbXML file from Revit is.
What can be improved?
Well, there are several items that can be improved and they are mostly not on us. To get it started I add what I think are the 3 main shortcomings and my thoughts on how they can be addressed in the future. Feel free to add what you think needs to be added to this list in the comments section.
1. Revit analytical models and as the results gbXML files, by design, are not intended to be clean. Watch this presentation from the Autodesk University to see the logic behind this approach which in short is it doesn't matter for a large scale early stage energy model. Well, This will be quite a problem for studies that you can do with Honeybee. Included but not limited to daylight and comfort analysis.
The best solution that I can think of, until Autodesk fixes their exporter, is to use Revit Rooms and Spaces and generate a clean model from the scratch. We have already tried this approach in Revit but since the Revit API doesn't provide access to Room openings we had a very hard time to get it to work.
That's why that I opened an idea on Revit ideas to get over this issue. With your support we already have 81 votes, but it hasn't been enough to make them to consider the idea for an official review. If you haven't voted already and you think this will be a helpful feature take a moment and vote so we can have it implemented at some point in the future.
2. There is no way (that I know) to export only part of the model. The way export gbXML is set up in Revit is to export the whole model once together. As a result, if you have a huge model with 100 rooms and you want to get one of the rooms into Honeybee using this component you have to export the whole model, which can take some time, and then import them all back into Grasshopper. To partially address this issue I added an input to the component that allows you input a list of names for rooms that you're interested to be loaded into Grasshopper. You can use the name of the room/space in Revit as an input for the component.
3. The component doesn't import adjacencies, loads, schedules and HVAC systems. I wasn't able to export a gbXML file from Revit with any of this data except for the adjacency, but even if you can do that, the component currently can only import geometries and constructions. I hope we get access to 1 and so we don't have to use the xml file approach at all, but if that takes a very long time then we will add these features to the component.
Happy 2017!
Mostapha…
le and grasshopper timer to simplify simulation control. Double click the main Kangaroo component to open this remote. There are buttons for Stop(reset), Play, Pause, and Step (moves the simulation forward one iteration).
Line-line force - allows interaction between line segments - they are treated as rigid cylinders. As with springs, there are settings for offset and rest distance, so this can be used to simulate colliding rods, and also for keeping cylinders tangent to one another (can be used for reciprocal structures).
Gear simulator - collision between curves in a plane, can be used for various mechanical simulations - cams, gears, rack and pinions etc.
Developablize force - adjusts vertices of a mesh locally, to make angles around each interior vertex sum to 2*Pi, so the mesh can be unfolded to a flat sheet without stretching.
Volume dependent pressure force - allows you to set a rest volume for a mesh instead of just a fixed pressure. When combined with Laplacian smoothing for area minimization, this can be used to optimize for CMC (constant-mean-curvature) surfaces. It will also work on open meshes.
Translation lock - maintains a fixed relationship between a pair of points. This can be used to enforce periodic boundary conditions for TPMS.
Equalize angles force - given a set of angles (defined by 3 points each), this tries to adjust them all to become equal.
Mirror symmetry force - can be used to minimize curvature variation, and optimize for higher order curve continuity. It can also be used for simulating torsional resistance in curved rods.
True minimal surface relaxation - Laplacian smoothing force now includes an option for cotangent weighting, which optimizes for zero mean curvature, unlike spring based methods, or uniform weighted Laplacian smoothing which only roughly approximate this.
Fast sphere collide - allows much faster collision detection between large numbers of spheres. By placing these spheres at the vertices, this can also be used for collision between meshes.
Force-density element - an experimental one, more on this later
Projected-force - adjusts its strength so the component of the force in a given direction stays constant.
New mesh tools:
WarpWeft - sorts the edges of a quad mesh into warp and weft directions. This can be used to assign them different stiffness in fabric form-finding.
Checkerboard - sort the faces of a mesh into 2 lists so that 2 faces of the same colour are never adjacent.
MeshDirection - sorts the vertices of a quad mesh to give it a sort of u-v directionality
Refine Strips - subdivision in one direction only - can be used to generate developable strips
Stripper - separates out the strips of quads from a larger mesh
Unroller - unfolds a quad strip to flat without stretching
MeshMap - maps points from one mesh to another (can be used together with circle-packing to generate conformal mappings)
Reciprocal structure - generates starting geometry for a reciprocal structure from any input mesh (using the Plankton mesh library *Note* If you already have the Plankton components installed, you will need to update to version 0.3.0, which is available from here)
ReMesher - adjusts the connectivity of a mesh by flipping, splitting and collapsing edges to make all edge lengths closer to a target value
Diagonalize - creates a new face for every edge of the original mesh. Can be used on quad meshes to easily convert to a diagrid.
Refine - simple non-smoothing subdivision, splitting quads into 4 quads, and triangles into 4 triangles
QuadDivide - subdivide quads by any number squared, not just powers of 4
Corners - finds the corner vertices of a quad mesh
ByParent - simple quad subdivision, keeping the output grouped by parent face.
User objects:
The download comes with an increased collection of user objects to simplify setting up common simulation types - Including a simple to use origami simulator, a reciprocal structure generator, and a tool to generate compact circle packings from a CP mesh.
General:
Geometry input now accepts polylines and straight curves.
Hinges can now be fold completely flat in both directions.
Various other minor bug fixes and speed improvements (including much faster removeDuplicatePoints/Lines components)
*****
I've not yet updated all the documentation and example files to reflect this new version, but over time I will keep posting here with new demos and explanation of all these new features. I'll try and add a few new examples each week. Vote in the comments below if there is a feature mentioned above that you're particularly keen to hear more about soon.
No doubt there are still some bugs to be discovered. If something isn't working the way you expect or want it to, please post in this forum (ideally with a description or sketch of what you think should be happening, and a clear description of what happens instead and any error messages).
There are also some more new features that weren't quite ready to make it into this release, but are on the way shortly...
Kangaroo remains completely free, for personal, academic, and commercial use. I'm always interested to hear about projects done using it, and suggestions for improvements or additions.
Daniel
…
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.
…