d the workshop PDF from this link: http://goo.gl/bcvRNH Download event poster from this link: http://goo.gl/Q0KWCM Brief: Cairo is filled with barriers controlling people movements, suppressing them as well as detaining green and public spaces to the extent that most people have been taking these spaces for granted. Public spaces have been for a while the periphery of our daily life. We will explore in this workshop how we can manipulate and alter people’s perception and direct their attention to how these spaces are integral for city life. This exploration will be backed up by intensive technical tutorials introducing computational design and fabrication techniques and tools mainly Rhino, Grasshopper, Geco and Ecotect. Not only will this be the typical technical workshop, but rather you will also have the chance to be guided step by step on how these tools are used through out different design stages in a real world scenario. Design prototypes will be produced through 3D printing, the main workshop output will be a fabricated one to one functional model for one of the designs using our new in-house CNC machine. Tutors (check the PDF for bio): Olga Kovrikova, MArch DIA Alexandr Kalachev, MArch DIA Karim Soliman, MArch DIA Islam Ibrahim, MArch DIA Sherif Tarabishy, B.Sc. AAST Application: Application deadline 1 September 2013 ** For students (undergrad / Master), teachers and PhD proof of status is required (university ID with a date or a certificate of enrollment) to apply for the students package. Packages (choose one of the following in the application form): 1. Standard registration Course fee is 4250 EGP For Students 3500 EGP 2. Early bird registration discounted fee For Professionals 3750 EGP For Students 3000 EGP ** Early bird offer ends on 14 August 2013 3. Group registrations discounted fee (5 or more) For Students 20% off - You will have to fill out an application form here: http://goo.gl/0QxAga - You will need to submit your CV and Short Portfolio (max. 10 MB) to info@morph-d.com, email subject: “Morphing Norms Application” (we will decide if you are eligible for an early bird discount or not based on the date of your email submission) - We will confirm receiving emails from all applicants. Successful applicants will be contacted 5 days after each deadline (early bird/final) and will have to confirm participation within 3 days, if they fail to do so, places will be given to others on the waiting list. - A maximum of 30 applicants will be selected.
…
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…
basis" problem ... all of a sudden - quite recently - a girl posted the MITESIGF (Most Important Thread Even Seen In Grasshopper Forums). She doesn't even realized that: she's novice:
http://www.grasshopper3d.com/forum/topics/array-1
4. Why this MITESIGF is MITESIGF? For 2 reasons:
4.a: Wooden pairs (Beams) Profile Curves (belonging in some tree) MUST allow individual control on a per "item basis" (OK, that's obvious) - see Images posted in the thread. No attractor (or any other "global" policy) can cut the mustard here (to tell you the truth this happens in 99% of pure engineering cases, but they appear very rarely in GH Forums - if at all, mind). If the profile curves are defined with 5 points (or 9 for the double thing) we need "on-the-fly" control over this Array (like the radii in your Sphere Manipulator) :
4.b: Critical Bottom-to-Top issues arise: Create a "global" topology (call it "parent") - the beams - and then place real-life "components" (call them "childs") that affect (most probably) the "parent". OK, that's impossible to do with GH/Rhino (peace of cake with CATIA/Microstation) but you can "approximate" things up to a point. Alternatively: you can "trigger" some interest from GH/Rhino developers if they have any AEC market(s) in mind.
Topic 4.a requires the master-to-slave slider thingy (iterate over branches (index slider:master) > reset the 5 values (value slider:slave) > modify them on the fly > save > increase/decrease branch > ...).
Other than that my definitions are far more challenging than this simple case ... but ... anyway ... long is the path (and hilly).
more soon.
best, The Troll
…
, but without modifying the lists order:
suposing i have a structure list
(Paths = 75)
{0} (N = 51)
{2} (N = 51)
{3} (N = 51)
{4} (N = 51) ...............
I`m trying to apply to that list of values the statement:
if x>y then x=0
if x<y then x=x/z
but i need the list structure to keep exactly the same.
I`d be very thankful for any ideas on how to approach this problem.
Many thanks,
Roberto
…
that aren't relevant anymore or if there are any I missed please let me know. Maybe we can get a list like this in a better place as well.
Thank you.
Right Mouse - When wiring, plugs wire into multiple inputs.Shift+Click - Pick component aggregate.Shift+Clicking - Place component aggregate.Alt+Left - Click Split canvas tool.Ctrl+Q - Preview toggle.Ctrl+E - Enable toggle.Ctrl+Left - Navigate upstream.Ctrl+Right - Navigate downstream.Ctrl+M - Mesh Edge display toggle.Ctrl+1 - No previewCtrl+2 - Wireframe preview.Ctrl+3 - ShadedCtrl+Alt+Shift+Click - Save image of canvas.Ctrl+Alt and Shift+Ctrl+Alt - Highlights components on the canvas and component palette.Ctrl+Shift - Rewire component input/output.Double Click - Find/SearchAlt+Drag - Copy component on canvas.Ctrl+Tab - Document cycling.Ctrl+Shift+P - PreferencesCtrl+N - New fileCtrl+O - Open fileCtrl+S - Save file.Ctrl+Shift+S - Save as.Ctrl+Alt+S - Save backup.Ctrl+W - Close open document.Ctrl+Z - Undo copy.Ctrl+Y - RedoCtrl+X - CutCtrl+C - CopyCtrl+P - PasteCtrl+Alt+V - Paste in placeCtrl+Shift+V - Paste in centerCtrl+A - Select allCtrl+D - DeselectCtrl+Shift+I - Invert SelectionCtrl+Shift+A - Grow SelectionCtrl+Shift+Left Arrow - Grow UpstreamCtrl+Shift+Right Arrow - Grow DownstreamCtrl+Left Arrow - Shift upstreamCtrl+Right Arrow - Shift downstreamCtrl+G - Group selectionF3 - FindF4 - CreateF5 - RecomputeCtrl+B - Send to backCtrl+F - Bring to frontCtrl+Shift+B - Move backwardsCtrl+Shift+F - Move forwardsInsert - Bake selectedCtrl+Q - Toggle previewCtrl+E - Toggle enabled selected
…
ported to Rhino and "set" in Grasshopper, i trim both surfaces from their rectangular bases so that when sDivide is used it creates and distributes the same number of points on each surface.But heres the problems: a) if i use the "trimmed" surfaces with SrfGrid it errors warning: "A point in the grid is null. fitting operation aborted".I'd learned this was caused by "nulls" replacing position Data Items when the rectangular grid(surface base) was trimmed away. So i used Clean Tree which worked removing all nulls, then Shift Paths\Flip Matrix to create line-endpoint pairs for Polyline\Evaluate Curve. I Flattened the last Flip Matrix placing all data items in one source for SrfGrid, like in the working Untrim\CopyTrim definition.This time,.b) SrfGrid errored with: "The UCount value is not valid for this amount of points",.So, i substituted a 356 value, numeric Slider in the Addition B param., and tested its range until a valid UCount was found. Then SrfGrid fitted a surface thru the points, BUT,d) those SrfGrid surfaces are extremely deformed even thought the points preceding it from Evaluate Curve are accurate,SEE: def: "3b-RGH_SurfaceBlend.gh",AND,.a2) if i use Untrim with CopyTrim then SrfGrid works, but since the Jokers limbs WILL be in different surface positions then the blends between the Arm (for example) will rise from its relative FLAT position on the untrimmed Source surface to the Arm on the Target surface, rather than morphing from the Corresponding Arm position on the Source surface,. ..see def.: "4-RGH_SurfaceBlend.gh"So please let me know,..1) how to produce accurate surfaces from SrfGrid in def.: "3b-RGH_SurfaceBlend.gh",. ..(NOTE: BOTH these def's contain 2 indentical, "internalized" surfaces, but if def. 3b can be made to work it will also work with Dis-similar surfaces)2) which component to use or how else to determine the correct UCount value for a specified amount of points(ie:155), re: SrfGrid error: "The UCount value is not valid for this amount of points",.3) how else to force SrfGrid to work with Trimmed surfaces?, AND,..4) how to force intersurface, point-blend correspondence lines: Polylines(PLine) to be connected between correctly! correponding positions (Limbs) on the surfaces?,
Really! appreciate all help, definitions and kind generosity common to this knowledgable membership,
Cheers!,
Jeff…
s my code, so I decided to write a new simple component refreshing all time at 300 ms interval and the problem came up again. The code provoking the display exceptions and images with the erros are listed below.
----------------------------------------------------------------------------------------------
using System;using System.Drawing;using Grasshopper.Kernel;using FirstComp.Properties;using System.Timers;namespace FirstComp{ public class FirstCompGH : GH_Component { private Timer myTimer = new Timer(300); //3 veces por segundo private Random rand = new Random(DateTime.Now.Millisecond); public FirstCompGH() : base("Nombre", "Abreviado", "Descripcion", "Categoría", "SubCat") { myTimer.Elapsed += new ElapsedEventHandler(MainLoop); myTimer.Start(); } protected override void RegisterInputParams(GH_Component.GH_InputParamManager pManager) { pManager.Register_DoubleParam("Op A", "A", "Primer parámetro de la operación",0.0); pManager.Register_DoubleParam("Op B", "B", "Segundo parámetro de la operación",0.0); } protected override void RegisterOutputParams(GH_Component.GH_OutputParamManager pManager) { pManager.Register_DoubleParam("Suma", "S", "Resultado de la suma"); pManager.Register_DoubleParam("Resta", "R", "Resultado de la resta"); pManager.Register_DoubleParam("Mult", "M", "Resultado de la multiplicación"); pManager.Register_DoubleParam("Div", "D", "Resultado de la división"); } protected override void SolveInstance(IGH_DataAccess DA) { // Variables para contener los datos de entrada // Le podemos asignar algunos valores iniciales. double opA = double.NaN, opB = double.NaN; // El objeto DA recupera los datos de la entrada. // Si no hay datos de entrada abortamos. if (!DA.GetData(0, ref opA)) { return; } if (!DA.GetData(1, ref opB)) { return; } opA += rand.Next(1,10); opB += rand.Next(1,10); // Ahora realizamos las operaciones matemáticas DA.SetData(0, (opA + opB)); DA.SetData(1, (opA - opB)); DA.SetData(2, (opA * opB)); if (opB != 0) //Rhino.RhinoMath.ZeroTolerance DA.SetData(3, (opA/opB)); else { AddRuntimeMessage(GH_RuntimeMessageLevel.Error, "Error de división por cero"); return; } } public override Guid ComponentGuid { get { return new Guid("44BEA3FE-7CB8-42fe-AEC9-BE5F6EE424E8");} } protected void MainLoop(object source, ElapsedEventArgs e) { this.ExpireSolution(true); } protected override Bitmap Internal_Icon_24x24 { get { return Resources.icono; } } }}
-------------------------------------------------------------------------------------------------
Images showing errors.
I can't figure out what is causing these errors.
Best Regards
Ernesto
…
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
…
reaky thing consisting from triangulated "modules" (i.e an assembly out of this, this and that) where the exterior edges ARE always under tension (= SS 304/316 cables OR nylon) and the interior ones MAY be under compression ( = steel, aluminum, wood, carbon) OR ... some of them ...may be under tension. Bastardized T trusses deviate a bit from theory ... but who cares? (not me anyway). T trusses have many variants (but as the greatest ever said: Less is More).
2. Large scale T for AEC is the art of pointless since it costs around the GNP of Nigeria. Here's some indicative components from a module of a multi adjustable TX system costing (the module) ~ the price of my Panigale (Google that):
The above is mailed to a friend who has MIT (yes, that MIT: the top dog) on sight ... therefor he needs some appropriate "credentials", he he.
3. The distance that separates the above with the demo TDT node provided is around 666.666 miles - but we don't care: we are after Art not some testimony to vanity.
4. On purpose I've used a smallish ring to give you a clear indication upon the constrain numero uno in truss design: CLASH matters.
5. You'll need:
(a) A decision related with the tensioners (classic Norseman + SS cables or nylon machined thingies?).
(b) A machinist who can do elementary stuff (like the adapters) and can weld this to that (the "ring" for instance). His abilities must be 1 in a scale of 100. If the fella has a computer (not a CRAY) and he knows what 3dPDF is (hmm) ... well ... use that way to communicate with him PRIOR designing anything: He must agree on the parts BEFORE the whole is attempted (as a design in GH or in some other app).
(c) A carpenter with a wood lathe for the obvious. BTW: BEFORE doing any TDT attempt > ask the carpenter about the available wood strut sizes. Against popular belief DO NOT varnish the wood (use exterior alkyd/oil stains from some top maker like the notorious US company PPG).
http://www.ppgpaints.com/products/paints-stains-data-sheets
(d) Good quality cigars (and espresso) plus some classic music (ZZTop, PFloyd, Cure, Stones, U2 etc etc) during the assembly.
(e) Faith to the Dark Side (see my avatar).
May the Force (the dark option) be with you.…
st variety of papers (mostly related with LIDAR airborne sampled clouds) ... but ... hmm ... no code (other than some "abstract" algos that may (or may not) work). Reason? A very hot cake that one these days: from reverse engineering to DARPA founded future defense systems and up to cruse missiles pattern recognition algos.
The solution (obviously doable only via code) is the so called flat hard clustering ... were points are sampled into clusters based on the coPlanarity "rule". For large amounts recursive octTrees (an oriented box divided in 8 "partitions") subdivisions are used and then pts are processed in parallel (and then clusters are re-evaluated in order to "absorb" other clusters with same plane A,B,C,D vars etc etc).
See what's happening in a very carefully made test point collection:
3.7 ms and the "ideal" clustering (7 search loops VS the max 42M theoretical threshold):
Depending on the pts "preparation" ... a considerable more time/search loops is required ... and ... well ... also "valid" clusters (4 points and up) made:
So "ideally" speaking in your case:
1. Mesh faces center points (or alternatively: mesh vertices) are sampled into a pts collection .
2. Hard flat coPlanarity clustering is attempted yielding pts/planes in equivalent DataTrees.
3. Planar Breps are made with respect the planes (like the black things captured above) and sampled, say, into a breps List.
4. The method Brep[] solids = Brep.CreateSolid(breps); is used for attempting to create your desired "engulfing" brep. This method is very slow mind (other waaaay faster approaches also available).
…