300895
FB: https://www.facebook.com/ChidoStudio
FB: https://www.facebook.com/WEDOTdesign
Detalles:
Instructores:
Arturo de La Fuente (Chido Studio Argentina)
Eliana Monaco (Chido Studio Argentina)
Luis de La Parra (Chido Studio Mexico)
WS ROSARIO
Lugar:
DOSCASAS
ROSARIO: Sarmiento 1232 Planta Alta (2000 Rosario)
Fechas:
Viernes 16 de Mayo 2014 – 11:00 – 19:00 hs
Sábado 17 de Mayo 2014 – 11:00 – 19:00 hs
Domingo 18 de Mayo 2014 – 11:00 – 19:00 hs.
WS BUENOS AIRES
Lugar:
GARAGELAB
BsAs: Roseti 1380 CABA
Fechas:
Jueves 22 de Mayo 2014 – 18:00 – 21:00 hs
Viernes 23 de Mayo 2014 – 18:00 – 21:00 hs
Sábado 24 de Mayo 2014 – 11:00 – 20:00 hs.
Domingo 25 de Mayo 2014 – 11:00 – 20:00 hs
Importante:
Todos los niveles de experiencia son bienvenidos el único requisito es tener un entendimiento básico de los programas CAD y una actitud positiva hacia el aprendizaje de dichas herramientas. Necesitas llevar una laptop, nosotros te instalamos los programas de prueba.
Si planeas venir de fuera de la ciudad avísanos y te pondremos en contacto con otras personas que también vayan a hacerlo para en caso de desearlo puedan compartir su lugar de estancia.
Al participar en el workshop obtienes el 50 % de descuento en la licencia educacional Rhinoceros por medio de Rhino Chile.
COSTOS:
Profesionales: $1600
Estudiantes: $1400
Si ya realizaste algún Workshop de Chidostudio tenes un 20% descuento en esta inscripción.
Si venis en grupo con 2 amigos más cada uno tiene un %20 de descuento.
Proceso de Inscripción:
El participante deberá un mail a bsas@chidostudio.com donde se le enviará el procedimiento y medios de pago.
El depósito mínimo para reservar la matrícula es del 50% el resto deberá ser cubierto el día del evento.
Una vez que el depósito se haya llevado a cabo el participante deberá enviar a este correobsas@chidostudio.com los siguientes datos:
Nombre completo
Email
Teléfono
Institución educativa u Oficina
Archivo adjunto del recibo del depósito bancario
En cuanto recibamos la información immediatamente nos pondremos en contacto para especificar los pasos a seguir.
Contacto:
Arturo de La Fuente
bsas@chidostudio.com
Tel: (+54) 11-57268799
…
r." I'm sorry to hear that, I take the interface and ease-of-use rather seriously so this sounds like 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."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."[...] 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.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'.
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.
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 this time around 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.
Sliders."I think they should be optional."They are optional."The “N” should turn into the number if set."What if you assign more than one integer? I think I'd rather see a component with inputs 'N', 'P' and 'X' rather than '5', '8' and '35.7', but I concede that is a personal preference."But if I plug it into something that'll only accept a 1, a 2, or a 3, that slider should self set accordingly."Agreed.
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."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.
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.
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.
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.
Organisation.Agreed. We need to come up with better ways to organise, document, version, share and simplify GH files. GH1 UI is ok for small projects (<100 components) but can't handle more complexity.
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
david@mcneel.com…
hours/day (40 hours) Future University in Egypt (FUE) Department of Continuing Education(DCE) ________________________________________ The aim of this workshop is to teach participants how to create a parametric housing model which can be associated with day lighting and thermal analysis. Moreover, participant will get the opportunity to develop passively design envelope. The workshop is highly interactive giving different examples that develop a strong understanding of Grasshopper Workflow & different passive strategies using the performance simulation tool (DIVA). The participants are divided into groups to study the different orientations and the final outcomes of each group are presented thus concluding the recommendation strategies for each orientation. At the end of the workshop, each participant will receive a Certificate of Attendance from Future University in Egypt. Target Participants: ‐Professional architects. ‐Master and PhD students. ‐ Last year of undergraduate students (ONLY). Prerequisite: -None, however, a basic Grasshopper & Rhinoceros knowledge is preferred. Used Software:(will be provided by the instructor). ‐Rhino 5 SR 3 ‐Grasshopper 0.90066 ‐DIVA Version 2.1.0.3 ________________________________________ Workshop Outline: 1st DAY (Wednesday 29 Jan): 1.Introduction to passive design strategies (efficient envelope) 2.Introduction to parametric design logic 2nd DAY (Thursday 30 Jan) : 1.Developing technical tools based on reverse engineering technology. 2.Examples for parametric facade design 3rd DAY (Saturday 1 Feb): 1.Enforcing the parametric logics with Grasshopper 2.Introducing the performance simulation tool (DIVA) 4th DAY (Sunday 2 Feb): 1.Facade design using grasshopper ‐Studio work. 2.Associative techniques – Day lighting and thermal simulation 5th DAY (Monday 3 Feb): 1.Final optimization and final results 2.Group work presentation ________________________________________ Participants are required to bring their own laptops. To register: 1.Fill in the application form found in this link: https://docs.google.com/forms/d/18OrcwwDks5-vd0irZITC430bjMVb8I8pdw0i5OefyMg/viewform 2.Kindly pay the workshop fees at FUE DCE Admission or in the Bank account Number of participants is a minimum of 20 and a maximum of 24 ________________________________________ Workshop Trainers: Ayman Wagdy Mohamed Ibrahim Researcher at Sustainable Design research group | AUC Lecturer at Parametric design | AUC M.Sc. Architecture – Architecture and Building Technology| Politecnico Di Milano Haitham Salah Ali Mahmoud Teaching Assistant of Design course | AASTMT Head of design team | YBA Architect Principal and cofounder | Arkan Architect ________________________________________ For any questions or info please do not hesitate to contact us at : Mob. : 01003220017 - 01008551772 Email : Fue_ppd@outlook.com…
Added by ayman wagdy at 12:12pm on January 17, 2014
how to call excel vb commands from within rhino
The idea is that data from grasshopper could produce a very basic diagram or certain conditions, in this case floor plates and stairwell locations. The user could then "draw" using the formatting tools. In this case the dark colors would represent a change in the fenestration pattern Code in excel would search for the formatting (easy enough to do through Excel Vb) and output the resulting data into another workbook.
Basically you would be using excel as a CAD tool. The advantage of this is that it gives you a flexibility that pure code can't. Which I think is very exciting, because code can't deal with exceptions very well. For example, another possible use I could think of would be the manipulation of a brick wall. Since excel has multiple worksheets, you could LAYER code for one object. One worksheet could give instructions on brick rotation the other on a cull pattern. . . . The advantage of excel is that you can vary these patterns based on the location of your program for example, so that the density would decrease at a certain point. With the vb script, you could also get quite sophisticated with the patterning. In essence each cell is a pixel.
image by danielle aubert "excel artist"
The difference with excel, which makes it a very POWERFULL tool in my opinion is that you are not trapped into what your code outputs, which often is incredibly difficult to have respond to various condition, program, sunlight etc. With excel you can use code to generate a basic pattern, but then modify it. You can also layer code, just like you do in photoshop to produce different effects on the same geometry. You could even execute different code in different areas. . . . Anyway, I thought that it was potentially a game changer. Let me know what you think. And if you have any pointer on , how to start running excel code from rhino or importing rhino data to excel please share so I can start playing with these ideas.…
Added by Ben Fortunato at 8:15am on February 28, 2010
ours looks like). Anyway, you'll probably want to start with a Fader 1-way. I set mine up to go from 0 to 300 over the course of 6 seconds. Then I just wrote a very quick C# component to check the output of the Fader component and whether it met one of three conditions. Here's the code (very simple). Note: you'll need to use the input manager to remove one of the Y input and the output manager to add 2 more outputs (B & C).
if (x <= 100) { A = true; B = false; C = false; } if (x > 100 && x <= 200) { A = false; B = true; C = false; } if (x > 200) { A = false; B = false; C = true; }
Now, we know if at any given Fader value if it's in the first phase, second phase, or third phase. I output a boolean value which can also be considered a 0 or 1 if converted to an integer. So, if I multiply those boolean values by 255, then the one that is true will be 255, and the others will always be 0. Now, you should have your color scheme which switches depending on what phase its in. Simply connect that to the Uno Write component (with the Firefly Firmata sketch loaded on your board) and send the color values to the board as PWM values.
Some things I should note... You probably notice the Fader component looks a little different (it's missing the start input and I'm using the GH_Timer). I've decided (for good reason) to abandon the Form Timer I was using in a lot of the Firefly components in favor of the newly re-written GH_Timer component. So, in order to get the Fader component to update in the next version, you have to connect a Timer and turn it on (not that much different). But, it's significantly faster. Part of the reason is that the form timer just wasn't fast enough to get really smooth results... Now, it's blazing fast. I've incorporated this Timer scheme in a lot of the Firefly components and the results are roughly 10x faster. Since, you're only switching values (and not trying to quickly modulate the PWM values) the current version of Firefly should be just fine (just use the Start input to start the Fader component). But, when we release the next version (hopefully very soon), this may change a bit. Anyway, I hope that clarifies it a bit. I've attached a screenshot below. I didn't include the file because I've got a newer version of Firefly that would just crash on you (or not open properly)... but hopefully you can get how to do it.
…
now.
This V4 can sense if you feed it with your points and uses these instead of the p1,p2,p3 (it's a prelude for V5 that uses DataTrees of points making any surface subdivision a reality). Do the following: sample a triad of your points (NOT internalized) and feed the C# . Then ... start dragging these Rhino points around (the C# responds accordingly). See any difference?
The topology:
Well, the whole fractal logic (in this case) is to have 3 pts on hand (call them p1,p2,p3 : red, green, blue) and then project the "right" one, say, p3 to the Line (p1,p2) > do this > do that ... blah blah.
But ... what p3? that's the 1M question: Here for instance the right p3 (blue) is (by accident) the 3rd point entered (it's obvious the "projection" recursive logic):
but if you drag around a bit the points : p3 is now different (C# does this by sorting synchronously the triangle angles per point VS points) Numbers are used to indicate that "swift" : (0 for the new p1, 1 for the new p2, 2 for the new p3... etc). Compare with the initial points (red = ex p1, green = ex p2 , blue = ex p3).
and again different:
The 1M question:
In fractal thinking the big thing is when to stop: I could obviously control that by a counter ... but here the requirement is the tile min size (within unpredictable amount of recursions) : this is what the stop logic used does.
The 1B question:
So ... implementing fractal logic (against DataTrees of points) to a parametric environment ... requires a lot of questions: because each time the size of the start triad varies ... whilst the stop condition is constant: meaning that with a little bit of "good" luck you can reach incredible high amount of tiles (computer out of memory > Adios Amigos).
Obviously I'm taking having all possibilities in mind and especially big projects > big facades > millions (or zillions) of tiles > Armageddon > ....
more soon
…
onents to the latest version and, as you can see, everything works fine:
Over the next week, I am going to be adding in several new capabilities to the Adaptive model in LB+HB that are not an official part of ASHRAE or ISO standards but they are endorsed by the experts and researchers who have helped build the standards. Mostapha, I will be sure to have the component give a comment any time that these un-standardized methods are used and I will be clear that I have made them a part of LB because I have found these insights from new research to be particularly helpful to design processes for passive architecture. Also, I think many of us recognize that both ASHRAE and ISO were initially founded to produce standards for conditioned or refrigerated spaces and that, understandably, they . Among the features that I will be adding in:
1) You will have the option of using either the American ASHRAE adaptive model or the ISO EN-15251 model (see the CBE's comfort tool for a visual of the differences - http://comfort.cbe.berkeley.edu/).
2) In addition to a different comfort polygon, the European standard also uses a "running mean" outdoor temperature instead of the average monthly outdoor temperature. This "running mean" is computed by looking at the average temperatures over the last week and weights each of the daily average temperatures by how recent it is. This makes more sense to me than the ASHRAE method and addresses the issue that you bring up, Alejandro. Needless to say, the updated adaptive model will allow you to use either a running mean or average monthly temperature with either the American or European polygon.
3) The WIP adaptive chart currently has an option for a "levelOfConditioning". This input allows you to make use of research the was conducted along-side the initial development of the adaptive model, which showed that the findings did not contradict the PMV model when people were surveyed in fully conditioned buildings. This parallel research ended up producing a different correlation between the outdoor and desired indoor temperatures and this correlation had a much shallower slope than the official adaptive model for fully naturally-ventilated buildings. The levelOfConditioning allows you to make a custom correlation for full natural ventilation, full conditioning or (presumably) somewhere in between for a mixed-mode building. This levelOfConditioning will become an official input for all LB components using the adaptive model (not just the chart at the moment).
At the end of all of this, I will put together a new video series on Adaptive comfort so that we are all on the same page about how to use the model.
-Chris…