s to load from file (from 0 to 1)
So this post is about masks.
Rhino Point Clouds can store information such as : location of a point, it's color and normal vector. It is common to store intensity values, but it is not supported in Rhino.
Mask characters :
x y z - location
u v w - normal
r g b - color
a - intensity
Let's say that your file is formatted such as :
10.000 ; 12.000 ; 20.053 ; 0.243
which means it stores location and intensity values.
A proper mask will inform Load Cloud component how to read those values
x;y;z;a
The first non-alphabetic character in the mask is automatically interpreted as the separator.
Same masks work with Save Cloud component. Note that it has D input which when set to True will make it surround all the values in double-quotes.
"10.000" ; "12.000" ; "20.053" ; "0.243"
Cloud Load doesn't care about those double-quotes, it just ignores them and proceeds to read the values without them.…
ood Samaritan) said: well ... since the Ducati won't start (not my fault officer) help that girl.
Good news: Almost ready, well for a pair of curves ... but the rest are bureaucracy than any(?) intelligence(?). Took me 27 minutes, 23 seconds and 45,78 milliseconds using the famous cut and paste method of mine - US patent pending (from other C# stuff, that is).
I hear you: but the planes don't rotate. Well, that's exactly "almost" is used: the rotation logic IS NOT that simple (can you guess the reason?).
How to use it (up to that point - FULL detail Louvers used, he he):
(a) Load the Rhino file first. It doesn't display anything but the Block Manager can tell you a different story.
(b) Load the definition (it doesn't look that impressive at least as regards the graphics, he he) AND read all the comments.
(c) Go there and enable the second script (turn false to true, DO NOT turn false the second boolean flag because the simplified Louver is not yet imported).
(d) Prior changing the geometry via the first C#, disable the script (or keep it active if your computer is fast). But ... if you change the widthOfPanel value ... you'll need CATIA for that I'm afraid (create on the fly the parametric Louver assembly in full detail, in REAL-TIME).
I hear you: where are the wooden things? Well ... that's kid's stuff my dear just extruding a BrepFace both sides (V2 does this).
I hear you: are you saying that you'll make ALL the curves with C# (control their shape individually PER pair) and not just place the louvers into the existing curves provided? Yes that is what V3 does (it's ready but some minor things remain).
I hear you: and what V4 does then? Well ... have faith, he he
All that provided that ... that |$@%@$ Ducati could start (what's wrong with this thing? that's the 1M question).
best, The Troll…
o I can apply your color gradient code (not shown but in GH file, off screen) after the Z sort:170316_SpheresStandardizer_2017Mar16b.gh
The fact that sphere 'Volume' is required a second time, after 'Pull' to wires, reminds me of a similar issue we dealt with last week: http://www.grasshopper3d.com/forum/topics/trimming-points-pulled-fr...
Seems to me that 'Pull Point' has a serious defect that requires extraordinary effort and/or kludgy code to remedy. If you don't graft the curves, 'Pull' returns each point pulled to it's nearest curve - exactly what you want, except without knowing which curve puled it?
In this code (above), you are using 'Pull D (Distance)', 'Smaller' with an arbitrary value as 'B' and 'Cull' to associate the closest curve with each point. In the other thread, I ended up creating brep cylinders around the curves to get the correct result. Ridiculous!!
I've spent a lot of time trying and utterly failing to find a truly proper solution. Is there one? (see "AHA!!!!" below!)
Searching the forum, I quickly found a couple old posts referring to the same problem:
pull point (bug?) May 27, 2009http://www.grasshopper3d.com/forum/topics/pull-point-bug
Small request April 18, 2013http://www.grasshopper3d.com/forum/topics/small-request
=========================
AHA!!!! I had given up and was about to post the above when I finally solved it. Created a cluster called 'PullT' that does the job, sorting by 'D (Distance)'. Here's the cluster:
And here's how it's used: 170316_SpheresStandardizer_2017Mar16c.gh
Notice that 'PullT' emits a cull pattern ('Pc') that can be used on related data to structure it into the same tree pattern - 'Volume (V)' in this case, so it's only used once. Could do the same with the original mesh spheres if there was reason to do so.
I've tested it on last week's code in the other thread and it seems to work fine; will post it there shortly.…
t defined from the discussion of radiation exchange between urban surfaces and the sky in urban heat island research (See Oke's literature list below). It will be affected by the proportion of sky visible from a given calculation point on a surface (vertical or horizontal) as a result of the obstruction of urban geometry, but it is not entirely associated with the solid angle subtended by the visible sky patch/patches.
So, I think using "geometry way" to approximate Sky View Factor is not correct. Sky View Factor calculation shall be based on the first principle defining the concept: radiation exchange between urban surface and sky hemisphere:
(image extracted from Johnson, G. T., & Watson, 1984)
Therefore, I always refer to the following "theoretical" Sky View Factors calculated at the centre of an infinitely long street canyon with different Height-to-width ratios in Oke's original paper (1981) as the ultimate benchmark to validate different methods to calculate SVF:
So, I agree with Compagnon (2004) on the method he used to calculate SVF: a simple radiation (or illuminance) simulation using a uniform sky.
The following images are the results of the workflow I built in the procedural modeling software Houdini (using its python library) according to this principle by calling Radiance to do the simulation and calculation, and the SVF values calculated for different canyon H/W ratios (shown at the bottom of each image) are very close to the values shown in Oke's paper.
H/W=0.25, SVF=0.895
H/W=1, SVF=0.447
H/W=2, SVF=0.246
It seems that the Sky View Factor calculated from the viewAnalysis component in Ladybug is not aligned with Oke's result for a given H/W ration: (GH file attached)
According to the definition shown in this component, I assume the value calculated is the percentage of visible sky which is a geometric calculation (shooting evenly distributed rays from sensor point to the sky and calculate the ratio of rays not blocked by urban geometry?), i.e solid angle subtended by visible sky patches, and it is not aligned with the original radiation exchange definition of Sky View Factor.
I'd suggest to call this geometrically calculated ratio of visible sky "Sky Exposure Factor" which is "true" to its definition and way of calculation (see the paper on Sky Exposure Factor below) so as to avoid confusion with "The Sky View Factor based on radiation exchange" as discussed in urban climate literature.
Appreciate your comments and advice!
References:
SVF: definition based on first principle
Oke, T. R. (1981). Canyon geometry and the nocturnal urban heat island: comparison of scale model and field observations. Journal of Climatology, 1(3), 237-254.
Oke, T. R. (1987). Boundary layer climates (2nd ed.). London ; New York: Methuen.
Johnson, G. T., & Watson, I. D. (1984). The Determination of View-Factors in Urban Canyons. Journal of American Meteorological Society, 23, 329-335.
Watson, I. D., & Johnson, G. T. (1987). Graphical estimation of sky view-factors in urban environments. INTERNATIONAL JOURNAL OF CLIMATOLOGY, 7(2), 193-197. doi: 10.1002/joc.3370070210
Papers on SVF calculation:
Brown, M. J., Grimmond, S., & Ratti, C. (2001). Comparison of Methodologies for Computing Sky View Factor in Urban Environments. Los Alamos, New Mexico, USA: Los Alamos National Laboratory.
SVF calculation based on first principle:
Compagnon, R. (2004). Solar and daylight availability in the urban fabric. Energy and Buildings, 36(4), 321-328.
paper on Sky Exposure Factor:
Zhang, J., Heng, C. K., Malone-Lee, L. C., Hii, D. J. C., Janssen, P., Leung, K. S., & Tan, B. K. (2012). Evaluating environmental implications of density: A comparative case study on the relationship between density, urban block typology and sky exposure. Automation in Construction, 22, 90-101. doi: 10.1016/j.autcon.2011.06.011
…
you may know, PCS (from now I will call polar coordinate system with PCS, and cartesian one with CCS) describes point position with 2 values (like x and y in CCS) which are r and theta(r,theta). r is for distance from PCS center, theta is angular dimension which is in 0 to 360 or 0 to 2*pi domain.
To hark back to David's guide line - here it is replaced with guide circle.
Why to sort points like this ? As usual, one image tells more...
Here is logic behind all this stuff :
Find an average point of all given points*
Search for furthest point from an average point*
Create a circle with center at average point and radius = distance from average point to furthest point*
*Steps 1-3 can be replaced with custom hand-made circle, I decided to automate it that way.
For each point find closest point on circle - this will be used for finding theta value
For each point find distance to average point - this is r value
To overcome problem with same theta (t) values (like same x values in CCS), instead of multiplying by 1000, we will use a new create set component. This component creates set of integers, each one representing one unique input value. So if points A, B, C, D, E are (r,theta) :
A (1, 30)
B (2, 30)
C (3, 30)
D (1, 45)
E (1, 60)
Then create set will output list of integers = 0,0,0,1,2 (same theta for A, B, C other theta for D and E). Now its getting really easy - remap r values to domain 0 to 0.5 (or any less then 1), and add integers from create set component to remapped r values.
7. So what we have now is list of floating point numbers : A=0, B=0.25, C=0.5, D=1, E=2
Profit of remapping is that r values will never affect integers representing theta values - and all the information is stored in one floating point number ! By sorting these values we will obtain proper order of points - to complete this, we need to sort points parallel with values.
What's really cool about polar sorting - there could be any amount of points, but polyline connecting all of them will never self-intersect. Probably there is some relation with 2d convex hull.…
.. then you put (or drill) rather "canonical" patterns that formulate the inner/outer skin (or both).
2. The above approach hits 3 walls: (a) very slow response (Rhino is a surface modeller) (b) booleans/fillets potential issues (Rhino is a surface modeller) (c) a potential aesthetic antithesis between the liberty of the "whole" VS the "strict" rules of the "details".
3. Since you opt to work with Rhino It could be worth considering playing his own game: deforming surfaces that is ... by working against control points or via the Morph methods. Then join them and get the decorative thingy as "solid".
Images below are from a C# that actually gets the control points of Surfaces in Lists and "deforms" them according a gazillion of options (a) via any "on-the-fly" defined pattern (Take or skip this control point: shift branches/items that is) (b) using any number of attractors in any push/pull mode (c) using chaotic vector values (d) using ... well too many ways to list them here.
Imagine what the Alien cuppa def does (modifies "diagonally" control points) ... multiplied by 1000.…
n en el diseño y fabricación digital de formas complejas y euclidianas.
Tomando como plataforma Grasshopper con RHINO, se explora y optimiza el diseño y fabricación de topologías complejas bajo los entornos de "Grasshopper", "RhinoNest" y "RhinoCAM" así como la parte de renderizado tipo high-end con Brazil.
D-O-F De 8:00 AM a 12:00 PM y de 1:00 PM a 5:00 PM
Contenidos:
1. Modelado Avanzado y sus Tecnicas. Aplanado y Desarrollo de Superficies.Anidado y distribución Nesting.
2. Introducción al Diseño Paramétrico.Definiciones Avanzadas de Grasshopper,posibilidades y limitaciones. Ajustes de escala para impresión y corte.
3. Introducción a la Manufactura en CNC - RhinoCAM 2.0.
4. Guía Paso a Paso para la realización de un Renderizado usando Brazil 2.0. Presentación DIGITAL de proyectos.
Docentes:
Andrés González - CEO McNeel Miami
Ovidio Cardona - Especialista en RhinoCAM y Zebra
Juan David Moreno - Especialista en Rhino y Brazil
Inversión:
$650 000 (Incluye licencia Educativa y Certificación de McNeel)
$550 000 ( Incluye Certificación de McNeel)
Informes:
Bits LTDA Tel: 412 30 15
Laboratorio de Imagen Facultad de Arquitectura Tel: 430 94 32…
ices" which i found very intresting , I have your thesis and it will be the base of my futur work, I'm a graduate student in bioclimatic architecture and environment in Constantine -Algeria , I will prepare a thesis for my master degree in the theme of " parametric design, the dynamic envelope and intelligent façade" and really I need your help, if you can send me your work in grasshopper in(.ghx) mentioned in the "APPENDIX D SOLAR CONTROL VISUAL DEFINITION "(GRASSHOPPER),because i can't download it from the web site , I'm juste a beginner in grasshopper so I want to master the link between all the elements ,for this reason I would like to master your exemple in grasshopper as beginning , and I'll work with daylighting + thermal comfort in my thesis which is the continuity of your work, can you share your exemple with me please ? and why did you choose a 200 btu/ft² as a limits for direct normal irradiance , what is the formula ? I'm waiting for your response because it's so importante for my work , and i promise you , i will put your name in my references . thank you karla. the files needed are: the part which contains: 1-Solar Irradiance / TMY3 Excel Data (in grasshopper) 2-:Surface Geometry Analysis / Grid Pattern Selection (in grasshopper) 3-: Solar Profile Angles (in grasshopper)
4- Shading Geometry Profile Angles (in grasshopper) …
nputs to run (please refer to the image)
Currently, here is how I set the data:
protected override void RegisterInputParams(GH_Component.GH_InputParamManager pManager) { //Create default size
double defaultBaySize = 0; pManager.AddTextParameter("LotLib", "Llib", "Lot Library", GH_ParamAccess.tree); pManager.AddCurveParameter("BoundaryCrv", "BC", "Boundary Input", GH_ParamAccess.list); pManager.AddIntegerParameter("Direction", "D", "Direction of gridLines", GH_ParamAccess.item, 0); pManager.AddNumberParameter("CCsize", "S", "Distance from column to column", GH_ParamAccess.item, defaultBaySize); pManager.AddCurveParameter("GridCrv", "GC", "Take in curves input for gridlines", GH_ParamAccess.list);
}
protected override void SolveInstance(IGH_DataAccess DA) {/* Setup */ GH_Structure<GH_String> LotLib = new GH_Structure<GH_String>(); DA.GetDataTree(0, out LotLib); List<Curve> BoundaryCrv = new List<Curve>(); if(!DA.GetDataList(1, BoundaryCrv)) { return; } int Direction = 0; DA.GetData(2, ref Direction); double CCsize = 0; DA.GetData(3, ref CCsize);
List<Curve> GridCrvs = new List<Curve>(); DA.GetDataList(4, GridCrvs); if (!DA.GetDataList(4, GridCrvs)) { return; }}
Is there a way can set data in the way if the component does not receive inputs for BoundaryCrv but only GridCrvs, the BoundaryCrv List will empty.
Thank you very much …