that are available, I found myself in a quite difficult problematic.
I did a lot of google search/work and found some information, but still kind of haven't got the information that I need or want to use. Note: Our school has provided us 3 hours of basic Grasshopper tutorial and one hour of Honeybee/Ladybug temperature tutorial (with weather data etc).
For now I have used Grasshopper and Kangaroo, haven't quite implemented other plugins.
What I want to achieve?I want to create a basic wind simulation in a room (cube at first, but then add more space and use different models) that I can change inside grasshopper. For example I have two openings. I blow wind inside the object from one opening and it goes out the other opening. When I change the wind parameters I can analyse the wind and data that is flowing through the cube.
Is there a way I can visualize the wind?
I have seen different solutions, but mainly vectors with colors that are visualized as wind direction and temperature. Is it possible to make it 3D that I can actually make a real-life model out of it?
Why cube?At first I want to test it and see how it works, if it is viable or not. In the end I would create a facade that is designed for natural ventilation. I am kind of trying to put two projects together. One for the wind analysis, the other for the 3D-Result that is created with the wind. It might be a quite awful that I am asking, but I don't know where to go after doing the google research. Also, some Grasshopper links I found that might help describe the situation. http://www.grasshopper3d.com/forum/topics/wind-analysis-by-grasshopperhttp://www.grasshopper3d.com/forum/topics/wind-cfd-change-form(Should I approach it with Ladybug and Ecotect?)
Thanks, A
…
d octopus - with karamba causing octopus to crash when running (I believe).
I happen to have visual studio installed; and it reports the following error once it crashes:
"Unhandled exception at 0x00007FF9ADB520B0 (karamba.dll) in Rhino.exe: Fatal program exit requested. occurred"
Attached is the definition file with baked geometry if this helps.
I am currently running Rhino 6 with the latest karamba build.
Details
I aim to create a parametric bridge model - optimising weight and deflection (structural) as well as proximity of 3 movable loads (architectural). The geometry creation is a bit complicated, however I do not think this can ever fail; as I have stress tested this.
The setup for octopus is as follows:
Inputs (for octopus and the parametric model)
Geom. creation (parametric model)
Karamba analysis
Outputs (one is non-karamba, the other two are karamba based)
After an arbitrary number of phenotypes generated (usually around 200), Rhino quits constantly.
I have double checked the following:
Octopus can run with just the inputs (a fake output is created to allow for octopus to run). It does not crash here.
Octopus can run with the inputs and the non-karamba outputs. It does not crash here
Octopus cannot run with the inputs and the karamba outputs. It crashes here
Octopus cannot run with the inputs and all outputs. It crashes here
I have also checked the following:
Geometry generation is built ruggedly (by setting parameter limits appropriately & testing extreme scenarios)
Octopus never receives any value to make it quit (see if statement at the end of karamba parameters)
Any help is appreciated, as I'm currently on a deadline for my thesis on this!
Best,
Alex…
Added by AB to Karamba3D at 9:47pm on March 19, 2018
to parametric design workflows. More information on syntactic design methodology:
My PhD dissertation (see chapters 3 & 4)
Designing with Space Syntax
Syntactic Design Methodology
For more information, videos, news and updates you can visit the following website.
See a video demo-tutorial here.
The plugin is available for download here: https://genesis-lab.dev/products/syntactic/
This plugin is completely compatible with SpiderWeb for Grasshopper and we hereby thank Richard Schaffranek for all we have learned from this extremely useful plugin.
NEW VERSION WAS RELEASED ON JANUARY 25, 2015.
UPDATE: Genesis Lab [webpage][website] is to modernize, open-source, and develop the toolkit starting in December 2021. Stay tuned for updates through my YouTube Channel and ResearchGate. …
you will need to deal with all of the curves that intersect the boundry curve, but you will also need to sort through all of the circles inside because the planar surface algorithm won't sort those out for you. The good news is that because you are using circles and linear segments, you can use "pure" geometry equations for some of these intersections instead of relying on NURBS curve "physical" intersections. In the end this means faster and also "more" reliable intersections (especially with the circles).
Method 1: Dealing with everything as a phyisical curve...
First things first, i guess the "easiest" way to do this would be to translate everything into an OnCurve derived class, and then use the IntersectCurve method to find the intersections. You will need to sort through the resulting ArrayON_XEVENT to find the parameter of each intersection. There should always be 2 intersections, and you're always going to be interested in the intersections of the circle not the boundry curve.
To trim the curves, you'll want to use the Split method along with one of the parameters on the curve that you retrieved from the intersection. The only issue is that the split method gets a bit complicated when using it on closed curves. You could either split at both parameters that you retrieved from the intersection results, then sort through the 3 resulting curves to join the two that you need. Or move the start point of the circle to where one of the intersection points happened, translate the other intersection point to the new curve parameter (ie the parameter will be a different number, but it will be physically in the same place), then split with that new curve parameter.
Method 2: Try and work with the circles as circles
Because you can tell if a circle intersects something by seing if the distance to its center point is less than the radius of the circle, this might be a quicker way to go. If you have the boundry curve as an OnCurve derived class, then you can use the GetClosestPoint method and use all of the center points for each of the circles. The nice thing is that after the 3Dpoint in, and the parameter on the curve that you'll get out, you have the option of supplying a maximum distance. If you do supply that value (use the radius of the circles), then you'll only get a result when the distance is less than or equal to that value. In which case there will be an intersection.
To go even further, you can treat the segments of the boundry curve each as a line, and find the closest point/distance to that. That's maybe more complex than your looking to go, but speed wise, it might just be worth it. Take a look at the following link for more code/discussion on the subject.
http://www.codeguru.com/forum/showthread.php?t=194400
Part 2: Circle-Circle intersections
If you're going to want to make a planar surface out of those circes and the boundry curve, then you'll need to resolve all of the intersections that you have there. Again this is probably something that would be best taken care of by doing some distance tests between the center points of all the circles and seeing if that distance is less than the radius your using. After you've found circles that intersect, you can be try intersecting the curves using the same method mentioned above, or even manually generating the intersection with some trig, but ultimately creating a final result might take a bit of work, especially where you have more than two circles intersecting. The "lazy" way out of this is what's used by the curve boolean command, which is to take each individual curve, make a planar surface from that individual curve, and use standard Rhino booleans to get the result. Luckily you're looking for the union of all those areas, which will be the easiest to create and deal with. After you create the planar surface of each one (RhUtil.RhinoMakePlanarBreps), you can use either RhUtil.RhinoBooleanUnion or the more specialized version, RhUtil.RhPlanarRegionUnion. Note that RhPlanarRegionUnion only takes 2 breps at a time and needs the plane of the intersection.…
ake a network of lines (i.e. a graph) and make a Plankton Mesh, from which you can use Cytoskeleton to make a solid mesh (and then smooth it with Weaverbird).
Works with ngons (polygons with 3 or more sides). Other examples I found only worked with tris and quads.
Works on open or closed surfaces
While these examples start with a surface, you could start with a network of lines and make a patch surface
This is meant for 2D networks/surfaces. I haven't attempted filling a 3D volume. My guess is this wouldn't work as it would require a non-manifold mesh that Plankton wouldn't handle.
Note similar results could be achieved with the following:
TSplines
MeshDual (dual of a tri mesh, not as much freedom/control)
Working backwards, here is the GhPython script from Will Pearson that builds a Plankton Mesh from vertices and faces. The vertices are a list of 3D coordinates, the faces are a tree a lists, with each list containing the indices of vertices that form a closed loop. From Will, "Plankton only handles manifold meshes, i.e. meshes which have a front and a back. This orientation is determined by the "right-hand rule" i.e. if the vertices of a face are ordered counter-clockwise then the face normal will be out of the page/screen."
# V: list of Point3d # F: tree of int
import Grasshopper appdata = Grasshopper.Folders.DefaultAssemblyFolder
import clr clr.AddReferenceToFileAndPath(appdata + "Plankton.dll")
import Plankton
pmesh = Plankton.PlanktonMesh()
for pt in V: pmesh.Vertices.Add(pt.X, pt.Y, pt.Z)
for face in F.Branches: face = list(face)[:-1] pmesh.Faces.AddFace(face)
These vertices and faces are precisely the output from Starling. Starling takes in a list of Polylines which form the (properly oriented) face loops.
The polyline face loops can be generated...
Directly from Panels on a surface using LunchBox
Using any network of lines/curves on a surface (curves will need to be converted to polylines before Starling)
The latter was achieved using the Surface Split command, then converting the face edges (converted to curves) into polyline loops to represent faces.
…
requires four weather data inputs: air temperature (_dryBulbTemperature), relative humidity (relativeHumidity_), wind speed at 1.1 meters from the ground (windSpeed_) and mean radiant temperature (meanRadiantTemperature_).You can add values to the first three inputs from the Ladybug "Import Epw" component. For the last (meanRadiantTemperature_), you can add it from Ladybug's "Outdoor Solar Adjusted Temperature Calculator" component, or let "Thermal Comfort Index" component to calculate it. Both use different methods to calculate the final values.
I attached an example file below with second option.For more precise calculations you can use Honeybee and Chris' microclimate maps.An icing on the cake for the end: one of Ladybug developers yesterday released a set of Ladybug components for modelling in ENVI-met application. ENVI-met is cutting-edge microclimate software, which can be downloaded for free. It opens a number of advanced new analysis in outdoor domain, which couldn't have been done with the current Ladybug+Honeybee tools. So you can perform the simulation in ENVI-met 4 free software, and then add mean radiant temperature values from ENVI-met simulation to "Thermal Comfort Indices" component. Here is an example file.If you would like to go with the last approach, then the best would be to post a question about it in this topic.
1) You can make a polygonized tree.I haven't subtracted the trunk from the crown, but I guess it makes sense that it can be done.2) In most solar related simulations, a default albedo value of 0.2 is used. This corresponds to average albedo value taken from materials surrounding the urban or countryside location (concrete, grass, gravel, sand, asphalt...). However the presence of snow can significantly magnify the average albedo value several times. "Sunpath shading" components albedo_ input has an ability to calculate albedo due to presence of snow, if nothing is added to it (to albedo_ input). As you are performing the analysis of PET in a horizontal plane, it will not affect your calculations.3) Most thermal comfort indices will require performing analysis at 1.1 meters above the ground. This is considered to be height of standing person's gravity center.The same goes for PET index. So you are correct: you should place the analysis grid at 1.1 meters above the ground before adding it to the "Sunpath Shading" component.It is worth mentioning that "Thermal Comfort Indices" component used in this topic's PET_on_Grid2.gh and PET_on_Grid3.gh files is from last year, and much slower than the newest one (VER 0.0.64 MAR 18 2017) used in the example attached below. Just a remainder if you have been using older version of this component.Let me know if I misunderstood some of your questions, or if I missed to answer some of them.
EDIT: sorry for posting a double reply. When I posted it the first time, I only got links visible, with no text. Something has been wrong with grasshopper ning forum for the last couple of months.…
). It deals with the potential possibility to port GH into AEC fields (real-life AEC fields, nothing to do with academic thinking). The bad news are that the smart AEC sector is occupied solely by Bentley/GenComp – expect soon Revit/Dynamo as well (not to mention CATIA). The good news are that there’s millions of designers/engineers/industrial designers out there who could be interested for a 3rd alternative.
Intro: Well, in the old days (when men had mustache and muttonchops) AEC design performed in a nice top-to-bottom sequence (kinda like a vector) : the Big Man (aka The Brain) did some sketches (with crayons) and the rest (known as the “others”) struggled to make The Idea a reality. Today things are different, mind. Or they should be different. Or may be different. Or whatever. The big easy:For a zillion o reasons (AEC matures, PLM, cost, outsourcing, sustainable engineering…add several more) this vector like process of the past is like a Brown motion these days: Right down the moment that you (or your team) “sketch” The Big Idea … another team design simultaneously (i.e. in parallel) the components (parts) that compose the whole. This is the so called bottom-to-top design mentality. So the whole and the parts meet in some "middle point" instead the later being dictated by the former. In quite a few occasions parts dictate the whole (cost, cost and cost being the main reasons). The more a design is contemporary the more this bottom-to-top thing plays a critical role. Ignore it and have a very big time (sooner or later).The bad news:If you accept the above…well GH – at present phase - is not ready for contemporary AEC work. At.All.3 Main reasons for that:1.You can’t use parametric parts (i.e. nested blocks to speak Rhino language) into a given definition (in this case attached : truss nodes, connection flanges, mount plates, cable tensioners, planar glazing components, roof skin components…etc etc). This is obviously a Rhino domain.2.You can’t bake a given solution in such a way that the Rhino file is structured (i.e. assemblies of nested blocks). Or you can do it theoretically writing some VB/C code – but the core of the matter is that corresponding components are MIA. That means that you can’t export anything useful actually into established AEC oriented apps and/or established MCAD apps (for doing/calculating the parts for real-life production).3.The GH process can’t being interrupted. Imagine defining, say, a building “envelope” in GH and then …er…use Evolute tools in order to optimize things (say quad planarization and the likes). Then …continue in GH for more detailed work. Then design the parts as in 1 above. Then back to Evolute. Then back to GH.So…if anyone is interested I would be glad to start the mother of all debates and/or some kind of crusade (GH for President, that is).PS: This definition is a WIP thing – more refined stuff to follow (in particular a complex canopy tubes pre-stress system).
PS: Tree8 components are used sporadically.
PS: Use Saved Views
May the Dark Force be with us.Best, Peter …
. From the Thermal Comfort Indices component, Comfort Index 11 (TCI-11):MRT = f(Ta, Tground, Rprim, e)
with:- Ta = DryBulbTemperature coming from ImportEPW component- Tground = f(Ta, N) where N comes from totalSkyCover input. Tground influences the long-wave radiation emitted by the ground in the MRT calculation.- Rprim defined as solar radiation absorbed by nude man = f(Kglob, hS1, ac)- ac is the clothingAlbedo in % (bodyCharacteristics input)- I can't find any definition in the code of Kglob and hS1. Could you tell me please what are those values referencered to? --> probably the globalHorizontalRadiation but how?- e = vapour pressure calculated from Ta and Relative Humidity input
Do you agree that in this case the MRT does not depend on these inputs: location, meanRadiantTemperature, dewPointTemperature and wind speed?It does not depend neither on the other bodyCharacteristics like bodyPosture, age, sex, met, activityDuration...?
MRT calculated by the TCI-11 method is the mean radiant temperature of a vector pointing vertically with a sky view factor of 100%?For ParisOrly epw,
2. From the SolarAdjustedTemperature component (that seems to be more used for the UTCI calculation examples on Hydra compared to TCI-11).
In contrast to the TCI-11, this component distinguishes diffuse and direct radiation and contextualizes the calculation thanks to _ContextShading input, right? It can also be applied to a mannequin thanks to the CumSkyMatrix and thus evaluate the dishomogeneity of radiation exposure.This component seems not to consider the influence of vapour pressure on the result --> is it then more precise to put the MRT output (from the TCI) as an input of meanRadTemperature for SolarAdjustedTemperature?The default groundReflectivity is set to 0.25 --> is GroundReflectivity taken into account in the Tground or MRT calculation in the TCI component? If yes, what is the hypothesised groundReflectivity?The default clothing albedo of 37% (TCI-11 bodyCharacteristics) corresponds to Clothing Absorptivity of 63%?
If the CumSkyMatrix input is not supplied, I get 9 results for the mannequin --> where are those points/results coming from?
If the CumSkyMatrix input is supplied,I suppose the calculation of the 482 results correspond to a calculation method similar to the radiation analysis component that is averaged over the analysis period. Right?But I don't understand why the mannequin is composed of 481 faces and meshFaceResult gives 482 results.
Finally, what is the link between the MESH results, the solarAdjustedMRT and the Effective Radiant field ? Is there a paper to have a detailed explanation of the method?
3. Here are some results for the ParisOrly energyplus weather data. You can find here attached the grasshopper definition.There is no shading in this simulation and the result coming from the ThermalComfort indices for MRT is very different compared to the solar adjusted MRT.Why such a big difference and which of the result should be plugged into the UTCI calculation component?
Results for ParisOrly.epwM,D,H:1,1,12
Ta : 6.5°Crh: 100%globalHorizontalRadiation: 54 Wh/m2totalSkyCover: 10MRT (TCI-11): 1.2°C
_CumSkyMtxOrDirNormRad = directNormalRadiation : 0 Wh/m2diffuseHorizontalRad: 54 Wh/m2_meanRadTemp = TasolarAdjustedMRT: 10.64°CMRTDelta: 4.14°C
_CumSkyMtxOrDirNormRad = CumulativeSkyMtxdiffuseHorizontalRad: 54 Wh/m2_meanRadTemp = TasolarAdjustedMRT: 10.47°CMRTDelta: 3.97°C
_CumSkyMtxOrDirNormRad = CumulativeSkyMtxdiffuseHorizontalRad: 54 Wh/m2_meanRadTemp = MRT (TCI-11)solarAdjustedMRT: 5.17°CMRTDelta: 3.97°C
Thanks a lot for your helpRegards,
Aymeric
…
hope this number will grow in future. Currently available features are:
1) Creation of 2d or 3d context for any kind of building related analysis: automatically generate the 2d/3d surrounding buildings for the location where you would like to perform visibility, solar radiation, cfd or any other type of analysis. You need some other plugin for the last three, like Ladybug. It only creates the context=surroundings! The "automatic generation" process also includes creation of the local topography (terrain) along with buildings.
2) Identification of certain 2d or 3d elements in the created context. For example: selection of all hotels, parks, hospitals, restaurants, residential buildings etc.
3) Performing direct terrain analysis (hillshading, slope, ruggedness, roughness, water flow...)
4) Creation of terrain shading masks and horizon files for further solar and photovoltaics analysis.
Gismo will be very grateful if he could get any suggestions, improvements, bug reports and testing in the following period. In case you are willing to provide any of these, the requirements, installation steps and .gh example files can be found here, here and here.
Thank you in advance !!…
Added by djordje to Gismo at 9:10am on January 29, 2017
Introduction to Grasshopper Videos by David Rutten.
Wondering how to get started with Grasshopper? Look no further. Spend an some time with the creator of Grasshopper, David Rutten, to learn the