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…
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…
phere with the maximum number of triangles but not much than a defined threshold.
I scaled that mesh just to fit Rhino grid, but it is not mandatory. What is useful, is to scale not uniformly the mesh (Scale NU). It could be done after cellular modifier applied or before or before and after. The 3 options are possible in the script. If you don’t need them just put 1 in scale sliders.
Ellipsoid mesh is the populated with points, I put 2 independents populations to randomize a bit further. For each vertices of the mesh the closest distance from the populated points is calculated.
Here is an illustration in color of this distance.
This distance is then used to calculate a bump. If domain for bump is beginning with negatives values to 0, it carves the mesh. Instead it bumps/inflates it.
Some images to illustrate the difference with populating 100 points with one or two populations.
Here some images to illustrate the application of scale before carving or after.
Next phase apply noise. At the moment I don't find it good.…
GH, same as using sweep2 command in Rhino.
The one on the right is what I got so far (the output smooth our the kink of the original rails). Basically I am just following the methods provided by sdk sample: http://wiki.mcneel.com/developer/sdksamples/sweep2 .
The following is the function I copy and use directly from the SDK sample. By using this function, I can generate the sweep surface at right. But I want to have is the one in the middle with the kink edges. Can anyone show me how and where to modify he settings? I guess some sweep arguments need to be changed? I have try couples, such m_simplify, m_bSimpleSweep, m_bSameHeight, m_rebuild_count... but still cannot find a right combination for this function to output the sweep surface I want. Any suggestions or helps are very appreciated. Thanks for your help and time on this.
'Sweep2 function'----------------
Sub Sweep2( ByVal Rail1 As IOnCurve, _
ByVal Rail2 As IOnCurve, _
ByVal sCurves As List(Of IOnCurve), _
ByRef Sweep2_Breps As List(Of OnBrep))
'Define a new class that contains sweep2 arguments
Dim args As New MArgsRhinoSweep2
'Set the 2 rails
Dim Edge1 As New MRhinoPolyEdge
Dim Edge2 As New MRhinoPolyEdge
Edge1.Append(Rail1.DuplicateCurve())
Edge2.Append(Rail2.DuplicateCurve())
'Add rails to sweep arguments
args.m_rail_curves(0) = Edge1
args.m_rail_curves(1) = Edge2
args.m_bClosed = False
Dim section_curves As New List(Of OnCurve)
'Loop through sections to set parameters
For Each Section As IOnCurve In sCurves
Dim sCurve As OnCurve = Section.DuplicateCurve()
section_curves.Add(sCurve)
Dim t0 As Double = 0
If Not Edge1.GetClosestPoint(sCurve.PointAtStart(), t0) Then
If Not Edge1.GetClosestPoint(sCurve.PointAtEnd(), t0) Then
Dim s As Double = 0
sCurve.GetNormalizedArcLengthPoint(0.5, s)
Edge1.GetClosestPoint(sCurve.PointAt(s), t0)
End If
End If
args.m_rail_params(0).Append(t0)
Dim t1 As Double = 0
If Not Edge2.GetClosestPoint(sCurve.PointAtStart(), t1) Then
If Not Edge2.GetClosestPoint(sCurve.PointAtEnd(), t1) Then
Dim s As Double = 0
sCurve.GetNormalizedArcLengthPoint(0.5, s)
Edge2.GetClosestPoint(sCurve.PointAt(s), t1)
End If
End If
args.m_rail_params(1).Append(t1)
Next
'Set shapes
args.m_shape_curves = section_curves.ToArray
'Set the rest of parameters
args.m_simplify = 0
args.m_bSimpleSweep = False
args.m_bSameHeight = False
args.m_rebuild_count = -1 'Sample point count for rebuilding shapes
args.m_refit_tolerance = RMA.Rhino.RhUtil.RhinoApp.ActiveDoc.AbsoluteTolerance()
args.m_sweep_tolerance = RMA.Rhino.RhUtil.RhinoApp.ActiveDoc.AbsoluteTolerance()
args.m_angle_tolerance = RMA.Rhino.RhUtil.RhinoApp.ActiveDoc.AngleToleranceRadians()
Dim sBreps() As OnBrep = Nothing
If (RhUtil.RhinoSweep2(args, sBreps)) Then
For Each b As OnBrep In sBreps
Sweep2_Breps.Add(b)
Next
End If
Return
End Sub
…
ve Intermediate Insight of Computational Design Strategies While Exploring Rangoli Art form in 2 Dimension and 3Dimesion in which Participants will not only be trained to Digitally Design using Parametric software's but they will also be trained to Fabricate them in reality.
This Course will be explored in manner where Participants will understand inter-dependency of Rhinoceros3D & Grasshoper3D through a unique Hybrid Teaching Method While Exploring Rangoli Geometry .
The course will also take participants through Topics such as - Computational Thinking, - Computational / Parametric Design, - Computational Rangoli Exploration, - Digital Fabrication, - 3D Visualization ( Rhino3D 6), - Making Info-graphics & Design Diagrams ( Rhino3d 6 ).
Participants will also be doing a Project at the last Leg of Workshop in which they will implement the skill they gained in first Few Weeks.
{ Tutor } Nitant Pixelkar (Computational Artist / Designer, Mumbai)
Nitant Hirlekar A.k.a. Pixelkar, is a Computational Artist. He graduated from Rachana Sansad school of Interior Design 2011, Mumbai. In Academics He Bagged Two Gold and One Silver Medal on National Level.
In his post academic days, he came across the Emerging Computational Techniques in Design industry in which Algorithm serves as a main Functional part. He uses Algorithms to Deconstruct the Captured images in Pixelated form using the Grid of the Desired Indian Art Forms.
He Heads Collective Group Named "Mutation Lab” which is a multidisciplinary Design & Art Cell. Where they Explore Computational Approach while Designing Various Scales Spatial Installation, Digital Fabrication, Interactive Installations and Computational Consultancy for Various Architects.
He has exhibited his first artwork in Kalaghoda Arts Festival for in 2014 And further in 2016 and 2017.In 2015 he exhibited in Dharavi Biennale” organized by Wellcome Trust,London & Sneha Organisation, Mumbai Which was internationally acclaimed. In 2016 he got Featured on a TV show - The Creative Indian's as an Absolut Creative Indian of the Week.
Academically he is been involved in Many Computational Design Workshops / Elective Studios for School of Interior Design (Rachna Sansad), LS Raheja College of Architecture & Rat-Lab (Delhi).
{ Participants } The Course is aimed at Architecture, Interior Design, Product Design,Furniture Design & Fashion Design Students and Professionals. However we would be thrilled to have any Interdisciplinary Artist / Creator/ Maker to join the Course as well.
{ Level }
Intermediate
{ Timing } Monday To Friday - 6:00 PM to 9:00 PM (15 Hours/ Week = 5 Week X 15 Hours = 75 Hours )
{ Dates } Registration Ends - 24th April 2020 **Subejct to Availablity
{ Workshop Dates } 4th May 2020 To 5th June 2020
{ Venue } Lower Parel,Mumbai ( Details To Be Announced )
{ Schedule }
{Registration Form}…
, Engineer and Researcher from France with broad programming experience. He is the author of the City in 3D Rhinoceros plugin for creation of buildings according to geojson file and with real elevation. Guillaume already created a new component: "Address to Location". It enables getting latitude and longitude values for the given address:
2) Support of Bathymetry data: automatic creation of underwater (sea/river/lake floor) terrain. This feature is now available through new source_ input of the "Terrain generator" component. Here is an example of terrain of the Loihi underwater volcano, of the coast of Hawaii:
3) A new terrain source has been added: ALOS World 3D 30m. ALOS is a Japanese global terrain data. Gismo "Terrain Generator" component has been using SRTM 30m terrain data, which hasn't been global and was limited to -56 to +60 latitude range. With this addition, it is possible to switch between SRTM and ALOS World 3D 30m models with the use of source_ input.
4) 9 new components have been added:
"Address To Location" - finds latitude and longitude coordinates for the given address.
"XY To Location" - finds latitude and longitude coordinates for the given Rhino XY coordinates. "Location To XY" - vice versa from the previous component: finds Rhino XY coordinates for the given latitude longitude coordinates. "Z To Elevation" - finds elevation for particular Rhino point. "Rhino text to number" - convert numeric text from Rhino to grasshopper number. "Rhino unit to meters" - convert Rhino units to meters. "Deconstruct location" - deconstructs .epw location. "New Component Example" - this component explains how to make a new Gismo component, in case you are interested to make one. We welcome new developers, even if you contribute a single component to Gismo! "Support Gismo" - gives some suggestions on how to make Gismo better, how to improve it and support it.
5) Ladybug "Terrain Generator" component now supports all units, not only Meters. So any Gismo example file which uses this component, can now use Rhino units other than Meters as well. Thank you Antonello Di Nunzio for making this happen!!
Basically just forget about this yellow panel:
This panel is not valid anymore, so just use any unit you want.
6) A number of bugs have been fixed, reported in topics for the last couple of weeks. We would like to thank members in the community who invested their time in testing, finding these bugs and reporting them: Rafat Ahmed, Peter Zatko, Mathieu Venot, Abraham Yezioro, Rafael Alonso. Thank you guys!!! Apologies if we forgot to mention someone.
The version 0.0.2 can be downloaded from here:
https://github.com/stgeorges/gismo/zipball/master
And example files from here:
https://github.com/stgeorges/gismo/tree/master/examples
Any new suggestions, testing and bug reports are welcome!!…
Added by djordje to Gismo at 5:13pm on March 1, 2017
y using the Honeybee_Update Honeybee component.
The video below (best viewed in full-screen mode) provides an idea of what these components are capable of being used for:
The video below shows how these components can be used in an existing Honeybee project (for additional links please open this video in youtube):
I have uploaded two examples as Hydra files that show how these components can be used for grid-point and image-based simulations:
Example1 : Grid Point Calculations
Example2: Image based simulation
Finally, a more esoteric application is demonstrated in this video:
These components are still in the beta-testing stage. Some of the limitations of the components are:
1. Only Type C photometry IES files are supported at present.
2. Rhino is likely to get sluggish if there are too many luminaires (i.e. light fixtures) present in a scene.
3. Due to the spectral limitations of the ray-tracing software (RADIANCE), simulations involving color mixing might not be physically realizable.
Additional details about photometric and spectral calculations are probably an overkill for this forum. However, I'd be glad to answer any related questions. Please report any bugs or request new features either on this forum or on Github.
Mostapha, Leland Curtis, Reinhardt Swart and Dr. Richard Mistrick provided valuable inputs during the development of these components.
Thanks,
Sarith
Update 16th January 2017:
An example with some new components and bug fixes since the initial release announcement can be found here
…
ay how many valid permutations exist.
But allow me to guesstimate a number for 20 components (no more, no less). Here are my starting assumptions:
Let's say the average input and output parameter count of any component is 2. So we have 20 components, each with 2 inputs and 2 outputs.
There are roughly 35 types of parameter, so the odds of connecting two parameters at random that have the same type are roughly 3%. However there are many conversions defined and often you want a parameter of type A to seed a parameter of type B. So let's say that 10% of random connections are in fact valid. (This assumption ignores the obvious fact that certain parameters (number, point, vector) are far more common than others, so the odds of connecting identical types are actually much higher than 3%)
Now even when data can be shared between two parameters, that doesn't mean that hooking them up will result in a valid operation (let's ignore for the time being that the far majority of combinations that are valid are also bullshit). So let's say that even when we manage to pick two parameters that can communicate, the odds of us ending up with a valid component combo are still only 1 in 2.
We will limit ourselves to only single connections between parameters. At no point will a single parameter seed more than one recipient and at no point will any parameter have more than one source. We do allow for parameters which do not share or receive data.
So let's start by creating the total number of permutations that are possible simply by positioning all 20 components from left to right. This is important because we're not allowed to make wires go from right to left. The left most component can be any one of 20. So we have 20 possible permutations for the first one. Then for each of those we have 19 options to fill the second-left-most slot. 20×19×18×17×...×3×2×1 = 20! ~2.5×1018.
We can now start drawing wires from the output of component #1 to the inputs of any of the other components. We can choose to share no outputs, output #1, output #2 or both with any of the downstream components (19 of them, with two inputs each). That's 2×(19×2) + (19×2)×(19×2-1) ~ 1500 possible connections we can make for the outputs of the first component. The second component is very similar, but it only has 18 possible targets and some of the inputs will already have been used. So now we have 2×(18×2-1) + (18×2-1)×(18×2-1) ~1300. If we very roughly (not to mention very incorrectly, but I'm too tired to do the math properly) extrapolate to the other 18 components where the number of possible connections decreases in a similar fashion thoughout, we end up with a total number of 1500×1300×1140×1007×891×789×697×...×83×51×24×1 which is roughly 6.5×1050. However note that only 10% of these wires connect compatible parameters and only 50% of those will connect compatible components. So the number of valid connections we can make is roughly 3×1049.
All we have to do now is multiply the total number of valid connection per permutation with the total number of possible permutations; 20! × 3×1049 which comes to 7×1067 or 72 unvigintillion as Wolfram|Alpha tells me.
Impressive as these numbers sound, remember that by far the most of these permutations result in utter nonsense. Nonsense that produces a result, but not a meaningful one.
EDIT: This computation is way off, see this response for an improved estimate.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
Added by David Rutten at 12:06pm on March 15, 2013
try now to integrate Geco in an interdisciplinary architectural engineering studio: hoping we can show you some nice applications of your tool, I'll keep you update and sending now details by e-mail. Here the file (very welcome to be shared). It most probably contais trivial errors by me, thanks for helping and giving some tip! Gr. Michela
FILE:
Ok, right, I see the outputs update correctly. Origin of problems must be in some different mistake I do:
- Incident radiation: I am not sure I understand what is going on: why I get so many 'not a number' ? (The Galapagos report is full of NaNs).
Bio-Diversity: 0.887 Genome[0], Fitness=NaN, Genes [89% · 44%] { Record: Too many fitness values supplied } ...
Genome[7], Fitness=NaN, Genes [74%] { Record: No fitness value was supplied } ....
Genome[9], Fitness=NaN, Genes [37% · 11%] { Record: Genome was mutated to avoid collision Record: Too many fitness values supplied }
- Daylight calculations: the geometry accumulates withouth deleting the previous models. As a consequance, results almost do not change after few varations (so, outputs get updated but do not vary). In current daylight definition: the first object being imported is the one where the grid has to fit; its setting makes it cancelling all the other objects during import. All the others, do not delete anything when imported. When running loops (manual or GA) that vary parameters, the entire geometry do not get cancelled - so I guess the loop does not pass back by the cancelling step, but imports only the geometry which has been varied by the parameters using the setting of that import component only? I will then try again by changing the order of the operations, but if you have specfic tips, let me know.
THANKS!
…
mplex the models are. If we are running multi-room E+ studies, that will take far longer to calculate.
Rhino/Grasshopper = <1%
Generating Radiance .ill files = 88%
Processing .ill files into DA, etc. = ~2%
E+ = 10%
Parallelizing Grasshopper:
My first instinct is to avoid this problem by running GH on one computer only. Creating the batch files is very fast. The trick will be sending the radiance and E+ batch files to multiple computers. Perhaps a “round-robin” approach could send each iteration to another node on the network until all iterations are assigned. I have no idea how to do that but hope that it is something that can be executed within grasshopper, perhaps a custom code module. I think GH can set a directory for Radiance and E+ to save all final files to. We can set this to a local server location so all runs output to the same location. It will likely run slower than it would on the C:drive, but those losses are acceptable if we can get parallelization to work.
I’m concerned about post-processing of the Radiance/E+ runs. For starters, Honeybee calculates DA after it runs the .ill files. This doesn’t take very long, but it is a separate process that is not included in the original Radiance batch file. Any other data manipulation we intend to automatically run in GH will be left out of the batch file as well. Consolidating the results into a format that Design Explorer or Pollination can read also takes a bit of post-processing. So, it seems to me that we may want to split up the GH automation as follows:
Initiate
Parametrically generate geometry
Assign input values, material, etc.
Generate radiance/ E+ batch files for all iterations
Calculate
Calc separate runs of Radiance/E+ in parallel via network clusters. Each run will be a unique iteration.
Save all temp files to single server location on server
Post Processing
Run a GH script from a single computer. Translate .ill files or .idf files into custom metrics or graphics (DA, ASE, %shade down, net solar gain, etc.)
Collect final data in single location (excel document) to be read by Design Explorer or Pollination.
The above workflow avoids having to parallelize GH. The consequence is that we can’t parallelize any post-processing routines. This may be easier to implement in the short term, but long term we should try to parallelize everything.
Parallelizing EnergyPlus/Radiance:
I agree that the best way to enable large numbers of iterations is to set up multiple unique runs of radiance and E+ on separate computers. I don’t see the incentive to split individual runs between multiple processors because the modular nature of the iterative parametric models does this for us. Multiple unique runs will simplify the post-processing as well.
It seems that the advantages of optimizing matrix based calculations (3-5 phase methods) are most beneficial when iterations are run in series. Is it possible for multiple iterations running on different CPUs to reference the same matrices stored in a common location? Will that enable parallel computation to also benefit from reusing pre-calculated information?
Clustering computers and GPU based calculations:
Clustering unused computers seems like a natural next step for us. Our IT guru told me that we need come kind of software to make this happen, but that he didn’t know what that would be. Do you know what Penn State uses? You mentioned it is a text-only Linux based system. Can you please elaborate so I can explain to our IT department?
Accelerad is a very exciting development, especially for rpict and annual glare analysis. I’m concerned that the high quality GPU’s required might limit our ability to implement it on a large scale within our office. Does it still work well on standard GPU’s? The computer cluster method can tap into resources we already have, which is a big advantage. Our current workflow uses image-based calcs sparingly, because grid-based simulations gather the critical information much faster. The major exception is glare. Accelerad would enable luminance-based glare metrics, especially annual glare metrics, to be more feasible within fast-paced projects. All of that is a good thing.
So, both clusters and GPU-based calcs are great steps forward. Combining both methods would be amazing, especially if it is further optimized by the computational methods you are working on.
Moving forward, I think I need to explore if/how GH can send iterations across a cluster network of some kind and see what it will take to implement Accelerad. I assume some custom scripting will be necessary.…