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.…
search for residential type and surprisingly there are none. This can be, but i'm surprised.
The location in example is the Financial District of Manhattan. I assume there might not be too many purely residential buildings there. If you increase the radius to 300meters it will find one.The OSMobject "Residential building" will look for mostly purely residential buildings. For example those in Chinatown or Lower East Side.However most of the time a building might be a multi-purpose: shops on the ground floor, offices above, and above them residential apartments. Users can sometimes avoid tagging these kind of buildings, and may just tag them with "buildings"="yes", not the type of the building too (for example: "building"="multiuse"). So this may be the problem why you might not get too many residential buildings.I guess the only solution to this issue is to add these tags by yourself. Then Gismo will instantly make use of them.I mentioned previously that I will create a couple of video tutorials, but I seemed to never found enough time. I apologize for that. The process is actually quite simple.
Here is small step by step tutorial on how to do that. It may take you about 2 minutes to tag your building and use that tag in Gismo.
Also office buildings. I imagine this is not up to you, but can be kind of disappointing. I wanted for example to do some Ladybug analysis only on residential or office buildings ... pitty.
"Office building" has not been added to "OSMobjects" dropdown list. I have just added it.However, whenever some sort of object is not defined in "OSMobjects" dropdown list, one can use the _requiredKey and requiredValues_ inputs of the "OSM tag" component:
I just tried looking for office building for the same location we have in the create_legend_example.gh file and it found 3 of them. There would probably need to be more, but it may be that nobody tagged those with "building"="office"
The legend is nice, though i think is not completely synchronized with the LegendBakeParameters: You need to provide a point for the LegenPlane input and another for the titleOriginPt output of the CreateLegend.
Unlike Ladybug, Gismo threats the title and the legend separately. So the legend's color bar would have its own starting point (plane) while the title will have its own. I found myself puzzled sometimes in Ladybug, why this wasn't possible.Or did I misunderstand you?…
Added by djordje to Gismo at 12:33pm on May 8, 2017
a direct answer for you, in part because that statement suggests a complicated data tree indeed! And in part because I can't quite shake the question "Why?".
It's my nature to "think out of the box" and as you may have noticed, my answers in the other two threads related to this topic weren't quite what you asked for. The first question that comes to mind in this case is why look for the two closest trunks? Why not just the closest or why not "N" (all or all those within a given radius)?
The next question is why use a plane intersection at arbitrary height to get a point on each trunk for measuring distances between them?
So please bear with me as I explain how I've explored this problem so far, knowing I don't have an answer yet and, in fact, am not even sure that the question makes sense to me. ;)
First, I got tired of looking at these upside down "trees" so I flipped them right side up. I used 'Mirror' instead of 'Rotate' which might cause problems? But lets move on. I changed your preview colors so they wouldn't conflict with my 'Tree/List Viewer' defaults and to increase contrast a bit.
Then I skipped your methods for finding "Cluster 'B' and 'C'" and used 'Curve Proximity' between the trunks instead.
This is hard to convey with a static image but might make more sense interactively. There are two copies of 'Tree/List Viewer'; the second one ("slave" group) is driven by the set of sliders in the first one. As you move the 'path idx' slider, one of the trunks will be cyan in color, as set above. The others will be blue except for one that is yellow. As you move the 'list idx' slider, the yellow highlight will move among the blue trunks, showing the closest trunk at 'list idx' = 0 and the furthest at 'list idx' = 3 (five trunks total, one selected by 'path idx' and the other four by 'list idx'. The result is that for each trunk, we have all the other trunks sorted by distance.
That's all for now! There is a very simple way to connect the 'Twigs' instead of the 'Trunks' to 'Crv A' with interesting results, but it requires flattening the 'Twigs' so isn't as useful as we want.
The big question for me remains: what is the data/tree structure of the results you seek? From the statement I quoted above, it sounds like:
One branch per trunk.
For each trunk, one branch per twig? (or...?)
For each twig branch...? A list of distances to each of the other trunks? (or a list of the other trunks sorted by their distances from this twig?)
It sounds like a complicated mess, frankly. And again begs the question, why? What's the underlying goal beyond the objectives you have outlined so far?…
Added by Joseph Oster at 7:59pm on November 14, 2017
). 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 …
lC_UtilEigenSystemSym (level 1) { Exception has been thrown by the target of an invocation. TargetInvocationException }
Object: MillC_UtilEigenSystemSym (level 2) { Could not load file or assembly 'Sawapansolversnet, Version=1.0.4490.29339, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified. FileNotFoundException }
Object: MillC_Topostruct2D (level 1) { Exception has been thrown by the target of an invocation. TargetInvocationException }
Object: MillC_Topostruct2D (level 2) { Could not load file or assembly 'Sawapansolversnet, Version=1.0.4490.29339, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified. FileNotFoundException }
Object: MillC_Topostruct3D (level 1) { Exception has been thrown by the target of an invocation. TargetInvocationException }
Object: MillC_Topostruct3D (level 2) { Could not load file or assembly 'Sawapansolversnet, Version=1.0.4490.29339, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified. FileNotFoundException }
Object: MillC_FEASystem (level 1) { Exception has been thrown by the target of an invocation. TargetInvocationException }
Object: MillC_FEASystem (level 2) { Could not load file or assembly 'Sawapansolversnet, Version=1.0.4490.29339, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified. FileNotFoundException }
Object: MillC_UtilFFT1D (level 1) { Exception has been thrown by the target of an invocation. TargetInvocationException }
Object: MillC_UtilFFT1D (level 2) { Could not load file or assembly 'Sawapansolversnet, Version=1.0.4490.29339, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified. FileNotFoundException }
Object: MillC_UtilFFT2D (level 1) { Exception has been thrown by the target of an invocation. TargetInvocationException }
Object: MillC_UtilFFT2D (level 2) { Could not load file or assembly 'Sawapansolversnet, Version=1.0.4490.29339, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified. FileNotFoundException }
EDIT: Even with COFF disabled in GrasshopperDeveloperSettings this still happens (Thanks Jon)
Is millipede not compatible with Rhino version 5? Or is there a different .dll to use?
Having loaded some of the components:
I congratulate you on following Rutten's 3rd law of Grasshopper :)
Although I hope the Solver and especially the Stress lines get further refinement in order to differentiate them as I find it hard to read the small label at the bottom. Maybe the Chimney's can have different numbers 3 = 3D, 2 = 2D etc.
…
al surface, but this is not happening with the edge mesh list!
In fact when I want to create mesh faces (the side mesh faces to close the boundaries surfaces) I can see (and I have tested/x2 checked within GH), that the corrispondent top edge and bottom edge of a determinated face are not coincident.
How can I assign a consistent index list to the top and bottom mesh edge list?
How the edge topology is assigned?
I post here the code, FYI, even I do not think that can help to find the problem.
And 2 screenshot to show you the problem.
double thickness = new double(); if (!DA.GetData(0, ref thickness)) return; Mesh baseMesh = new Mesh(); if (!DA.GetData(1, ref baseMesh)) return; List<Plane> localCSPlanes = new List<Plane>(); if (!DA.GetDataList<Plane> (2, localCSPlanes)) return; List<Mesh> solidMesh = new List<Mesh>(); List<Point3d> meshFaceCenterPlus = new List<Point3d>(); List<Point3d> meshFaceCenterMinus = new List<Point3d>(); List<Plane> localCSPlanesPlus = new List<Plane>(); List<Plane> localCSPlanesMinus = new List<Plane>(); List<Line> edgeMeshPlusLine = new List<Line>(); List<Line> edgeMeshMinusLine = new List<Line>(); Mesh offsetPlus = baseMesh.Offset(0.5*thickness, false); Mesh offsetMinus = baseMesh.Offset(-0.5 * thickness, false); Mesh recMesh = new Mesh(); solidMesh.Add(offsetPlus); solidMesh.Add(offsetMinus); //This for-cycle creates a index-consistent list of plus-offset mesh face center points and local coordinate system mesh planes. int nFcsPl = offsetPlus.Faces.Count; int nEdg = offsetPlus.TopologyEdges.Count; for (int i = 0; i <= nFcsPl - 1; i++) { meshFaceCenterPlus.Add(new Point3d(offsetPlus.Faces.GetFaceCenter(i))); localCSPlanesPlus.Add(new Plane(offsetPlus.Faces.GetFaceCenter(i), localCSPlanes[i].XAxis, localCSPlanes[i].YAxis)); } //This for-cycle creates a index-consistent list of minus-offset mesh face center points and local coordinate system mesh planes. int nFcsMn = offsetMinus.Faces.Count; int nEdgMn = offsetMinus.TopologyEdges.Count; for (int i = 0; i <= nFcsMn - 1; i++) { meshFaceCenterMinus.Add(new Point3d(offsetMinus.Faces.GetFaceCenter(i))); localCSPlanesMinus.Add(new Plane(offsetMinus.Faces.GetFaceCenter(i), localCSPlanes[i].XAxis, localCSPlanes[i].YAxis)); } for (int i = 0; i <= nEdg - 1; i++) { Line lineRecPlus = offsetPlus.TopologyEdges.EdgeLine(i); edgeMeshPlusLine.Add(lineRecPlus); Point3d recPointA = lineRecPlus.From; recMesh.Vertices.Add(recPointA); Point3d recPointB = lineRecPlus.To; recMesh.Vertices.Add(recPointB); Line lineRecMinus = offsetMinus.TopologyEdges.EdgeLine(i); edgeMeshMinusLine.Add(lineRecMinus); Point3d recPointC = lineRecMinus.To; recMesh.Vertices.Add(recPointC); Point3d recPointD = lineRecMinus.From; recMesh.Vertices.Add(recPointD); recMesh.Faces.AddFace(0 + 4 * i, 1 + 4 * i, 2 + 4 * i, 3 + 4 * i);
NOTE: I know how to create a solid from a single mesh surface, but this is not what I want now, because I have to sort (for further purpose) the solid mesh in top, bottom and side faces.
Thanks a lot for your help!
cheers,
matteo…
iece could be easily cut using the "plan" curve, the wall need extra attention and manual work to prepare.
This script attempts to automate the preparation of lasercutting curves with some control:
1) Height: The parameter is set using the "Name" property of the Rhino "plan" curve object. Number of storeys (e.g. 5) is to be entered in that field and the script will read it after you press F5 (recompute) in grasshopper. If the block models are not multiples of standardised storey height, you could set "Storey height" in grasshopper to 1 and set exact height to individual "plan" curves in Rhino.
(Special mention: This part of script including reading "Name" property in Rhino and auto-correcting curve direction is attributed to Victor Leung's Laser Cutting Tool for Block Models)
2) Mode of wrapping: The wall could either be "sitting" on the bottom plate and being completely covered by the top plate, or wrapping outside both the bottom and top plate. In either case, material thickness is taken into consideration and the finished model will remain the same size.
3) Extra height option: In preparing flat roof models, one may like to add extra height for parapet wall to make the model more appealing.
4) Easy picking up: Each individual piece has some uncut part (red lines for engrave) to hold itself in place after cutting. There is no need to use masking tape to stick. Individual pieces could be taken out when you are ready to use.
There are also known issues to this script:
1) At internal corners, the adjacent wall will be longer (in wrapping outside mode) or shorter (in sitting inside mode). You have to manual cut at this point.
2) It could not work with only one input curve. (Although it may be a stupid bug,) A dummy rectangle nearby could be created to make it work.
Enjoy,
Sa
Lasercutting Tool for Block Models (Fold and Wrap) by Sa Ng is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Based on a work at http://www.grasshopper3d.com/forum/topics/laser-cutting-tool-for-block-models.
…
. 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
via MIDI controllers.
my idea is to link PureData to GH via UDP. why pure data? cause' i can relate data like GH to generate numeric relations (and link it to audio generation)
so far i got PD and Processing to talk, but i can't get to grasshopper.
i use this definitions to make pd and processing to talk http://ubaa.net/shared/processing/udp/ and this GHX to get the data to GH http://www.grasshopper3d.com/forum/attachment/download?id=2985220%3...
i got this data from this post but the GH definition doesn't work for me. i have tried LAN definitions and "the engine" as well but they both freeze, even if i send data thru processing or PD.
i have a lot of questions at this time
1.- why processing tells me that i am getting the data from diferent ports, while i'm using 6000?
2.- why in the UDP definition i get no data out, even if it should say something like "waiting fordata/port/etc.." that's defined in the C# capsule
3.- is there a direct way to get midi data (key and CC) to GH
i also tried to use firefly to get the data via COM port. i know you can do this trick in processing but i just don't know how.
well. if anyone could help me i would share the results here (since it's a magister, results shoud be very interesting)
UDP has allways been a unsolved issue on other posts. maybe we could work it out ;)
Thanks…
Added by jota aldunce at 8:43am on September 28, 2010