:
______________________________________________________________________
As most of you know by now, Grasshopper will be included in Rhino 6 for Windows. We are almost finished with the Grasshopper in Rhino 6 development and you are invited to try it.
There are many enhancements, including:
High DPI displays are now supported.
Compatible with existing Grasshopper plug-ins.
New components including Make2D, Bend, Flow, Maelstrom, Splop, Splorph, Stretch, Taper, and Twist...
GhPython is now included. It features its own GHA compiler and a major node-in-code speed up.
Stable development target: Your plug-ins continue to work each minor Grasshopper upgrade.
RhinoCommon enhanced: More Rhino core functionality is accessible from within Grasshopper.
Developer documentation is online with guides and API references.
Now:
Download the current Rhino WIP for Windows
Try all your existing Grasshopper definitions
Report any problems you find here...
We want to make sure this new Grasshopper works for you. If you have any issues, David needs to hear from you very soon.
Thank you,
- Bob
Visit Grasshopper at: http://www.grasshopper3d.com/?xg_source=msg_mes_network
______________________________________________________________________
So...
Any news about OS X version? Many of us won't use Parallels or whatever win emulator or have a win machine nearby.
Hope you are working at it.
Cheers
gbrl
…
Added by Gabriel Netto at 3:44pm on October 29, 2016
size component supported only ground PV panels and angled roof PV panels.
Download the newest PV SWH system size component from here (Click on "View Raw" to download it. Then move the downloaded .ghuser file to File->Special Folders->User Objects Folder, an confirm to overwrite it with previously located one).
Just a few opinions on the project you are currently working on:This kind of fixed, non-transparent (overhang) PV panels attached to a building facade are vert convenient for locations with higher latitudes.The reason for this is because they (fixed overhang PV panels) are dimensioned according to the sun position at summer solstice. Elevation angles on summer solstice at higher latitude locations are lower, than those of lower latitude locations.Due to Incheon's low latitude (37), you will get rather short length of the PV panels* : less than 10 centimeters (0.097 meters in the attached .gh file below). As you have mentioned, Galapagos needs to be used too.I will just mention some of the good and bad ways in which the upper issue could be somewhat avoided:1) Increasing the vertical distance between PV panels (PV panels appear above every second window).2) Increase the tilt angle. This will increase the length of PV panels also, but will decrease the final annual AC energy output.An example of this solution has been applied at FKI building in Seoul (latitude: 37N):I already did some tests (with tilt angles: 40, 45, 55) and this does not seem like a good solution, though.3) Shrinking the "sun window" by using the minimalSpacingPeriod_ input. In Photovoltaics, a planner is suppose to make the 9h to 15h part of the sun window free of any obstructions. If you try to decrease the "sun window" to 10 to 14h, the length of your PV panels will increase. You can try to experiment a little bit with this (set your minimalSpacingPeriod_ to 21th of June 10 to 14hours). In general, shrinking the sun window on summer solstice is not a good principle during planning.4) Using tracking PV panels, not fixed ones. But Ladybug Photovoltaics components do not support this kind of PV systems. They only support fixed ones.I would personally go with the first option. You can also experiment with the second and third one.Comment back if you have any other questions.-----------------------* By "length of the PV panels" I mean the: tiltedArrayHeight_ input of the PV SWH system size component.…
ents will react to sensors, creating a range of different lighting and spatial effects that will trigger further movement and produce a feedback loop of behaviour and response. To accommodate this responsiveness, the design will be developed using parametric associative modeling, processing, arduino, and digital fabrication using the CNC and Laser Cutters. Students can both develop completely new designs, and/or work on the evolution of the Workshop 1 Supple Pavilion project.
The Visiting School will return to Barracão Escola de Carnaval to evolve the design of the migrating Pavilions, their contents and their context, exploring a design philosophy of interactive event design and the production of a creative fusion of high-tech design generation and fabrication with low-tech redefinition of Carnival-float artisan techniques, paraphernalia, and materials. We will work in the immense and creative Pimpolhos warehouse, collaborating with local artisans of several Samba Schools in the post-industrial, partly-derelict Porto do Rio area, (the birthplace of the Carnival and Samba), introducing digital fabrication techniques. The goal is to create interventions for micro-venues and cultural events that express the identity of the Samba culture within the `Porto Maravilha` planning.
Instruction for the Supple Pavilions workshop series will be led by Rob Stuart-Smith of Kokkugia, Lawrence Friesen of Generative Geometry, Ivan Ivanoff of Interactive Art Estado Lateral Media Lab, Toru Hasegawa of Proxy, with Anne Save de Beaurecueil and Franklin Lee of SUBdV, along with other AA tutors, the Pimpolhos Artistic Directors, and Carnival float-fabricators. Each workshop will provide an introduction to computational design (Grasshopper, Processing and Arduino) and digital fabrication, no previous computational experience is required. Students taking part in multiple workshops will have access to advanced computation instruction. This workshop will produce 1:1 prototyping, exploring the structure and transformations of the pavilions. Final fabrication and assemblage will occur in July.
The workshop is open to architecture and design students and professionals worldwide. Participants can take part in one or more workshops, with fee discounts offered to those interested in multiple workshops.
…
he results are accurate enough.Good to go!Current working directory is set to: C:\002_VIDEO\02_UNI\TU_GRAZ\01_DISSERTATION\02_RESEARCH\08_POMODORO\01_SIMULATION_MODEL/03_HONEYBEE\VF_00\gridBasedSimulation\start cmd /c C:\Users\paratufello\AppData\Roaming\Ladybug\unnamed\annualSimulation\unnamed_7_DS.batWMIC PROCESS get CommandlineWMIC PROCESS get CommandlineWMIC PROCESS get Commandlinestart cmd /c C:\Users\paratufello\AppData\Roaming\Ladybug\unnamed\annualSimulation\unnamed_7_DS.batWMIC PROCESS get CommandlineWMIC PROCESS get CommandlineWMIC PROCESS get Commandlinestart cmd /c C:\Users\paratufello\AppData\Roaming\Ladybug\unnamed\annualSimulation\unnamed_7_DS.batWMIC PROCESS get CommandlineWMIC PROCESS get CommandlineWMIC PROCESS get Commandlinestart cmd /c C:\Users\paratufello\AppData\Roaming\Ladybug\unnamed\annualSimulation\unnamed_7_DS.batWMIC PROCESS get CommandlineWMIC PROCESS get CommandlineWMIC PROCESS get Commandlinestart cmd /c C:\Users\paratufello\AppData\Roaming\Ladybug\unnamed\annualSimulation\unnamed_7_DS.batWMIC PROCESS get CommandlineWMIC PROCESS get CommandlineWMIC PROCESS get Commandlinestart cmd /c C:\Users\paratufello\AppData\Roaming\Ladybug\unnamed\annualSimulation\unnamed_7_DS.batWMIC PROCESS get CommandlineWMIC PROCESS get CommandlineWMIC PROCESS get Commandlinestart cmd /c C:\Users\paratufello\AppData\Roaming\Ladybug\unnamed\annualSimulation\unnamed_7_DS.batWMIC PROCESS get CommandlineWMIC PROCESS get CommandlineWMIC PROCESS get Commandlinestart cmd /c C:\Users\paratufello\AppData\Roaming\Ladybug\unnamed\annualSimulation\unnamed_7_DS.batWMIC PROCESS get CommandlineWMIC PROCESS get CommandlineWMIC PROCESS get Commandlinestart cmd /c C:\Users\paratufello\AppData\Roaming\Ladybug\unnamed\annualSimulation\unnamed_7_DS.batWMIC PROCESS get CommandlineWMIC PROCESS get CommandlineWMIC PROCESS get CommandlineRuntime error (IndexOutOfRangeException): index out of range: 0Traceback: line 271, in script…
is set to: C:\002_VIDEO\02_UNI\TU_GRAZ\01_DISSERTATION\02_RESEARCH\08_POMODORO\01_SIMULATION_MODEL/03_HONEYBEE\VF_00\gridBasedSimulation\start cmd /c C:\Users\paratufello\AppData\Roaming\Ladybug\unnamed\annualSimulation\unnamed_7_DS.batWMIC PROCESS get CommandlineWMIC PROCESS get CommandlineWMIC PROCESS get Commandlinestart cmd /c C:\Users\paratufello\AppData\Roaming\Ladybug\unnamed\annualSimulation\unnamed_7_DS.batWMIC PROCESS get CommandlineWMIC PROCESS get CommandlineWMIC PROCESS get Commandlinestart cmd /c C:\Users\paratufello\AppData\Roaming\Ladybug\unnamed\annualSimulation\unnamed_7_DS.batWMIC PROCESS get CommandlineWMIC PROCESS get CommandlineWMIC PROCESS get Commandlinestart cmd /c C:\Users\paratufello\AppData\Roaming\Ladybug\unnamed\annualSimulation\unnamed_7_DS.batWMIC PROCESS get CommandlineWMIC PROCESS get CommandlineWMIC PROCESS get Commandlinestart cmd /c C:\Users\paratufello\AppData\Roaming\Ladybug\unnamed\annualSimulation\unnamed_7_DS.batWMIC PROCESS get CommandlineWMIC PROCESS get CommandlineWMIC PROCESS get Commandlinestart cmd /c C:\Users\paratufello\AppData\Roaming\Ladybug\unnamed\annualSimulation\unnamed_7_DS.batWMIC PROCESS get CommandlineWMIC PROCESS get CommandlineWMIC PROCESS get Commandlinestart cmd /c C:\Users\paratufello\AppData\Roaming\Ladybug\unnamed\annualSimulation\unnamed_7_DS.batWMIC PROCESS get CommandlineWMIC PROCESS get CommandlineWMIC PROCESS get Commandlinestart cmd /c C:\Users\paratufello\AppData\Roaming\Ladybug\unnamed\annualSimulation\unnamed_7_DS.batWMIC PROCESS get CommandlineWMIC PROCESS get CommandlineWMIC PROCESS get Commandlinestart cmd /c C:\Users\paratufello\AppData\Roaming\Ladybug\unnamed\annualSimulation\unnamed_7_DS.batWMIC PROCESS get CommandlineWMIC PROCESS get CommandlineWMIC PROCESS get CommandlineRuntime error (IndexOutOfRangeException): index out of range: 0Traceback: line 271, in script…
dy for a wall where we want to analyze its openings. I made a parametric wall that then get's analyzed with different geometries and the idea was just to leave it there for the weekend as it morphed through different iterations. However, after successfully running a test simulation on my pc (just with one iteration), it fails to run the same test on the workplace computer. Any help would be greatly apprecated! Here is the following error:
Sorry! But the number of available CPUs on your machine is 4.
Honeybee set the number of CPUs to 4.
Grid-based Radiance simulation
The component is checking ad, as, ar and aa values. This is just to make sure that the results are accurate enough.
Good to go!
Current working directory is set to: C:\ladybug\Parametric_Shading_Wall\psw_z0.25_t.025_y.2_r90_m3_lux\gridBasedSimulation\
Failed to read the results!
rtrace: fatal - (psw_z0.25_t.025_y.2_r90_m3_lux_RAD.oct): truncated octree
rtrace: fatal - (psw_z0.25_t.025_y.2_r90_m3_lux_RAD.oct): truncated octree
rtrace: fatal - (psw_z0.25_t.025_y.2_r90_m3_lux_RAD.oct): truncated octree
rtrace: fatal - (psw_z0.25_t.025_y.2_r90_m3_lux_RAD.oct): truncated octree
Runtime error (PythonException): Failed to read the results!
rtrace: fatal - (psw_z0.25_t.025_y.2_r90_m3_lux_RAD.oct): truncated octree
rtrace: fatal - (psw_z0.25_t.025_y.2_r90_m3_lux_RAD.oct): truncated octree
rtrace: fatal - (psw_z0.25_t.025_y.2_r90_m3_lux_RAD.oct): truncated octree
rtrace: fatal - (psw_z0.25_t.025_y.2_r90_m3_lux_RAD.oct): truncated octree
PS. It says to see line 336…
answer further on Friday.
The "ghdoc" variable and rhinoscriptsyntaxThe ghdoc variable is provided by the component if you select it as "target".You might ask yourself: "why do we need it"?Its use comes from the very design of the established RhinoScript library. This library is imperative, which means it is build from a set of procedures or functions that act on various geometrical types. Additionally, there is one level of indirection: most of the time, the user does not work with the geometry itself in the variable, but rather with Guid of geometry that is present in a document. This is exactly what ghdoc is: it is the document that the RhinoScript library always implicitly targets with all AddSomething() calls (for example, AddLine()).
Based on this comment...RhinoScript use within GhPython may be less idealThat comment is from a previous version of this component that did not have the ghdoc yet.With the ghdoc variable, the standard Rhino document target of RhinoScript is replaced, therefore we can use Grasshopper while leaving the Rhino document unchanged. This saves uncountable Undo's, and makes it easy to structure ideas through the definition graph
...is the rhinoscriptsyntax target irrelevant if using solely RhinoCommon classesYes. If you create class instances (objects), you will need to create also your own collection objects to store them (mostly lists, trees). You can imagine the ghdoc as being an alternative to them, just that you do not access data by index (number), but by Guid. So you can use the RhinoScript or the RhinoCommon libraries independently or mix them. The RhinoScript implementation in Rhino is open-source and is all written in RhinoCommon. Also the ghdoc implementation is open-source, and is here.
RhinoScript and/or RhinoCommon objects which are not recognized as valid Grasshopper geometryYes, sure, Grasshopper handles only a portion of all available types. Basically, unhandled types are all the types that do not exists in the 'Params' tab. For example, there is no textdot and no leader, so on line 149 there is a throw statement and all TextDot calls (about line 350) are commented out. When/if Grasshopper one day will support these types, these calls will be implemented.
DataTreeHere is a small sample. However, I think that 80% of the times it is not necessary to program for DataTrees, as the logic itself can be applied per-list and Grasshopper handles list-iteration.
I hope this helps,
- Giulio_______________giulio@mcneel.comMcNeel Europe…
ger at the scale of rooms, walls and atria, but that of cells, grains and vapour droplets. Rather than the flow of people, services, or construction schedules, the focus becomes the flow of light, vapour, molecular vibrations and growth schedules: design from the inside out.
The sg2012 challenge, Material Intensities, is intended to dissolve our notion of the built environment as inert constructions enclosing physically sealed spaces. Spaces and boundaries are abundant with vibration, fluctuating intensities, shifting gradients and flows. The materials that define them are in a continual state of becoming: a dance of energy and information.Material potential is defined by multiple properties: acoustical, chemical, electrical, environmental, magnetic, manufacturing, mechanical, optical, radiological, sensorial, and thermal. The challenge for sg2012 Material Intensities is to consider material economy when creating environments, micro-climates and contexts congenial for social interaction, activities and organisation. This challenge calls for design innovation and dialogue between disciplines and responsibilities.sg2010 Working Prototypes strove to emancipate digital design from the hard drive by moving from the virtual to the actual in wrestling with the tangible world of physical fabrication. sg2011 Building the Invisible focused on informing digital design with real world data. sg2012 Material Intensities strives to energise our digital prototypes and infuse them with material behaviour. They have the potential to become rich simulations informed by the material dynamics, chemical composition, energy flows, force fields and environmental conditions that feed back into the design process.
More information can be found at http://www.smartgeometry.org
sg2012 take place at Rensselaer Polytechnic Institute, Troy, in upstate New York from 19-24 March 2012. The Workshop and Conference will be a gathering of the global community of innovators and pioneers in the fields of architecture, design and engineering.
The event will be in two parts, a four day Workshop 19-22 March, and a public conference beginning with Talkshop 23 March, followed by a Symposium 24 March. The event follows the format of the highly successful preceding events sg2010 Barcelona and sg2011 Copenhagen.…
ort and export from the images below and also from the HELP file of DB in attachments (Page 71: Importing Geometric Data; Page 78-80: Import 3 - D CAD Data). In their HELP file, they mention about "import geometric data".
However, regarding the input of schedules, loads, constructions and etc., DB normally uses "Component " and "Template" (Page 29: Templates And Components; Page 591: Templates; Page 533: Components). "Templates" are databases of typical generic data, including Activity templates, Construction templates, Glazing templates, Facade templates, HVAC templates, Location Templates, and etc. "Component " are databases of individual data items (e.g. a construction type, material, window pane).
Both "Component " and "Template" are allowed to be imported and exported by using "Import / Export library data" command (.ddf format - DB Database File; Page 734: Import Components/Templates, Export Components/Templates). DB also allows us to build up our own libraries of templates and components (Page 731: Library Management; Page 733: Template Library Management).
In order to import both geometric information and other information related to schedules, loads, constructions and etc. from GH to BD, we supposed the following two ways:
1. GH(HB+GB) --> gbXML (both geometric and "Component " and "Template" information) --> DB
This is the way we most prefer. We did see information related to schedules, loads, constructions encoded in the gbXML file generated by GB, but still do not know the reason why DB did not take this information (I also mentioned this in Q6 within the gh file). We assume this might because the gbXML file we create encodes the schedules based on a different template / schema than the one DB expects. We also post this question to the DB forum for help.
(http://www.designbuilder.co.uk/component/option,com_forum/Itemid,25/page,viewtopic/p,13755/#13755)
2. GH(HB+GB) --> gbXML (geometric information only) + .ddf ("Component " and "Template" information only) --> DB
If the first way doesn't work and DB only takes geometric information from the gbXML, then we might think of the other way - generating the .ddf files from GH(HB+GB) to pass the schedule, load and construction information to DB.
I was wondering if it is feasible for HB and GB to have this function? And what is your suggestion to achieve this?
In addition, we notice that DB can export XML files (not gbXML), so we are trying to figure out if DB also accepts / reads the XML file. If so, we might be able to convert the gbXML (with both geometric and schedule information) to XML. What do you think about that?
Thank you again for all your help!
Best,
Ding
DB import
DB export
Template libraries
Component libraries
…
ay how many valid permutations exist.
But allow me to guesstimate a number for 20 components (no more, no less). Here are my starting assumptions:
Let's say the average input and output parameter count of any component is 2. So we have 20 components, each with 2 inputs and 2 outputs.
There are roughly 35 types of parameter, so the odds of connecting two parameters at random that have the same type are roughly 3%. However there are many conversions defined and often you want a parameter of type A to seed a parameter of type B. So let's say that 10% of random connections are in fact valid. (This assumption ignores the obvious fact that certain parameters (number, point, vector) are far more common than others, so the odds of connecting identical types are actually much higher than 3%)
Now even when data can be shared between two parameters, that doesn't mean that hooking them up will result in a valid operation (let's ignore for the time being that the far majority of combinations that are valid are also bullshit). So let's say that even when we manage to pick two parameters that can communicate, the odds of us ending up with a valid component combo are still only 1 in 2.
We will limit ourselves to only single connections between parameters. At no point will a single parameter seed more than one recipient and at no point will any parameter have more than one source. We do allow for parameters which do not share or receive data.
So let's start by creating the total number of permutations that are possible simply by positioning all 20 components from left to right. This is important because we're not allowed to make wires go from right to left. The left most component can be any one of 20. So we have 20 possible permutations for the first one. Then for each of those we have 19 options to fill the second-left-most slot. 20×19×18×17×...×3×2×1 = 20! ~2.5×1018.
We can now start drawing wires from the output of component #1 to the inputs of any of the other components. We can choose to share no outputs, output #1, output #2 or both with any of the downstream components (19 of them, with two inputs each). That's 2×(19×2) + (19×2)×(19×2-1) ~ 1500 possible connections we can make for the outputs of the first component. The second component is very similar, but it only has 18 possible targets and some of the inputs will already have been used. So now we have 2×(18×2-1) + (18×2-1)×(18×2-1) ~1300. If we very roughly (not to mention very incorrectly, but I'm too tired to do the math properly) extrapolate to the other 18 components where the number of possible connections decreases in a similar fashion thoughout, we end up with a total number of 1500×1300×1140×1007×891×789×697×...×83×51×24×1 which is roughly 6.5×1050. However note that only 10% of these wires connect compatible parameters and only 50% of those will connect compatible components. So the number of valid connections we can make is roughly 3×1049.
All we have to do now is multiply the total number of valid connection per permutation with the total number of possible permutations; 20! × 3×1049 which comes to 7×1067 or 72 unvigintillion as Wolfram|Alpha tells me.
Impressive as these numbers sound, remember that by far the most of these permutations result in utter nonsense. Nonsense that produces a result, but not a meaningful one.
EDIT: This computation is way off, see this response for an improved estimate.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
Added by David Rutten at 12:06pm on March 15, 2013