y using the Honeybee_Update Honeybee component.
The video below (best viewed in full-screen mode) provides an idea of what these components are capable of being used for:
The video below shows how these components can be used in an existing Honeybee project (for additional links please open this video in youtube):
I have uploaded two examples as Hydra files that show how these components can be used for grid-point and image-based simulations:
Example1 : Grid Point Calculations
Example2: Image based simulation
Finally, a more esoteric application is demonstrated in this video:
These components are still in the beta-testing stage. Some of the limitations of the components are:
1. Only Type C photometry IES files are supported at present.
2. Rhino is likely to get sluggish if there are too many luminaires (i.e. light fixtures) present in a scene.
3. Due to the spectral limitations of the ray-tracing software (RADIANCE), simulations involving color mixing might not be physically realizable.
Additional details about photometric and spectral calculations are probably an overkill for this forum. However, I'd be glad to answer any related questions. Please report any bugs or request new features either on this forum or on Github.
Mostapha, Leland Curtis, Reinhardt Swart and Dr. Richard Mistrick provided valuable inputs during the development of these components.
Thanks,
Sarith
Update 16th January 2017:
An example with some new components and bug fixes since the initial release announcement can be found here
…
greatly appreciate it!!
You can write the number of the question and write your answer next to it, example:
1) a
2) c
3) a) Washington University in St. Louis
4) 2 weeks (1week+1week shipping)
5) 130
6) b
7) b
The survey questions are as follows:
1)
Did you 3D print before?
5)
How much did it cost (in dollars)?
a.
Yes, for a school project
a.
Between 20 & 50
b.
Yes, for a personal project
b.
Between 50 & 80
c.
Between 80 & 120
2)
Print size
d.
Please specify if otherwise: _____ dollars
a.
Between 2 & 6 cubic inches
b.
Between 6 & 12 cubic inches
6)
Do you think the price was expensive?
c.
Between 12 & 20 cubic inches
a.
Not at all
d.
Please specify if otherwise: ____cubic inches
b.
A little bit expensive
c.
Very expensive
3)
Where did you print your object?
a.
School
7)
Were you satisfied with the printed object?
b.
Outside school: _________________
a.
Yes, it was a great print without problems
b.
Not bad, some issues
4)
How long did it take to print?
c.
I was not satisfied, very bad quality
a.
___ days
b.
___ weeks
Thank you very much to all!!
PS: If you did many 3D prints, you can post multiple answers.
Wassef…
whole design intent, but this is what Inventor is good at. The way it packages bits of 'scripted' components into 'little models' that can be stored and re-assembled is central to MCAD working.
The Inventor model shown is almost 5 years old. We don't model like that any more, however it does offer a good idea of general MCAD modeling approaches.
iParts is useful in certain situations, it could've been useful in the above model, its usefulness is often in function of the quantity of variants/configurations.
So much is scripted in GH, maybe it should also be possible to script/define/constrain/assist the placement/gluing of the results?
...
Starting point: I think we are talking across purposes. AFAIK, the solving sequence of GH's scripted components is fixed. It won't do circular dependencies... without a fight. The inter-component dependencies not 'managed' like constraints solvers do for MCAD apps.
Components and assemblies are individual files in MCAD.
Placement of these within assemblies in MCAD is a product of matrix transforms and persistent constraints. There is no bi-directional link, the link is unidirectional (downflow only), because of the use of proxies.
Consequently, scripting the placement of components is irrelevant in GH, unless you decide that each component needs to be contained in its own separate file.
This also brings up the point that generating components and assemblies in MCAD is not as straightforward. In iParts and iAssemblies, each configuration needs to be generated as a "child" (the individual file needs to be created for each child) before those children can be used elsewhere.
You notice the dilemma, if you generate 100 parts, and then you realize you only need 20, you've created 80 extra parts which you have no need for, thus generating wasteful data that may cause file management issues later on.
GH remains in a transient world, and when you decide to bake geometry (if you need to at all), you can do that in one Rhino file, and save it as the state of the design at that given moment. Very convenient for design, though unacceptable for most non-digital manufacturing methods, which greatly limits Rhino's use for manufacturing unless you combine it with an MCAD app.
One of the reasons why the distributed file approach makes perfect sense in MCAD, is that in industry you deal with a finite set of objects. Generative tools are usually not a requirement. Most mechanical engineers, product engineers and machinists would never have any use for that.
The other thing that MCAD apps like Inventor have, is the 'structured' interface that offers up all that setting out information like the coordinate systems, work planes, parameters etc in a concise fashion in the 'history tree'. This will translate into user speed. GH's canvas is a bit more freeform. I suppose the info is all there and linked, so a bit of re-jigging is easy. Also, see how T-Flex can even embed sliders and other parameter input boxes into the model itself. Pretty handy/fast to understand, which also means more speed.
True. As long as you keep the browser pane/specification tree organized and easy to query.
:)
Would love to understand what you did by sketching.
I'll start by showing what was done years ago in the Inventor model, and then share with you what I did in GH, but in another post.
Let's use one of the beams as an example:
We can isolate this component for clarity.
Notice that I've highlighted the sectional sketch with dimensions, and the point of reference, which is in relation to the CL of the column which the beam bears on. The orientation and location of the beam is already set by underlying geometry.
Here's a perspective view of the same:
The extent of the beam was also driven by reference geometry, 2 planes offset from the beam's XY plane, driven by parameters from another underlying file which serves as a parameter container:
Reference axes and points are present for all other components, here are some of them:
It starts getting cluttered if you see the reference planes as well:
Is I mentioned earlier, over time we've found better ways to define and associate geometry, parameters, manage design change, improving the efficiency of parametric models. But this model is a fair representation of a basic modeling approach, and since an Inventor-GH comparison is like comparing apples and oranges anyways, this model can be used to understand the differences and similarities, for those interested.
I haven't even gotten to your latest post yet, I will eventually.…
Added by Santiago Diaz at 10:36am on February 26, 2011
of the new challenges presented to the society and architecture in Portugal. With technological developments, tools once limited to not creative areas begin to be part of the everyday life of students in University Architecture Laboratories and change its design processes. The architecture design methods are changing rapidly with the introduction of CAD-CAM software’s. In recent years, new software’s have been available for 3D representation and digital fabrication, which have allowed creating new ways of interacting with the computer and architecture. Contemporary architecture in its various scales, seeks greater flexibility, adaptability and interactivity taking into account both the means and goals of kinetic systems. Thus, it is essential to the creative industry players to acquire new knowledge about the latest technological innovations and how they can solve some of the problems and challenges of today’s society.
The workshop will explore the use of Grasshopper, Firefly and Arduino as creative and technical tools in all the design process, to simulation and prototype 3D interactive architecture solutions.
The theoretical and practical workshop (64 hours) taught in English and Portuguese, will be composed of two modules: (1) LS_01: Firefly +Grasshopper + Arduino and Scale Model Fabrication; (2) LS_02: Design Studio – Discursive Wall.
This workshop is intended for students and professionals from different areas of knowledge, (architecture, design, fine arts, engineering, music and programming) who are interested in the process of design: from ideation to prototyping. The participants will generate scale models.
Registration is limited to 20 participants with or without software knowledge. Participants will work individually and in group. Participants must take their own laptops to the workshop. Registrants should complete the form by 28 February 2012. Once registered, you will receive an email confirming your acceptance.
Questions or doubts contact us:
alivingsystem@gmail.com
…
Added by Brimet Silva at 7:07pm on January 16, 2012
rendo posizioni lavorative fino a qualche tempo fa impensabili. Questo nuovo approccio ha infatti la caratteristica di avvicinarsi alla programmazione informatica, ma con un approccio facilitato grazie ai componenti visuali.Hai bisogno di un motivo in più per usare Grasshopper? Eccolo! Trattandosi di uno strumento ancora in fase di testing (anche se perfettamente funzionante) l’applicativo è completamente gratuitoScarica la tua versione e inizia subito ad usarlo!Corsi certificatiLe lezioni sono tenute da Antoni(n)o Marsala, docente certicato McNeel, con alle spalle oltre 5 anni di esperienza nell’insegnamento di Rhinoceros. Negli ultimi anni abbiamo tenuto in grande considerazione l’evolversi di questo plugin e abbiamo deciso di investire sulle sue potenzialità.Nel Febbraio del 2011, grazie ad Antoni(n)o Marsala, è uscito Algoritmi Generativi, edizione italiana del libro di Zubin Khabazi Generative Algorithms with Grasshopper. Entrami sono scaricabili gratuitamente e rappresentano dei validi strumenti per capire il mondo di Grasshopper.Da diversi mesi inoltre, il Mandarino BLU, ha attivato una collaborazione con La Bottega di Galileo di Pisa, officina del libero scambio di idee, presentando dei progetti formativi post universitari, per coloro che vogliono entrare nel mondo della progettazione di nuova generazione.Dalla collaborazione con Multiverso, nasce invece un progetto formativo più ampio sviluppato a Firenze in via Campo d’Arrigo 40rLeggi il nostro programma didattico o scarica la versione in pdf…
2:
-Developing the winning design into a working application -Testing -Beers and BBQ
Details:
-Tutors: Gregory Epps, RoboFold founder, Florent Michel RoboFold software developer. -See previous workshops here. -Download Poster here.
-Please install Rhino5 and Grasshopper and Godzilla before this event.
-No previous experience with Grasshopper necessary. -Hours: 10am-6pm. -Location details: here.
***COMPETITION: THE BEST USE OF GODZILLA GETS A FREE PLACE***
Judged on creativity and practicality. Submit your name, association and a link to your video to robots@robofold.com We add an additional place for the winner. Flights, accommodation etc are not free...
Join us for the first Godzilla robot workshop - experiment with the easiest robot software on the Grasshopper platform.
More details and resources on: http://www.grasshopper3d.com/group/godzilla
Workshop Fee:
Student: £ 399
Professional: £ 599…
dellatore nurbs, Rhinoceros. Attraverso una serie di esercizi che si svolgeranno durante il corso, si spiegheranno i temi fondamentali che stanno alla base della modellazione generativa e del design parametrico.
Il corso è rivolto a chi ha già una familiarità minima con la modellazione attraverso Rhinoceros e vuole ampliare le proprie competenze verso il campo della modellazione parametrica e generativa, e si terrà da martedì 22.10.2016 a giovedì 24.10.2016 – dalle 10:00 alle 17:00.
Potete scaricare qui il PROGRAMMA DEL CORSO.
Il calendario dei corsi è consultabile qui.
VEGA Parco Scientifico TecnologicoVia della Libertà 12 – VeneziaEdificio Porta dell’Innovazione – Piano Terra
Per iscriversi al corso è necessario essere registrati al sito.Per tesserarvi al Fablab Venezia, diventare maker, usufruire dei vantaggi, clicca qui.
Le iscrizioni chiuderanno giovedì 17.11.2016.
Il corso ha un costo di 270,00 euro + iva (329.40) per i tesserati e convenzionati,per i non tesserati il costo sarà di 330,00 + iva (402.60) euro.
Vuoi risparmiare? Iscriviti entro tre settimane dalla data di inizio corso, usufruirai automaticamente dell’offerta “early bird” ovvero uno sconto del 20% sul costo a te dedicato.
Per iscriversi:
http://www.fablabvenezia.org/parametric-design-with-grasshopper/…
it could look like this:
Once you're told it's to do with flattening data structures called 'trees' it becomes obvious what it means and very easy to remember. If you had to guess what it meant before you were told about trees I'm not sure what you'd make of it. Perhaps something to do with downloading? Downward pointing arrows are often associated with downloading things.
If I compress the tree image the arrow can be above it, but now the tree doesn't look like a tree any more:
Unless you've seen it before on another icon and you know that shape represents a data tree in Grasshopper.
I in fact did use a downward pointing arrow to represent flatten in the parameter post-processes:
These icons only have 10x10 pixels so anything beyond a single, simple shape cannot be represented so I couldn't go with the stump.
I'm not particularly hesitant to change the UI from version to version. I know it annoys some people and I know that some tutorials and course materials will become outdated because of it. But while GH is in alpha mode I think it is more important to try and figure out what interface works best. I'm not particularly impressed by the improvement of the tree+arrow icon, because even if it immediately conjures up the words "Flatten Tree" in your mind, you still don't know what to make of it unless you already know about data trees and what it means to flatten them.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
laxation have been around much longer than any of the tools you mention, or indeed Rhino itself. A particularly well known one is Ken Brakke's Surface Evolver from over 20 years ago. Of the examples listed, some of them were inspirations when starting Kangaroo in 2009, and I've always tried to acknowledge those. (of course, surface relaxation is only one part of what Kangaroo is about)
I also was helped by conversations with many people, including Moritz as you mention, and especially yourself with the coding. Indeed the .Net class you ran back then for McNeel, as well as the other correspondence in your own time was really useful in getting started - thanks again!
As for mesh relaxation not being 'not so difficult', well - for sure there are many implementations of these things out there. Similarly there are dozens of examples of subdivision implementations (Andrew Heumann even showed you don't need to code anything, but can do it with standard grasshopper components), but let's not start being too dismissive of each other's work, hey ? Of course there's a lot more to making a flexible and useful tool than individual algorithms - making them part of a larger framework or system of tools makes a big difference.
Being the first to implement a particular existing algorithm on a particular platform maybe isn't as big a deal as inventing a new algorithm or technique. When other implementations of the same technique come along, we should just assess them on their merits. If the new tool owes something to previous contributions, then that needs to be acknowledged, and then if it improves in some way on what is already available then great. Even if it doesn't then it may still be useful as an exercise for the author or as an example of a different approach - though of course too much duplication of effort tackling already solved problems is a waste, and if there is no significant new contribution then it doesn't deserve to replace what is there.
If a new tool comes along that improves in some way on what we've done already (such as some of the topology tools available in Starling compared to what is in WeaverBird, or the material properties in Karamba compared to Kangaroo), then let's just learn from that and let it spur us on to greater things and improve even further!
So I'll look forward to using this and future versions of WeaverBird in conjunction with Kangaroo, as I think their feature sets complement each other very nicely.…
nt should stand up to reasonable, Socratic interrogation with logical and descriptive rigor. For example, I find entirely credible an architect who suggests that he placed his buildings 20 meters apart because he thought that it would make people more comfortable in light of his reading of the space relative to its environment, materiality, expected time of habitation/circulation, etc. His "thinking" such things is, for the most part intuitive, and backed by deductive logic. (Of course integration of wind analysis and other harder readings is obviously desirable) But I interpret the active denial of intuition's crucial role in design as at the heart of its current deplorable trending toward misuse of terminology, application of pseudo-science and intellectual over-reach. Architects wade out of their waters precisely when they invoke such things as human psychology or perception.
Furthermore, I believe that architects - student and professionals alike - regularly make formal decisions according to their aesthetic judgement. To suggest that students aren't qualified to make a design decision during their studies because they think it's formally successful seems exceedingly stingy; likewise, suggesting that a professional architect shouldn't rely on it is puzzling to me. I find architects' attempts to justify what are obviously decisions based on formal taste using other means often taking the same form of obfuscation that makes architects appear to be intellectual charlatans to specialists in other fields. Taste is taste. I would agree that it can't be taught. But good architectural design certainly remains at least somewhat grounded in artistic sensibility.
3) I'm by no means advocating that all architects must master every detail in their work. Rather, that architects have at least a generalist's working knowledge of materials and construction systems. Floors don't levitate, and windows require depth; rules of thumb count as vital knowledge.
4) I would say that consideration of performance-driven properties falls under basic understanding of how a building will operate in its given environment. For example, if you've designed a glass house in Arizona, ur doing it wrong. The more simulation and science you have, the better. Indeed, I think that such elements - wind analysis, solar gain analysis, structural performance - represent the most solid opportunities today for architects to assert the harder lines of defense in their design decision making...say for example, being able to demonstrate using basic geometry that your shade keeps the sun out in summer, but lets it in when it's cold.…