Parametrica.Con grasshopper puoi gestire progetti complessi dal punto di vista della forma e dell'organizzazione con un solo strumento , dal design dell'oggetto , allo spazio dell'architetture , all'organizzazione urbanistica.Grasshopper è un software open source , in continuo aggiornamento da parte degli utenti , TRA POCO POTRESTI CONTRIBUIRE ANCHE TU AL SUO SVILUPPO !!!Sabato 11 MAGGIO 2013durata di 6 ore : dalle 10:00 alle 17:00presso : STUDIO REMODESIGN (via dei marsi n° 41)per prenotare chiama il numero : 3498381249oppure manda una mail all'indirizzo : contact@ivoambrosi.itvisita il sito: www.ivoambrosi.it…
hilst settings concern only the currently selected instance.
For instance assume that you are in the Bermuda Shorts business and you want various ideas concerning a new ad campaign:
Or assume that the 4 horsemen want from you to quickly present some concept proposals related with a terminal event that they have in mind:
…
Grasshopper. So, I once made an attempt to bind ms sqlServer in order to get frozen definitions at some states, to avoid managing baked objects in Rhino and also be able to retain whole results without using the GH state manager that rebuilds everything.
But at that time GH's VB.Net component didn't properly read referenced dlls and I forgot it since then.
At first, I was surprised by Slingshot's extensive interface : I was still having in mind my own old project, a tool that would have acted at the Rhino's geometry object level, and auto creating the needed tables.
The bd would have consisted of a main table, owning the objects ID and name, and related tables containing the necessary information relative to the main objects.
For example, a Brep is made of so and so underlying objects, passed to respective tables, according to GH objects definition layout (just the way they are written in the xml schema).
Then, on a db, query an object by name, and retrieve the whole object or underlying objects (e.g. at the bounding curves level, or points level for a Brep).
With Slingshot, I made a few attempts to cheat GH with BLOB data fields, but no way to get a whole object. It seems that GH simply provides an object.toString ... and GH is definitely not conceived to produce persistence outside of Rhino. If I have some spare time, I will try to extract
About points and colors, I am now simply using a single field with CHAR(asLargeAsNeeded...), as GH parses String to every Point (or Vector or Color) entry of any component.
I do so because it need less to display on the canvas...
Whatever I wrote before, I really like your conception, as opened to relational interactions between ...whatever you need or dream of !
One last thing : GH can't open the definition file "Genome_DB_Template.gh" that I've downloaded from your site : http://slingshot-dev.wikidot.com/database-genome. I was expecting to learn a lot from your very smart stuff ! (I am running GH 08.00.13 and Slingshot 0.7.2.0)
Slingshot is running great, opened to any use...Thanks again.
Best,
Stan
…
Refinement component at first, possibly using MeshMachine instead which is slow but actually gives many fewer triangles and adaptive meshing for tight curves too. Neither are easy to adjust on a deadline!
Then you have to sneak up on workable settings, using only a few lines, or Grasshopper will freeze perhaps indefinitely for 200 lines with extreme settings, especially the CS (Cube Size) setting that can blow up into a huge number if your scale is big.
Cocoon gives lots of nearly flat split quad faces so I quadrangulated those for fun:
Or MeshMachine can refine the mesh to make it efficient:
Whereas the Cocoon Refine component will merely return an equally fine mesh with more equilateral triangles but no serious remeshing to rid so many tiny triangles where they are not needed? Actually, it does seem to remesh also:
David said he used some of Daniel's MeshMachine code in there.…
ra' nella finestra di Grasshopper, in alto, insieme agli altri set di componenti come 'Params', 'Maths', ecc.
Si tratta di un esperimento per cercare di ampliare in qualche modo l'ambito di utilizzo di Grasshopper.
Come sappiamo Grasshopper e' nato per consentire l'utilizzo parametrico di Rhino. Le definizioni di Grasshopper permettono di registrare i passi necessari per costruire gli oggetti, nonche' di variare i dati utilizzati dalla definizione, ad esempio oggetti geometrici, lunghezze, angoli, ecc.
Quando modifichiamo i valori utilizzati dalla definizione Grasshopper automaticamente ricalcola il tutto e ci mostra la preview del risultato.
A questo punto, se il risultato e' soddisfacente, possiamo dire a Grasshopper di inserire gli oggetti in questione nel documento di Rhino, cosicche' li vedremo apparire nelle viste come veri e proprii oggetti Rhino.
Questo modo di lavorare ha avuto un grande successo tra gli utilizzatoti di Rhino, rendendo molto piu' agevole la costruzione di oggetti nel caso in cui sia necessario procedere per tentativi, verificando il risultato prima di stabilire la forma finale da ottenere.
Il successo di Grasshopper pero' ha anche mostrato quanto sia comodo poter definire graficamente le procedure di costruzione, e in generale poter utilizzare Rhino tramite i componenti, ad esempio gli slider, che tutti noi, suppongo, vorremmo avere a disposizione anche quando usiamo Rhino nel modo classico tramite pulsanti e comandi.
Quindi col passare del tempo sono apparsi sempre piu' Add-on per Grasshopper che permettono di eseguire operazioni particolari o anche di utilizzare Grasshopper in ambiti diversi dal concetto originale di 'History programmabile'. Accodandosi a questa tendenza, edoc prova a costruire dei componenti che permettano di operare direttamente sugli oggetti Rhino, cioe' curve, superfici, layer ecc. appartenenti al documento Rhino su cui stiamo lavorando. L'idea e' permettere di utilizzare la comoda interfaccia utente di Grasshopper anche per operazioni che solitamente sono eseguite in modo tradizionale con pulsanti e comandi, o anche tramite script.
Come gia' detto, e' un esperimento. I componenti nascono, muoioni e cambiano molto spesso, nel tentativo di capire cosa puo' essere utile e cosa puo' fuzionare o meno.
Segnalazioni di bug, suggerimenti, considerazioni ecc. sono benvenuti.
se qualche anima pia volesse tradurre questa presentazione gli faremo un monumento equestre!
grazie e scusate
gg
…
ey provide all the means to what I try to achieve.
What I need is to get a fast (as possible) evaluation of passive heat/solar gain from a certain facade. I know my building can cool to a certain degree (lets say 80 W/m2 - now lets forget other internal gains) and I want to be sure my facade is not letting excessive amounts of heat into the room/building. Normally I would make a full blown simulation to count my overheating hours and thereby evaluate my facade. To speed up the process, the idea is just to evaluate overheating hours in a faster way. So what I am thinking is that excessive amounts may estimated by counting high intensity irradiation patches in a critical sky-component or whatever such thing would be called that surpasses my sensible cooling load. My hope is that any facade visible to the sky-patches would very similar to the number of overheating hours if properly calibrated to a simulated model. However I have no idea right now, if this can be done.
Why do this? Speed, convenience, whole building thermal analyses.
@Chris and @Abraham The critical sky-component is made with LBs radiance component radiation and filtering the beam-components with highest effects from a yearly epw-file.
@Chris Conductive heat gains are also important especially if the facade is badly insulated, so the next step is to filter the outdoor temperature parallel with that critical sky-component and then do a static heat transfer analysis and combine that with the effect from direct sun influence. Again, no idea if it works.
Hope it makes sense. I a little embarrassed I drew you into this little experiment. This was not at all the point of the discussion. But now we are into it I like to know what you think. If it works its kinda neat, at least i think it is.
/K…
ers and researchers, programmers and artists, professionals and academics who come together for 4 days of intense collaboration, development, and design.
The sg2012 Workshop will be organised around Clusters. Clusters are hubs of expertise. They comprise of people, knowledge, tools, materials and machines. The Clusters provide a focus for workshop participants working together within a common framework.
Clusters provide a forum for the exchange of ideas, processes and techniques and act as a catalyst for design resolution. The Workshop is made up of ten Clusters that respond in diverse ways to the sg2012 Challenge Material Intensities.
Applicants to the sg2012 Workshop will select their preferred cluster from the following:
Beyond Mechanics
Micro Synergetics
Composite Territories
Ceramics 2.0
Material Conflicts
Transgranular Perspiration
Reactive Acoustic Environments
Form Follows Flow
Bioresponsive Building Envelopes
Gridshell Digital Tectonics
More information about the Workshop and Clusters can be found here:
http://smartgeometry.org/index.php?option=com_content&view=article&id=116&Itemid=131
The application process will close on January 15th, 2012.
Full Fee $1500
Reduced Fee $750
Scholarship Fee $350
Fees include attendance to both the workshop and conference from March 19th-24th.
Reduced Fee and Scholarships are available only for Academics, Students and Young Practitioners, and are awarded during a competitive peer review process.
sg2012 takes place from 19-24 March 2012 at EMPAC (http://empac.rpi.edu/) and is hosted by Rensselaer Polytechnic Institute in Troy, upstate New York USA. 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.
sg2012 Challenge Material Intensities
Simulation, Energy, Environment
Imagine the design space of architecture was no longer 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
Follow us on Twitter at http://twitter.com/smartgeometry…
Added by Shane Burger at 12:29pm on December 13, 2011
nza dal centro delle facce ad un punto fisso per determinare quant'è il valore dell'offset per quella faccia.
Prova questa soluzione per ora:
- abilita il componente disattivato all'inizio;
- il componente curve offset non funziona bene, domani vedo se riesco a crearne uno migliore;
- inforna (bake) la brep risultante e convertila in mesh da rhino;
- per dargli spessore, fai l'offset solido della mesh in rhino per l'ultima fase, funziona meglio.
I've used the distance from the center of the faces to a fixed point to determine the value of the offset.
Try like this:
- enable the first component disabled;
- offset curve don't work perfectly, I'll try to fix it maybe...
- bake the brep and convert it into mesh in rhino;
- for the thickness, do a solid offset of the mesh in rhino for last phase, it just works better.…