giornata inaugurale sarà dedicata alla free-lecture introduttiva finalizzata alla realizzazione di un modello d'architettura complesso attraverso l'utilizzo di comandi e tecniche avanzate di rappresentazione con Grasshopper (plug-in parametrica di Rhinoceros) e 3dsMax. Sarà illustrato inoltre il potenziale di V-ray per 3dsMax realizzando un rendering concettuale. Durante il mini-corso dell' openDAY verranno mostrate le caratteristiche e le potenzialità degli strumenti per far luce sui nuovi valori assunti dalla modellazione 3D. La modellazione 3D sta interessando un pubblico sempre più vasto inserendosi in una nuova fase di ampia disponibilità per conoscenze, software, hardware di prototipazione e modelli. Pur mantenendo tutti i suoi valori già noti la questione si è talmente ampliata fino ad interessare norme giuridiche (diritti sui modelli ,concorrenza con offerte di servizi apparentemente simili, informazioni deformate e onfusione nei media) Makers University[http://www.makersuniversity.com], in collaborazione con parametricart, vi propone un punto di vista ampio e sintetico su queste tematiche.
Al termine della free-lecture, sarà illustrata l'offerta formativa [CLICCA QUI] di parametricart riferita ai corsi che si terranno nei mesi di Gennaio e Febbraio 2013 inseriti all'interno della più ampia programmazione della Makers University. SONO PREVISTE TARIFFE PROMOZIONALI PER COLORO CHE SI ISCRIVERANNO AI CORSI durante l'OpenDAY.
La lezione e la presentazione si terranno nel nuovo spazio co-working il PEDONE.
PROGRAMMAZIONE
- I temi della Makers University [Leo Sorge];
- Modellazione della parametricTower (concept di architettura complessa) utilizzando Grasshopper, applicativo per la modellazione parametrica [VIDEO] [Michele Calvano];
- Modellazione di una copertura reticolare 3D a completamento della parametricTower con 3dsMax utilizzando tecniche di modellazione mesh complesse [Wissam Wahbeh];
- Rendering con V-ray per 3dsMax illustrando la nuova interfaccia nodale [Wissam Wahbeh].
- Question Time per chiarimenti sugli argomenti illustrati.
COME
L'openDAY sarà aperto a tutti gli interessati,completamente gratuito e sarà replicato in tre sessioni di uguali contenuti organizzate nei seguenti orari:
Sessione [1] 11,30 - 13,30
Sessione [2] 15,30 - 17,30
Sessione [3] 17,30 - 19,30
Per necessità di organizzazione è importante la prenotazione all'evento utilizzando il form in fondo alla pagina specificando nella stringa apposita, il nome dell'evento e la sessione (es. open day sessione 1) oltre agli altri dati richiesti.…
rsi giornalieri (livello base) dedicati a 4 diversi topic Rhinoceros - 8 febbraio Grasshopper - 16 febbraio Rhino cam - 8 marzo Stampa 3D - 9 marzo
tutor: Amleto Picerno Ceraso, Francesca Viglione, Gianpiero Picerno Ceraso.
. Arduino for interaction (livello base-medio) 15, 16 marzo Il workshop parte dalle basi della programmazione di arduino fino ad arrivare all’interazione tra un oggetto fisico ed un imput informativo tutor: Gianpiero Picerno Ceraso
. Grasshopper advanced: “Complex surface” (livello medio) - 18, 19, 20 marzo Il workshop ha come obiettivo lo sviluppo di superfici complesse rispondenti ad informazioni provenienti dall’ambiente. Il corso parte dalle nozioni di Grasshopper fino ad arrivare alla possibile realizzazione di un oggetto tramite le tecniche di fabbrizazione digitale. tutor: Amleto Picerno Ceraso nb: è richiesta una conoscenza base di Grasshopper
. Emotional design (livello alto) 23, 24, 25 marzo Il workshop verterà sull’acquisizione, registrazione e manipolazione di tali dati/emozioni tramite Grasshopper e il loro utilizzo per controllare i parametri del design di specifici oggetti che diventeranno quindi, essendo customizzanti con le specifiche emozioni dell’utente, istanze e memoria tattile di precise esperienze. tutor: Andrea Graziano nb: è richiesta una conoscenza base di Grasshopper
. Fabricated fashion (livello alto) 26, 27, 28, 29, 30 marzo Il tema del workshop verte sulle tecniche di progettazione digitale applicate al fashion. tutor: Luis e Elizabeth Fraguada nb: è richiesta una conoscenza base di Grasshopper
. Blender (livello alto) - 16, 17, 18 maggio tutor: Andrea Graziano
. Interaction design: Arduino + Grasshopper (livello medio) - 2, 3, 4 maggio Il corso ha l’obiettivo di indagare processi di interazione tra le persone e gli ambienti in cui vivono attraverso il responsive design. nb: è richiesta una conoscenza base di Grasshopper e Arduino. tutor: Amleto Picerno Ceraso del Mediterranean FabLab e Antonio Grillo del FabLab Napoli.
info su costi: http://www.medaarch.com/2765-il-nuovo-calendario-attivita-firmato-medaarch/
…
about it.
2. Nick's comment below got me thinking about unit testing for clusters. Being able to work will data flowing in from outside the cluster or having multiple states to test against could be really cool. Creating definitions that were valid across a general cross section of possible input parameters was a significant issue for us. It was all too easy to write the definition as if we were drawing (often we were working from sketches) and then have it fail when the input parameters changed slightly.
4. I wasn't thinking about threading the solver itself. I was thinking along the lines of some IDEs that I've seen which compile your project while you type it. I know that threading within components and at the rhinocommon-level is a freaking hard problem that has been discussed at length already. (although when, 5-10 years from now, it's finished it will be very cool)
Let's say the solver is threaded and the canvas remains responsive. As soon as you make a change to the GH file, the solver needs to be terminated as it is now computing stale data.
What if the solver was a little more atomic and like a server? A GH file is just a list of jobs to do with the order of the jobs and the info to do them rigidly defined - right? The UI could pass the solver stuff to do and store the results back in the components on a component by component basis (i have no idea what the most efficient way to do this is in reality - I'm just talking conceptually) this might even allow running multiple solvers to allow for at least the parallelism the might be built into a given GH file to be exploited (not within components but rather solving non-interdependent branches of components simultaneously). This type of parallelism would more than make up for the performance hit you alluded to for separating the UI and the solver (at least for most of the definitions i write).
I was imagining a couple of scenarios:
a) Writing a parallel module: solver starts chewing away - you see it working - you know it's done 1/3 of the work - if you have something to do at that point you could connect up to some of the already calculated parameters and write something in parallel to the main trunk which is still being solved.
b) Skipping modifications: you need to make a series of interventions at different intervals along a section of code. Sure you could freeze out that bit of a section of down steam code and make modifications so you can observe the effects more quickly. Unfreeze a bit more and repeat etc. etc. until your done and then unfreeze that big chunk at the end to make sure you haven't blown anything up. Just letting it resolve as far as it can while you sit there waiting for inspiration seems a lot more intuitive to me though.
On a file which takes 15 minutes to solve that's no big deal, but you certainly don't want to be adding a 20 millisecond delay to a solution which only takes 30 milliseconds.
You also wouldn't notice it at that point :-) perhaps for things where it would really make a difference, like Galapagos interactivity, it could be disabled - or could the existing "speed" setting just digest this need? Since the vast majority of time that Gh is solving is on files under active development not on finished code, i think qualitative performance is probably more important that quantitative performance (again with cases like Galapagos needing to be accommodated). In our case the code only had to "work" once since its output went to a cnc machine to make a one off project and it didn't really matter if it took 15 seconds or 15 hours for the final run.
Lastly, I have no way to predict how long a component is going to take. I can probably work out how far along in steps a component is, but not how far along in time.
that's ok, from a user point of view, just seeing a percentage tick along once in a while would be nice reassurance that the thing is just slow and has not, in fact, crashed. Maybe there could be two modes of display: the simple percentage version for unpredictable code and, for those of us able to calculate the time taken for our algorithm based on the number of input parameters, a count down in seconds or minutes or whatever.
I think a good place to start with these sort of problems is to keep on improving clusters, ... etc etc
i totally agree.
…
Added by Dieter Toews at 7:53pm on September 4, 2013
) membrFP.Faces[0], // start/quide surface: going from DC to NY via LA uSpans, // obvious vSpans, // obvious true, // trim outer loop. Fails in most of cases. NOTE: inner loops ARE NOT treated false, // tangency 1.0, // point spacing patchFlexibility, // flexibility: use a generous value around 50 surfPullFactor, // surface pull factor (this needs some investigation) fixedges, // get 4 false values you stupid method, like that? 0.2); // tolerance - be generous: we are talking about tissues here not NASA sourced things
Do you know of a generic container in Rhincommon I can store geometry form meshes, breps and curves to points? That's what I seem to need to get around the IEnumerable error.
I have to figure out how to format the Boolean array in Python. Ah, parenthesis worked!
P = Rhino.Geometry.Brep.CreatePatch(CURVES_CONTAINER, Starting_Surface[0], 10, 10, True, False, 10, 30, 0, (False, False, False, False), 1)
At long last, only to find out it won't work right, as in no setting of flexibility will affect it at all?!
Tolerance has a sudden crazy effect if I turn it way up, like a piece of paper bending up opposite corners and it no long is trimmed, but flexibility is dead. I used your same values and same curves for everything. Yes, all the curves are participating, if I bake them and move them around.
My Patch is broken. Weird. Is there magic with the starting surface? I made a naive assumption just a plane would do. Yet you seem to be using your simple CreatePatch results for this?
Ah, the second CreatePatch command type that takes only a surface gives the same thing, nearly. You need a starting surface at all?! They said you could now leave that out as of Rhino SR10 by using Null, but Null or Nothing gives an error. How do I make a null? In Python it's None, as in just entering None into the Rhinocommon command or assigning a variable to None.
Now I have a patch!
But your's is more expressive, more crazy, like your starting surface is greatly influencing it to have extremely extended feet, whereas mine works like a normal patch, as if you were trying to smooth over things. And indeed your surface pull slider makes it more obvious you chose a specific starting surface attached to one of the curves. My starting planes had no such effect, earlier.
With such a starting surface to bias the results I get the same thing finally, indeed, good to know what that does, I never knew from using the command in Rhino.
Why did my use of a plane shut this down so badly though?! Crazy command.
I've enclose a working script for the record.…
Added by Nik Willmore at 12:47am on February 26, 2016
r-tools/
the hack is found here: http://fancywires.com/?p=499
it doesn't function the same as it used to, and i wonder if somethings have changed in the functions underlying the VB script or maybe some other updates to GH that are relevant.
furthurmore, i ask if anyone has made advancements on labeling techniques for cnc/laser cutting?
is there anything more built into GH to do this task?
Permalink Reply by Giulio Piacentino on Thursday
Yesterday I was asked a modified version of the script. Now it supports planes, so it should be easier to use.
- Giulio
Permalink Reply by gotjosh on Thursday
Delete
cool! I also recently adapted the old version to use an input plane instead of a point... i'll have to look at your script to see if we made the same solution.
thanks for your reply... is there anyway that your script could take care of the hack that fancywires has made afterwards? it would be great to have each letter returned cleaned and joined, so there were exactly the same number of curves in the output as characters in the input...
i am basically clueless with VB and .net scripting so far, but i can code in AS3 and php, so a small push in the right direction might get me far...
How can one return one single curve in a letter like "O"? Do you mean using single-stroke fonts? Or maybe returning a brep (polysurface) as output?
- Giulio
…
s o alguna de sus partes con la máquina de control numérico de ControlMAD. La finalidad es entrar en contacto con las herramientas disponibles ( control numérico, corte por láser, brazo robótico, scanner 3D..) para construir formas y superficies de geometría compleja a partir del 3D del ordenador.
El curso se acompaña de visitas para conocer de primera mano el trabajo con estas herramientas digitales.Duración: 48 horas:Clases de 3D: Modelado con RHINO (16 horas) + GRASSHOPPER (8 horas) + Vray (4 horas)Proyecto personal tutorado y fabricado en su totalidad o en la parte más significativa con la máquina de control numéricoVisitas programadas:Taller de maquetas. Maquetas de arquitectura para estudios como Zaha Hadid o Moneo. Trabajan con láser y control numérico.Fundición Capa: han realizado esculturas para Dalí, Oteiza o Manolo Valdés entre otros. Trabajan con scanner 3D y brazo robótico.Pasarela sobre el Manzanares, de D. Perrault.…
er, in debugging this I was still getting some output without the entire vast Voronoi bureaucracy even working, just from my offset/lowered edge curves. And they come out smoother, especially when more complex curves lead to lots and lots of Voronoi branches that then emulate a mere boring beveled edge.
Whereas with distinct-raised medial axes:
There was another bug in that I had cheated in finding the closest point to the outline, by only considering the outermost silhouette since I had so much trouble with data tree hassles trying to find the closest point to one of a collection of outer edges and the locally associated hole edges too.
Because of these failure modes and the hassles of a huge script, I'm abandoning Voronoi determined medial axes in favor of offset pilot curve tweaking:
No more data tree crap with the Path Mapper that makes me miss Python!
It's now robust since it won't break randomly during rough preview (low patch surface spans count):
So, can I do a whole huge array finally? Feeding in dozens of surfaces from an image trace, at the same very low patch resolution (30)...fairly quickly...gives just a flat patch since it's being overloaded with nearly equal height pilot curves:
Tiny holes won't offset and leave open curves so I'll filter those out. Yet so do very sharp concave outer edge curve areas:
Since we are just lowering an overall patch onto these, it's not an error, just feature loss here and there.
Trying it at patch spans 100 memory crashed Rhino, thankfully quickly, but no, it is not going to work on a huge patch, memory-wise, my having 24GB.
Will the Rhino patch command do it with baked curves? Rhino exists gracefully from the command. My test file is way too ambitious and this strategy is no match for ArtCAM at this crazy high detail level. A smaller geometry selection maxes out at 225 X 225 spans in Rhino, failing to capture much detail:
Ah! This should be done one item at a time then, and the patches will trim themselves. Possibly using Python to achieve parallel processing if there's a Rhinocommon Patch command. Is there? Yes there is!
http://4.rhino3d.com/5/rhinocommon/html/M_Rhino_Geometry_Brep_CreatePatch_1.htm
So from a very complicated system I'm now at merely two offset curves moved down in Z.
Taking curves form a surface seems to give them directions that make them offset away from the surface every time, conveniently.
It may not work well for closed curve forms that span the whole diagonal of the collection since that's again having to deal with the whole XY bounding box of the area, for memory.
…
Added by Nik Willmore at 4:57pm on February 25, 2016
t. So here we go!
1. Honeybee is brown and not yellow [stupid!]...
As you probably remember Honeybee logo was initially yellow because of my ignorance about Honeybees. With the help of our Honeybee expert, Michalina, now the color is corrected. I promised her to update everyone about this. Below are photos of her working on the honeybee logo and the results of her study.
If you think I'm exaggerating by calling her a honeybee expert you better watch this video:
Thank you Michalina for the great work! :). I corrected the colors. No yellow anymore. The only yellow arrows represent sun rays and not the honeybee!
2. Yellow or brown, W[here]TH Honeybee is?
I know. It has been a long time after I posted the initial video and it is not fun at all to wait for a long time. Here is the good news. If you are following the Facebook page you probably now that the Daylighting components are almost ready.
Couple of friends from Grasshopper community and RADIANCE community has been helping me with testing/debugging the components. I still think/hope to release the daylighting components at some point in January before Ladybug gets one year old.
There have been multiple changes. I finally feel that the current version of Honeybee is simple enough for non-expert users to start running initial studies and flexible enough for advanced users to run advanced studies. I will post a video soon and walk you through different components.
I think I still need more time to modify the energy simulation components so they are not going to be part of the next release. Unfortunately, there are so many ways to set up and run a wrong energy simulation and I really don’t want to add one new GIGO app to the world of simulation. We already have enough of that. Moreover I’m still not quite happy with the workflow. Please bear with me for few more months and then we can all celebrate!
I recently tested the idea of connecting Grasshopper to OpenStudio by using OpenStudio API successfully. If nothing else, I really want to release the EnergyPlus components so I can concentrate on Grasshopper > OpenStudio development which I personally think is the best approach.
3. What about wind analysis?
I have been asked multiple times that if Ladybug will have a component for wind study. The short answer is YES! I have been working with EFRI-PULSE project during the last year to develop a free and open source web-based CFD simulation platform for outdoor analysis.
We had a very good progress so far and our rockstar Stefan recently presented the results of the work at the American Physical Society’s 66th annual DFD meeting and the results looks pretty convincing in comparison to measured data. Here is an image from the presentation. All the credits go to Stefan Gracik and EFRI-PULSE project.
The project will go live at some point next year and after that I will release the Butterfly which will let you prepare the model for the CFD simulation and send it to EFRI-PULSE project. I haven’t tried to run the simulations locally yet but I’m considering that as a further development. Here is how the component and the logo looks like right now.
4. Teaching resources
It has been almost 11 months from the first public release of Ladybug. I know that I didn't do a good job in providing enough tutorials/teaching materials and I know that I won’t be able to put something comprehensive together soon.
Fortunately, ladybug has been flying in multiple schools during the last year. Several design, engineering and consultant firms are using it and it has been thought in several workshops. As I checked with multiple of you, almost everyone told me that they will be happy to share their teaching materials; hence I started the teaching resources page. Please share your materials on the page. They can be in any format and any language. Thanks in advance!
I hope you enjoyed/are enjoying/will enjoy the longest night of the year. Happy Yalda!
Cheers,
-Mostapha
…
DP ($$$ aside), GC, and Grasshopper. Arthur’s original question is very important
and the exact question (and hopefully answer) I was hoping to find on a
forum.
“How to take intelligent 3D parametric generative design models (scripting, etc.) into 2D documents?" Or, deliver the 3D design for evaluation, bid, construction, etc.
I am intrigued by Jon’s comments in the same thread and would like to know how I can learn more about the process (and
pitfalls) of turning over a 3D digital generative models to a contractor/fabricator.
Are there any industry guidelines established I could use as a reference to guide our firm through this type of uncharted territory?
Arthur’s question is very reminiscent of 10 years ago when I was frustrated with the amount of time spent on the development of a 3D model design (physical and/or virtual) only to have to wipe the table clean and start the process all over again in 2D in order to document the project for delivery. From this I jumped head first into BIM and Revit, vowing never to go back to unintelligent 2D line work. I am now working on Bentley software (v8i: Microstation and Bentley Architecture) with the access and desire to venture into Generative Components. I am very intrigued by Rhino/Grasshopper primarily with the apparent ease of use and available resources assisting in the learning process – something not really available with Bentley.
In hindsight, as I am doing my software research I think the current use of Revit and BA (Bentley Architecture) are more of a “bridge”
between the past (decades of digital 2D work, i.e. AutoCAD) and where hopefully
we all will be someday in the near future (100% 3D modeling, i.e. Digital
Project??). Without having the experience
it would appear that DP/CATIA (PLM software) are closer to this than any other
type of software. As complicated as the
industry standards are for the automobile and airline industry, I feel we
(architectural industry and others) are heading in a similar direction with
total understanding (PLM/ Evidence Based Design) of a design (a whole other topic). If anything I think the market will begin to
demand it sooner or later.
Gehry (DP) article NY Times:
http://www.nytimes.com/2009/02/11/business/11gehry.html
I know these type of broad discussions (software vs. software) can be blown out of proportion on forums, but I am would like to read
the pulse of those who are already in the trenches (using Grasshopper, CATIA, Digital Project, Generative Components, others??) and hear your thoughts. Just as valuable would be other threads,
industry articles/reviews of 3D parametric generative design software.
Thanks,
Boyd…