he Cordyceps. Maybe some of you find this helpful/useful.
So basically, the Cordyceps is a physical module with 4 knobs and 1 slider. The knobs give an output between 1 and 1000, while the physical slider outputs 0-359. And of course, for this physical module I wrote a plugin to communicate with it. The knobs are intended to be the variables that modifies the design, while the physical slider is intended to be connected to the camera component.
Here I will put up "the recipe" for all to make their own module. You will be able to download the plugin as well.
Please send me a message if you want the 3D-files for the knobs, the box and slider knob. They've been made to directly 3D-print.
Plugin:
https://github.com/zakadjeb/Cordyceps/blob/master/Cordyceps/Cordyce...
Code for Arduino IDE:
https://github.com/zakadjeb/Cordyceps/blob/master/Arduino/_Arduino_...
What you need:
1x - Arduino (Leonardo, UNO or whatever)
4x - Potentiometers
1x - Sliding potentiometer
1x - Breadboard
Bundle of jump wires.
1. So, a potentiometer is a variable resistor, which is basically a component that changes the resistance between the voltage and the ground.
If A is supplied with 5V then B must be connected to Ground. The W will give "read" the resistance, and thus should be placed in Analog input (A0-A5) on the Arduino. The slider potentiometer works the same way.
2. Now connect the 4 pots to each their Analog input. The slider is supposed to be in A4. So to make sure:
A0: Knob1
A1: Knob2
A2: Knob3
A3: Knob4
A4: Slider
3. Now it's time to connect the voltage! Using the breadboard, the voltage can be sent through 1 line, the Ground as well. It should be quite easy to connect them.
4. Now, download the Arduino IDE and copy-paste the code I supplied above. In the IDE, you need to let it know which Arduino you're working with, and which port is should send the script.
5. Almost there. Download the plugin. Open the port you're using through the plugin. Set Start to True and the Cordyceps should be within you.
This recipe will be updated!
Let me know if there are any issues.
// Zakaria Djebbara…
new component "OSM 3D roof"):
2) Simplified 3D roads can be created by using the network of OSM polylines (through new component "OSM 3D road"):
3) 3D forest.Up until now, Gismo supported generating a single 3d tree whenever such tree was present in openstreetmap.org database. Now it is possible to generate 3d trees in forest areas, by randomly positioning the 3d trees (through new component "OSM 3D forest"):
4) Boolean 3d shapes.Gismo's "OSM 3D" component generates shapes as parts: for example, if a building has irregular shapes across its height, they will all be created individually. Trying to merge them with Grasshopper's "Solid Union" component can sometimes fail.New Gismo "Rhino Boolean Union" components tries to overcome this issue by using a much better Rhino version of this command.
5) Library of common GIS color palettes (gradients).A single component containing 22 of the common color palettes used in GIS applications as ArcGIS and QGIS. For example: elevation, aspect, precipitation...
6) Url to location.Thanks to idea by Alex Ng, it is possible to extract location from a link of the following map websites: Openstreetmap, google maps, bing maps, wego.here, waze:
Version 0.0.3 can be downloaded from here:
https://github.com/stgeorges/gismo/zipball/master
Example files from here:
https://github.com/stgeorges/gismo/tree/master/examples
New suggestions, testing and bug reports are welcome!!…
Added by djordje to Gismo at 1:39am on January 29, 2019
stributes structural supports for a uniformly loaded domain using e.g. the internal energy of the loaded domain as fitness. Here the uniformly loaded domain is represented by the trimmed surface. My genomes are the support positions (green crosses), which are restricted to a set of predefined grid points. I’m currently using an (i,j)-coordinate indexing for these grid points (illustrated in the viewport just below) as opposed to a sequential , “one-dimensional” numbering (illustrated in the viewport further down).
(i,j)-indexing systemAltenative, sequential indexing system
The support positions are computed by two gene pools; one governing the i-index, Gene List {i}, and one governing the j-index, Gene List {j}, of each support. The value of slider 0 in Gene List {i} is paired with the value of slider 0 in Gene List {j} etc. and the amount of sliders corresponds to the amount of supports. The screen shot below depicts the slider constellation corresponding to the support distribution depicted above. Unfortunately the j-index represented in the sliders needs remapping as the number of j-indices vary for each i-index (horizontal row of grid points). With the current setup I have 12^6 x 9^6 = 1,6 x 10^12 different genomes. If I were to use the sequential, “one-dimensional” numbering, I would only use one gene pool with sliders ranging from 0 to 76 meaning that remapping could be avoided and thereby having only 76^6 = 1,9 x 10^11 different genomes.
So, my current genome setup causes a bunch of issues related to the Evolutionary Solver: Remapping Changing one of the j-index sliders, will not necessarily change the related support position but it will still facilitate another genome to be calculated by the solver. (This problem could be eliminated by using the sequential, “one-dimensional” numbering)
Switching slider values around If the values of e.g. slider 0 were to be switched around with the values of slider 5, this again would yield a new genome but an identical solution. (This problem cannot be eliminated by using the sequential, “one-dimensional” numbering)
Coincident support positions Two or more supports may be located in the same position. (This problem cannot be eliminated by using the sequential, “one-dimensional” numbering)
I find it impossible to imagine the fictive “fitness landscape” of this problem and not only because of the multidimensional genome characteristic but just as much because of these listed, intertwined peculiarities. I’ve tried running the Simulated Annealing Solver as well, but my experience is that the Evolutionary Solver yields better results. To my awareness, the solver uses some kind of topographical proximity searcher. This is why, I think that the solving process itself benefits more from analysing the (i,j)-index system, in which neighbouring grid points hold more uniform topographical information than the sequential, “one-dimensional” numbering, which might have big ID-numbering gaps between neighbours. Have I understood this correctly?
Cheers…
he "return" is comment out as shown below?
After restarting Rhino and Grasshopper, I opened the outdoors_airflow demo file, and the first step of creating the case file is ok:
Then the blockMesh component gives the following error: seems I have to manually start OF first..
so, as the error message suggested, I open OF by Start_OF.bat:
Then come back to the blockMesh component, now it can be executed while the OF command line window is also openning:
... and the blockMesh finished successfully:
... so I proceeded to run snappyHexMesh, checkMesh and update fvScheme:
... up to the simpleFoam component, I got the error again:
The warning message is:
1. Solution exception: --> OpenFOAM command Failed!#0 Foam::error::printStack(Foam::Ostream&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #1 Foam::sigFpe::sigHandler(int) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #2 ? in "/lib64/libc.so.6" #3 double Foam::sumProd<double>(Foam::UList<double> const&, Foam::UList<double> const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #4 Foam::PCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #5 Foam::GAMGSolver::solveCoarsestLevel(Foam::Field<double>&, Foam::Field<double> const&) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #6 Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMatrix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #7 Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #8 Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so" #9 Foam::fvMatrix<double>::solve(Foam::dictionary const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam" #10 Foam::fvMatrix<double>::solve() in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam" #11 ? in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam" #12 __libc_start_main in "/lib64/libc.so.6" #13 ? in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam"
... and the command lines in the readMe! output are pretty long and it is saved in the text file attached here.
So, my questions are:
1. why I have to manually start OF first before I can use the blockMesh component? Should butterfly automatically start OF?
2. what might be the cause of the unsuccessful run of simpleFoam in the end?
Hope you can kindly advise! Thank you!
- Ji
…
tema della modellazione parametrica con Grasshopper. Questa plug-in di Rhino consente di progettare, confrontandosi con un contesto evolutivo, attraverso la comprensione e l'utilizzo di parametri e componenti che influenzano la rappresentazione e la rendono dinamica componendo algoritmi. Nel corso verranno introdotte le nozioni base di Grasshopper approfondendo le metodologie della progettazione parametrica e le tecniche di modellazione algoritmica per la generazione di forme complesse.
Le informazioni teoriche saranno fornite in maniera accelerata ma organica e contestuale agli argomenti elencati. Per massimizzare i risultati, le lezioni saranno accompagnate da piccole esercitazioni pratiche.Argomenti trattati:- Introduzione alla progettazione parametrica: teoria, esempi, casi studio- Grasshopper: concetti base, logica algoritmica, interfaccia grafica- Nozioni fondamentali: componenti, connessioni, data flow- Funzioni matematiche e logiche, serie, gestione dei dati- Analisi e definizione di curve e superfici- Definizione di griglie e pattern complessi- Trasformazioni geometriche, paneling- Attrattori, image sampler- Data tree: gestione di dati complessiStrutturaIl corso ha una durata di 16 ore programmate nell'arco di 2 giornate con i seguenti orari: i giorni 10/11 e 11/11 dalle 10,00 alle 19,00 con pausa pranzo di un'ora.
PrerequisitiPer affrontare il corso è richiesta una conoscenza di base del software Rhino attraverso esperienze teoriche e pratiche. I partecipanti dovranno venire muniti di proprio laptop e con software Rhinoceros 5 o Rhinocero 4 perfettamente funzionanti.Alla fine del corso, verrà rilasciato l’attestato di partecipazione ad un corso qualificato certificato dalla McNeel, valido anche per l’ottenimento di crediti formativi universitari.
…
llet Distance]
[Slider=0..1..10]-->[D][Fillet Distance]
[Slider=1..5..20]-->[F][Unit Z]
[Fillet Distance][C]-->[B][Extrude]
[Unit Z][V]-->[D][Extrude]
This still leaves the problem of having more than one of a single component on the canvas. Referral can be made unambiguous by simply picking the most recent component with the same name. But how do you indicate you want a second Polyline component?
Possible solutions:
Separators in the text:[Point=SetMultiplePoints]-->[V][Polyline]----------------------------------[Point=SetMultiplePoints]-->[V][Polyline]
Keywords or symbols to indicate the creation of a new component rather than the re-use of an existing one:new [Point=SetMultiplePoints]--> new [V][Polyline]new [Point=SetMultiplePoints]--> new [V][Polyline]
(2) is a lot more flexible and (1) may not work at all as it will prevent any reuse above and below the separator.
--
David Rutten
david@mcneel.com…
horas.
Los datos al contextualizar la fachada serán:
Vehículos (ISD: input social data)
Personas (ISD: input social data)
Edificaciones contiguas: (UI: urban input)
Sol (Radiación e iluminación): (EFI: energetic flow input)
Creación de energía solar y térmica: (ECI: energetic contribution input)
Objetivos específicos:
Cada asistente generará una fachada contextual a esos 5 inputs.
Entenderá la plataforma de Grasshopper
Comprenderá los conceptos de diseño generativo
Usará los conceptos de programación orientada a objetos (POO)
Generará renders y modelos físicos de la fachada (Fabricación digital)
Costos: $3,250 alumnos $4,180 alumnos de posgrado y profesores $4,830 profesionales
Aulas VI salón 6205, ITESM CEM
Informes: (55)-34449396 mexdf@krfr.org bioarchitecturestudio@gmail.com
Para más información visitanos en:
Fachadas ContextualesWorkshop >Fachadas Contextuales< KRFR|SEEDKRFR|SEED Red Internacional de Investigación OR/gan
http://www.bioarchitecturestudio.wordpress.com
…
he last nights, let me try to describe it:-disclaimer: I'm an industrial designer, my coding experience can be compared to your, when you were 4 year old :)-disclaimer 2: I did a picture at the end of the post that maybe explains more than my words
the component has 2 inputs (Start Value, End Value) and one output (Picked Value)
this phantomatic component (which I would refere to as "dynamic value picker") supports any amount of domains on every input -> it works as if they come grafted, from a "longest list" component
The component "at rest" shows only one slider -with question marks on both edges-
For every couple on inputs you connect (1 Start Value connection + 1 End Value connection) it would visually generate a new slider (exactly like a "number slider" component)main difference from the "number slider" component, this one would show the Start Value and End Value numbers at the edges of each thus generated slider
Right click -> edit on it would recall a window similar to the "number slider", with the main difference that only the first part of those options would be present (see attached image for clarity)Whatever slide accuracy you set, it will affect the whole "dinamic value picker" phantom component (if you set "integer numbers" and for any reason one or more inputs are "floating points numbers", the component automatically rounds the inputs to the best "Integer", and allows you only to pick integer numbers in-between)
If you suddenly change a "Start Value" or an "End Value" input, the affected slider/sliders in the component will try to stay as close as possible to the same % value they were before (example if the domain was from 5 to 11, integers only, and you first picked the value 8, the slider was exactly in position 50%: when you change the End Value domain to 21 the slider will set itself to 13 - yes, I picked an easy one lol )
When you first plug a couple of Start Value + End Value, the slider sets itself to Picked Value = Start Value
It could also be possible to supply negative values as Value End and positive values as Value Start: the slider let you pick a number on that domain regardless of the numerical order you use
Last thing, but it's just fancy imagination, if you zoom-in the output (Picked Value) connection dot, a little - and + appears (like in other common components), letting you add a new cursor to every existing slider (it could be possible to customize the color of the new cursor to avoid confusion)
This is the exact description of what I would ask to the lamp genie :)
I attach a pic I just did, in the hope to better explain myself: picture link
and of course thank you again for reading this long poem!
…
as the design table? I think this could be 'drawn' and constrained in Inventor in a lot less time. I know the GH model would have a lot of flexibility, but in this case, what can you do with it that wasn't provided by an Inventor model?
Only the 27 lines mentioned were modeled in Rhino, the rest is modeled with GH.
The 5 hrs involved thinking about the approach, defining vertical lines, tilts, elevations, pitch of the roof, intersections.
Once I had decided what my approach would be, and tested the logic with those first lines, points and data path arrangements, it only took one more hour to get to this:
Which is actually quite fast, compared to MCAD workflows.
If you already have components (columns, beams, etc.) modeled and ready to drop into a project, of course it is lightning fast to model simple projects like this example.
I am not as much interested in those situations, because improving efficiency is straightforward and obvious.
I'm more interested in situations where there are no pre-defined families of objects, in which case you need to start from scratch.
The GH model I'm showing is modeled from scratch, except for the 27 lines in Rhino.
Here's one obvious advantage to modeling with GH, once the definition is set-up, it's virtually effortless to change inputs and alter the overall design. Here's an example, lets say we wanted to extend the roof 3 more units, curling away from the original direction.
Plan view before:
And after:
An MCAD app will also allow you to do this, as long as the location of additional elements follows the existing geometric method of definition. What happens if you want completely change the way you locate columns, roof slope, intersection points?
In MCAD, you'll need to re-model the underlying geometry, which will take the same effort as the first round. In GH, this process is not only much faster, it's open to algorithmic approaches, galapagos, etc. and it just takes some simple re-wiring to have all down-stream elements associate themselves to this new geoemtric definition.
For instance, here's the same definition applied to two curves, which are divided in GH, the resulting points are used as a starting point for lines directed at normal from curves.
This is not so easy to do in MCAD.…
Added by Santiago Diaz at 7:55pm on February 24, 2011
occur more than once in the same list, and different elements with identical values can occur more than once. Also, a list may contain lack of elements, referred to as "nulls".
Sets. Strictly speaking a Set is a mathematical construct which adheres to a strict collection of rules and limitations. Basically, a Set is the same as a List, with the exception that it cannot contain the same element more than once, or indeed two or more different elements with the same values. You see, in mathematics there is no difference between a value and an instance of that value, they are the same thing. In programming however it is possible to store the number 7 in more than one spot in the RAM. Grasshopper does not enforce this rule very strongly though, you can use a lot of Set components on lists that have multiple occurrences of the same value. The big difference between Lists and Sets in Grasshopper is that Sets are only defined for simple data types that have trivial equality comparisons. Basically: booleans, integers, numbers, complex numbers, strings, points, vectors, colours and intervals. Lists can contain all kinds of data.
Strings. Strings are text. There's nothing more to it. I don't know why early programmers chose to call them strings, but I suppose it's a better description of the memory representation of them. Strings are essentially sequences of individual characters.
Trees. Trees are the way all data is stored in Grasshopper. Even when you only have a single item, it will still be stored in a tree. A tree is a sorted collection of lists, where each list is identified by a path. A specific path can only occur once in a tree, when you merge two trees together, lists with identical paths are appended to each other. Trees are an attempt to losslessly represent not just the data itself, but also the history of that data. Imagine you have 4 curves {A,B,C,D} and you divide each into 3 points {X,Y,Z}. Then, for each of those points you create a new line segment {X',Y',Z'} and then divide each of those line segments again into 5 points each {K,L,M,N,O}. The way data is stored in trees, it should be possible to figure out whether a point M belongs to X' or to Z', and whether that X' or Z' came from A, B, C or D. This is why paths are often quite long after a while, because they encode a lot of history.
Paths. A Path is nothing more than a list of integers. It's denoted using curly brackets and semi-colons: {A;B;...;Z}. A Path should never be empty {} or have negative integers {0;-1}, but it is certainly possible to create a path like this and it probably won't even crash Grasshopper. Paths are 'grown' by components that (potentially) create more than one output value for a single input value. For example Divide Curve. It creates N points for every single input curve. In cases like this a new integer is appended to the end of the path.
In the next release the Path logic in Grasshopper is somewhat different. I fixed a number of obscure bugs (hopefully without introducing new fresh bugs) and special cased certain operations to somewhat reduce the speed at which paths grow. This may well break files that rely on a specific tree layout, but I hope the temporary sacrifice will be worth the long-term benefits.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…