ur setup. Can you say what sensor you are using? Are you using an Arduino to write this ascii information to the serial port? If so, there may be some formatting code for the string that you'll need to do to get the Read component to function properly. I see that you were able to open the port and Start reading... so my first thought is that the data is formatted correctly....
All of the read components look for a specific character (in this case two characters) to indicate when it has reached the end of the line being read and should spit out the data. In this case, Firefly uses the Carriage Return (\r) and Line Feed (\n) to know when it has reached the end of the line. In arduino, these are automatically added to any line if you use the Serial.println("blah, blah, blah"); command. Notice, this is different from the Serial.print("nothing to see here"); command. This doesn't mean that you can't still use the regular print command... it's just you need to use the println command to indicate when you've reached the end of the line. Let's take a look at a simple example.
void setup() { Serial.begin(9600);}void loop() { int sensorValue = analogRead(A0); Serial.print("The value of the sensor is: "); Serial.println(sensorValue);
delay(20); // important to wait some small time so you aren't sending just a ton of info over to GH which will cause it to crash :(
}
The first print statement prints a string to the serial port... and the next one adds the current sensor value... and THEN adds the carriage return and line feed to start a new line. The nice thing about using these together is that you can concatenate any type of data you want. If you were to upload this sketch, you should see a sentence being printed to the serial port that says "The value of the sensor is: 512". I made up the number, but you get the idea. Notice, I also had to include a delay function. You don't always need this (there are other ways to go about this) but the important thing to note is that the loop cycle on the Arduino can run really fast. I mean... really fast. So, you wont want to send so much data over to GH, because this could flood the string buffer in the Read component and cause it to crash (eventually). It's a good idea to add some small time interval just to slow it down a bit. I should say that I've optimized the refresh rate in the next release so it's significantly faster... so hopefully this wont be as big of a problem... but hopefully that helps some.
Now... Why are you writing data to a sensor? Sensors by default are considered inputs... so I'm quite confused as to why you would want to send data back (if you are... then you need some way to handle the string data being sent from GH... this is the whole reason we built the Firefly firmata... it sets up the two-way protocol so you don't have to deal with all of that mess... If you're going to read and write, you're better off just uploading the firmata and using the Uno Read and Write components). Also, I'm not very familiar with the Hyperterm or Advanced Serial Port Terminal... but I will say that could get COM conflicts if you're trying to open the port with different tools. Anyway, I hope some of this helps you get up and running.
Cheers,
Andy
…
gap as for a 20 meter gap, it's not a good argument.
I fully concede that not every single thing may be backed up by logic. There are simply too many design decisions to make and not enough time to make them rigorously. And I do believe there is place for human intuition and art in architecture, but I also think that artistic (or intuitive, or emotional) considerations should clearly be labelled as such.
When Le Corbusier designed the urban layout of the city of Chandigarh he used his intuition to distribute the buildings and clusters. His intuition however was grounded in European climes and it failed him in India. On hot days it becomes almost impossible to walk the distance between them. Would Chandigarh have been a better place if the maximum distance was defined by the largest walkable distance on the hottest day of the year instead of the unjustifiable intuition of the designer? I suspect it would.
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;
There are plenty of rational decisions which are made by tacit processes. People can become very good at mimicking rational behaviour using intuition. And -as I said- if you are an architect with a distinguished career; if you've already proven yourself to be capable of good design then there comes a point where your intuitions can be trusted (to an extend).
But students whose every design has always been virtual, who have not been able to evaluate their decisions by a follow-up study, I don't see how anybody can trust their instincts. Instincts aren't just sitting in someone's brain, they are cultivated by relentless exercise and trial-and-error. Until you actually build something there is no error, only trial, and virtual trial at that.
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.
I fully agree here. If there are non-communicable aspects to a design, just say that. There's no shame in it as long as you're honest about it and have considered -however briefly- the consequences in case you're wrong.
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.
I think we're on the same page here. If you want to make a physical building, then there's more to it than pure design. Engineering comes into play. I don't mean to imply that engineering doesn't require creativity or even artistic intellect, but it is a different kind of problem-solving.
I fully agree with your fourth point. I just wasn't sure what performance-driven meant.
--
David Rutten
david@mcneel.com
Tirol, Austria…
Added by David Rutten at 4:19pm on August 14, 2013
d the workshop PDF from this link: http://goo.gl/bcvRNH Download event poster from this link: http://goo.gl/Q0KWCM Brief: Cairo is filled with barriers controlling people movements, suppressing them as well as detaining green and public spaces to the extent that most people have been taking these spaces for granted. Public spaces have been for a while the periphery of our daily life. We will explore in this workshop how we can manipulate and alter people’s perception and direct their attention to how these spaces are integral for city life. This exploration will be backed up by intensive technical tutorials introducing computational design and fabrication techniques and tools mainly Rhino, Grasshopper, Geco and Ecotect. Not only will this be the typical technical workshop, but rather you will also have the chance to be guided step by step on how these tools are used through out different design stages in a real world scenario. Design prototypes will be produced through 3D printing, the main workshop output will be a fabricated one to one functional model for one of the designs using our new in-house CNC machine. Tutors (check the PDF for bio): Olga Kovrikova, MArch DIA Alexandr Kalachev, MArch DIA Karim Soliman, MArch DIA Islam Ibrahim, MArch DIA Sherif Tarabishy, B.Sc. AAST Application: Application deadline 1 September 2013 ** For students (undergrad / Master), teachers and PhD proof of status is required (university ID with a date or a certificate of enrollment) to apply for the students package. Packages (choose one of the following in the application form): 1. Standard registration Course fee is 4250 EGP For Students 3500 EGP 2. Early bird registration discounted fee For Professionals 3750 EGP For Students 3000 EGP ** Early bird offer ends on 14 August 2013 3. Group registrations discounted fee (5 or more) For Students 20% off - You will have to fill out an application form here: http://goo.gl/0QxAga - You will need to submit your CV and Short Portfolio (max. 10 MB) to info@morph-d.com, email subject: “Morphing Norms Application” (we will decide if you are eligible for an early bird discount or not based on the date of your email submission) - We will confirm receiving emails from all applicants. Successful applicants will be contacted 5 days after each deadline (early bird/final) and will have to confirm participation within 3 days, if they fail to do so, places will be given to others on the waiting list. - A maximum of 30 applicants will be selected.
…
tura digital en corte Láser, corte CNC, impresión 3d, y modelado paramétrico.
Este tercer taller enseña los fundamentos del modelado paramétrico y algunas bases de manufactura digital.
PERFIL DEL ALUMNO QUE INGRESA:
Diseñador, Arquitecto, Artista con conocimientos de Rhinoceros interesados en comenza a modelar paramétrico con Grasshopper para fabricación digital básica.
PERFIL DEL ALUMNO QUE EGRESA:
El alumno terminará con los conocimientos y criterios para el desarrollo de piezas o proyectos utilizando fabricación digital, mejorando y agilizando los flujos de trabajo, así como los criterios fundamentales del Modelado Paramétrico -Generativo.
Taller de modelado paramétrico con Grasshopper
Interfase
Manejo de Datos
Data Volátil
Data Persistente
Rangos y dominios
Atractores
Listas y Cull
Modelado por Layer Object
Análisis Básicos
Conexión de Curvas
Superficies
Análisis de Superficies
Panelización Básica
Relaciones con Excel
Modelado generativo
Fechas: del 8 de Febrero al 1º de Marzo
Días: Sábado
Horarios: de 10 am a 3 pm
Sesiones: 4 de 5hrs
Duración: 20 horas
Precio: $3,000.00…
r visual programming tools in the games world. MS's Kodu, looks interesting. Kismet and Visual3d look even more interesting..... mainly because they are more 'interactive' or 'reactive', rather than DAG-based.
Seems like the evolution path for GH-similar apps is:
1. base 3d or CAD app based on C/C++ code.
2. Add scripting language interface
3. Add some kind of visual interface
4. Add graph sorting / propagation engine
5. Re-jig base 3d or CADD app to make managed/interpreted scripts run faster, multi-threaded.
6. Add dynamic typed language, DLR stuff
6. ....
6. Add constraints solver...?
7. Rebuild CAD display engine to be procedural at the GPU level?
Seems like there are available tools for converting scripts into some kind of flowchart. There are even visual debuggers. MS even has something called the 'Debugger Canvas'. Spreadsheet constraints.
Seems like the time is ripe for lots of new apps like GH.
…
l design.
2/ Optimization
2.1/ in prefabrication
2.2/ combinatorial
2.3/ approach comparisons (i.e. deterministic vs stochastic)
2.4/ share your research
2.5/ ... etc. the list goes on and on
3/ Share you design rationale and how computation fits in
4/ Need help with this problem...
5/ Challenges and workshops announcements
6/ CD News
7/ Share computational design projects under construction or built (akin to skyscrapercity)
8/ and so many other categories and sub-categories...
Just my first thoughts. That breakdown in optimization is just an example. Maybe 'sections' is an old-school way of seeing things, I just wanted to share some thoughts on the kind of content I look forward to seeing. It can be pragmatic topics, but also theoretical, and allow folks to share their projects and research. Some categories are specific, others broad. I suppose I'm interested in community building with regards to computational design. I think SmartGeometry attempted to accomplish this at some point in the past, to some degree. However their focus appears to be in the workshops and challenges.
I recall the silly flame wars that the CG industry had 20 years ago (lame). I'd avoid that, even if it meant forbidding the mention of any specific software in certain areas or in the entire forum. Which would be tricky, but the endless flame wars and silly comparisons were such a waste of everyone's time in CG.
Without dwelling on this too much yet, I think that the software specific questions belong in software specific forums. If we already had a common language for computational design, you'd just need to add the right description as a meta-tag to any Dynamo or Grasshopper forum post, and you'd be able to find analogous solutions in either forum effortlessly, right?
The Dynamo and Grasshopper forums lack design-centric content. The emphasis is generally on the tools and workflow. Computational design is hybrid in essence, it involves both design and computer programming (be it visual or textual). We could really use a forum for knowledge exchange where the expectation is that both are discussed with equal status.
I disagree that such a forum ought to exclude professional programmers. It should include professional programmers whom have an interest in design, and also include professional designers whom have an interest in computer programming, and everyone in between, and enthusiasts, and artists whom are curious about algorithms as a creative medium, and academics, and students, and etc etc. As long as there is rich content and activity on design as well, not only the computational bit, then the crowd will be diverse and we'll all have more to learn from one another.…
rested in specializing in the field of Computational design.
The workshop will help understand how Grasshopper facilitates during the design process allowing one to Generate, Automate and Manipulate data.
To Register:
http://goo.gl/forms/gvUTyZihVK
Workshop Structure:
Day 01: 16 August 2018
Introduction to Computational Processes in Architecture
Understanding Grasshopper and its relation to Rhino3D
Working with fields and Grids (Supplementary readings for Architectural theory)
Spatial Concepts using Data
Day 02: 17 August 2018
Understanding Data in Grasshopper - LISTS
Managing Data in Grasshopper (Supplementary reading)
Experimentation on Massing and Architectural Forms
Day 03: 18 August 2018
Understanding Data in Grasshopper – Trees
Surface Logics (Supplementary reading)
Design Exercise and Prototyping
Day 04: 20 August 2018
Architectural Skins
Day 05: 21 August 2018
MasterClass Project
Introduction to various types of Digital Fabrications
Prototyping of works during the Workshops
Basic knowledge of Rhino 5 is required to be able to take this training.
CERTIFICATION: All participants will receive a Workshop certificate from Authorized Rhino Trainer.
3D Printing: Prototyping of works during the Workshops
Workshop Tutor:
Kavitha M, an Architect and Computational Designer, 3D Printing Specialist is also the co-founder of INTO Design Research, will head the Computational Process in Architecture using Grasshopper workshop. Graduated from Stadelschule Architecture class with Masters in Advanced Architecture Design, has been researching on teaching methodologies on digital tools and their influence on Design thinking.…
Meeting Agenda:
1) Discuss what the group would like to learn this term through our regular scheduled meetings. Topics include the priority and sequence of Grasshopper exercises we would like to explore during the winter term from http://www.digitaltoolbox.info/grasshopper_basic.html and Processing tutorials from the Processing Handbook I received from MIT.
2) Watch the Matt Storus Church Machine video and have a discussion about parametric and generative tools in design.
If you have a chance, please read the following article by Tim Love called Between Mission Statement and Parametric Model at:
http://places.designobserver.com/entry.html?entry=10757
3) Discuss a possible design build project over the following winter and spring terms using the skill set this group is developing. Conversation led by Chris Nielson (please see comments below for a brief backstory)
4) Discuss possible applied research and design work for the National Conference on the Beginning Design Student paper, Machine Craft and the Contemporary Designer: exploring parameters and variables through making physical artifacts. I wrote the attached abstract and submitted it for the conference the past fall and it was accepted. To continue with the research I need to assemble a team of students that will help explore the principles I set forth by making physical objects with the cnc router. In exchange for helping with the research I will show participants how to use the cnc router, how to author machine code and provide you with the cnc controller interface software necessary to simulate machine movements. Not to mention, your work will be sited in the research paper I present at the conference at UNC Charlotte in March. More tomorrow night, of course.
Thank you for your interest and I hope to see you there.
Sincerely,
Erik Hegre
Chris Nielson Reply by Eugene Parametric Society on January 7, 2010 at 12:02pm
All,
In response to Erik, who requested that I describe my intentions in a design-build project and to the article posted (definitely required reading for this group) I propose that we begin development of a project that spans the realm of "sustainable social" architecture and parametric design. The particulars of such a design do need to be made concrete, and it will be important to define the goals of such a project.
Therefore, I would suggest that this serve as a forum for the next few weeks for those interested in producing a built project. I agree with Nico that it may not be feasible to create the built piece, whatever it may be, this term; however we should have the groundwork and a plan in place by the end of the next 10 weeks.
Either way, I would ask that everyone who is interested to please provide as many concepts to this forum to begin a discussion. If you are indeed interested, please submit goals that this project could achieve (energy, socially, aesthetically, economically, related) and perhaps what you envision the project to physically be (shading device, public bench, water catchment, interactive thermal contraption, etc . . . )
I look forward to hearing your thoughts!
Cheers,
Christopher…
and 3d rapid prototyping using state of the art material simulation and optimisation. Participants will be guided through methods of advanced structural analysis and evolutionary algorithms implemented in Grasshopper, Karamba and Octopus in a 5 day workshop taught by Robert Vierlinger and Matthew Tam within the premises of the Academy of Fine Arts & Design in Bratislava, Slovakia. The workshop will cover the basics of setting up a karamba definition and more advanced form finding techniques with beams and shells through to preparing files for 3d printing and 2d documentation. For the Grasshopper newcomers there is a preparatory crash course on 20 July 2015 taught by Ján Pernecký. The workshop will be held entirely in English. VENUE Academy of Fine Arts and Design in Bratislava: VŠVU / AFAD, Hviezdoslavovo námestie 18, Bratislava, Slovakia ROOM 135 PRICING Early bird Student (until Jun 30, 2015) €320 Early bird Professional (until Jun 30, 2015) €380 Regular Student (from Jun 30, 2015) €400 Regular Professional (from Jun 30, 2015) €475 The fee covers only the tuition. Travel expenses, accommodation and food is to be covered by the participants. SCHEDULE Day 1 Lecture - Karamba in Projects from Competition to Construction Introduction to karamba - Setting up a basic karamba model Shells & Beams - Understanding the impact of load on geometries. Beams - Cross Section Optimization, Load Path Emergence Day 2 Extraction and Visualization of data from Karamba Complex Geometry - Processing of Free Forms for Karamba Force Flow - Understanding and Visualizing results on shells 3d Printing - Preparing geometries for rapid prototyping Day 3 Lecture - Form Finding in Karamba Isler Shells - Hanging Forms with karamba Shells - Shape Optimisation with Galapagos Trusses - Topology Optimization with Galapagos Columns - Positioning with Galapagos Multiobjective optimisation strategies with Octopus Day 4 Frequency Analysis & Non-Linear Analysis with Karamba Extraction and Visualization Part 2 BIS - Building Information Systems with karamba Day 5 Participant’s Examples and Topics Reviewing 3d Print Studies Large Complex Models Reviewing learn techniques and strategies Concluding lecture - public PARTNERS rese arch Academy of fine arts and design…
ght on why this is, and some ideas I have for how to improve things going forward.
MeshMachine grew out of some scripts I started developing over 3 years ago (described here), originally just with the aim of achieving approximately equal edge lengths on a smooth closed triangulated mesh.
As time went on, I kept adding things, such as ways of keeping boundaries and sharp edges fixed, different ways of controlling edge lengths that vary across the surface, and different ways of pulling to surfaces.
I was also still experimenting with different rules for the core remeshing operations, such as valence driven vs angle driven edge flips.
All of these things meant many variables in the script. I wanted to share the work so others could play with it, but not really knowing exactly what people might use it for made it difficult to simplify the interface, so I just exposed most of these variables I was using (actually there were originally even more, but I felt a component with 20+ inputs was excessive, and combined some of them and fixed others to default values).
I've never been happy with that component, but some people want a component that you can just feed a surface and get a mesh with 'nice' triangles, without too much fuss or needing to know anything about how it works, while other people want to be able to vary the density based on proximity to the border, and curvature, and attractor points and see the intermediate results, and model minimal surfaces without pulling to any underlying surface, and...
Since then I did the rewrite from Kangaroo to Kangaroo2, and through that process, and associated conversations with Steve Baer, David Rutten and Will Pearson, my ideas about how to structure libraries and make cleaner more flexible Grasshopper components changed. Much of this centres around using interfaces (in the specific programming sense, not to be confused with UI), because they allow separating code into multiple components, while still allowing to edit parts of it within Grasshopper, and other parts in a proper IDE (because I find the GH code editor is not conducive to writing large amounts of well structured object oriented code).
Towards the end of last year, Dave Stasiuk and Anders Deleuran invited me and Will Pearson over to CITA for a few days of mesh and physics coding and beer drinking. During this time I made the first steps to restructuring MeshMachine to be more modular and interface based like Kangaroo2, instead of one giant script. One of the main motivations for doing this was to make it easier to combine the K2 physics library with the remeshing. However, at the time I hadn't yet released K2, so it didn't make sense to post examples that used those libraries. After the launch of K2, this restructured MeshMachine development has been a bit on the back-burner, but this discussion and Dave Stasiuk's work with Cocoon is inspiring me to pick it up again.
Seeing how you are combining the Cocoon and MeshMachine, and how Dave is also using interfaces in his recent work suggests to me it might be possible to integrate them more smoothly...
…