taTree.
2. Since GH is acyclic by design we can't pick individually (without code, that is) our "picks" for the iceberg ... thus we need a global policy applied to ALL grid points at once.
3. This is what the next part does: it picks randomly some iceberg stuff and modifies their Z by a random value. If the Z is always "above" the grid or not it depends upon the domain of values to operate. Seed means "roll the bones again" (meaning another collection).
4. So we have the modified points Data Tree (that are steady - acting as the tips of the iceberg). Let's call them Anchors.
5. If we subtract set 4 from 1 we have the points prone to vary according some manipulation. Kangaroo does that manipulation (this is the best add-on that GH has to offer by 1M miles made by a very clever fella).
6. But if we instruct Kangaroo to do the job... he makes chaos since the points in 4 are not sufficient: we need perimeter steady points that act as Anchors as well. So we manage some logic to pick a variable set of perimeter points and we "merge" 4 and 6 and we have the final set of Anchors on hand - whilst all the rest are points willing to change.
7. Kangaroo is a physics engine meaning that the only thing that understands is ... er ... points and their relation (the "line" connecting them, that is). Kinda like a CPU that understands 0 and 1 and nothing else.
8. So we provide Kangaroo info about all the lines involved: how "stiff" they are and what is the expected/desired final length.
9. By double clicking the Kangaroo component ... the "simulation" starts running (in some kind of "loops") and goes towards an "equilibrium" where all our desires are satisfied - or the solution's entropy is the minimum possible (well up to some level, he he). Kangaroo displays a small control dialog that allows you to halt the process or reset it (meaning: start again).
10. If the instructions are "good"/"proper" the "loops" (iterations) are relatively few: if K does 1M "loops" ... this means that your instructions are silly or not well thought.
After stopping Kangaroo ... we have (hopefully) a "well" distorted collection of points (and their equivalent mesh) to proceed further via components usually found in the WB add-on
PS: If all the above sound Greek to you ... it's because I'm Greek, he he.
Moral: Get the gist of Kangaroo ASAP - worth spending some time I recon. If you do that and you need examples (other than the ones available at download time) ... well I have more than 300 (from simple to ultra paranoid).…
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).
…
on excel (leaving 0,0 cell blank and also making sure there are no commas in the names ) Also let's call the names "ID"
2 - For the weight, use numbers ranging from 1 - 10 where 10 is the highest dependancy.
3 - Save the file as a Unicode CSV from excel
4 - Create another file on excel that has the attributes of your spaces, with the names of your spaces under the header ID (let's start with a simple "area" and "SNo" attribute but you could add more features for sorting and manipulating your data)
5 - Open Gephi and further open your matrix CSV file
5 - Import it as "," (comma delimited file) and make sure you check "matrix" for the data type
6 - Ensure the import is nondirectional as well (or Gephi adds silly arrows)
7 - Not gonna go into the gephi bit too much but select a force atlas layout and set the force to something high 1000 or 10000 depending on the size of the data and the attraction to a 1000th of that 1 or 10. Go to the data lab and import your excel with the attributes and append to your existing datasheet.
8 - Set the node attributes to use the area for the node size and color scheme to SNo
9 - Play around with all the layout options and finally go to your preview. Once you're happy with it, export it to a GDF graph file.
the GDF now has the coordinates of the circles and the diameters. as well as the edge connections.
I've written a very amateur script that converts this to GH geometry (below)
Hope this helps someone out, I'm still figuring out the gephi streaming API but I've only started with python about a month ago so might take a while to get there.
You can use the second half of the GDF files to also create dependency chord diagrams online as shown in the third image.
https://flourish.studio/2018/07/25/how-to-make-a-chord-diagram/
Cheers,
Sanjay
…
the river Plate is an unexplored opportunity. The grid that configures the city’s urban tissue remains oblivious to its context, imposing a constant order. Its relationship with the river is one of mutual exclusion; as soon as the grid reaches the river it stops, but never modifies its nature. There is one happy exception to this condition – the northern riverside area of Buenos Aires called ‘Tigre’, which responds to the topography of the natural delta. In this workshop, projects will embrace the boundary between river and city as a means of managing alternative metropolitan ecosystems. By challenging the traditional relationship between architectural, urban and natural forces, students will propose new territorial organisations that develop both floating and rooted structures that are responsive to the nature of the delta. In this research workshop students have the opportunity to develop a range of computational techniques in order to explore alternative design opportunities. Week 1 Organised in teams, students will work with the articulation of the grid and the river. The goal is to produce several iterations analysing the potential transformation of the grid as it reaches the riverbank. This analysis will form the basis of an urban design proposal that establishes a new relationship between the city and the river. Design tutors, including Victor Orive, Arturo Revilla and professionals from the A A and other institutions, will provide digital tutorials and lectures on their own urban design research and projects. Week 2 During this phase we will address how such conditions affect discrete objects and/or a field of objects. The goal is to design a pavilion and study how a gradual change in field conditions will affect its size, porosity and orientation. This will unfold new opportunities to redefine the relationship between form and function.
Applications
The deadline for applications is 2 July 2012. All participants travelling from abroad are responsible for securing any visa required. After payment of fees, the AA can provide a letter confirming participation in the workshop. A portfolio or CV is not required, only the online application form and payment.
Fees
The AA Visiting School requires a fee of £695 per participant, which includes a £50 Visiting Membership. If you are already a member, the total fee will be reduced automatically by £50 by the online payment system. Fees are non refundable. Fees do not include flights. Accommodation during the workshop is not provided, but advice on accommodation options can be given. Students need to bring their own laptops, digital equipment and model making tools. Please ensure this equipment is covered by your own insurance as the AA takes no responsibility for items lost or stolen at the workshop.
Eligibility The workshop is open to architecture and design students and professionals worldwide.…
frontare il tema della modellazione parametrica con Grasshopper. Questa plug-in di Rhino consente di progettare, confrontandosi con un contesto evolutivo, attraverso la comprensione e l'utilizzo di parametri e componenti che influenzano la rappresentazione e la rendono dinamica componendo algoritmi. Nel corso verranno introdotte le nozioni base di Grasshopper approfondendo le metodologie della progettazione parametrica e le tecniche di modellazione algoritmica per la generazione di forme complesse.Le informazioni teoriche saranno fornite in maniera accelerata ma organica e contestuale agli argomenti elencati. Per massimizzare i risultati, le lezioni saranno accompagnate da piccole esercitazioni pratiche.Argomenti trattati:- Introduzione alla progettazione parametrica: teoria, esempi, casi studio- Grasshopper: concetti base, logica algoritmica, interfaccia grafica- Nozioni fondamentali: componenti, connessioni, data flow- Funzioni matematiche e logiche, serie, gestione dei dati- Analisi e definizione di curve e superfici- Definizione di griglie e pattern complessi- Trasformazioni geometriche, paneling- Attrattori, image sampler- Data tree: gestione di dati complessiStrutturaIl corso ha una durata di 16 ore programmate nell'arco di 2 giornate con i seguenti orari: i giorni 28/07 e 29/07 dalle 10,00 alle 19,00 con pausa pranzo di un'ora.DestinatariIl corso è rivolto a tutti coloro che hanno buone conoscenze di Rhinoceros e vogliono affrontare i nuovi metodi di progettazione in maniera consapevole attraverso il linguaggio visual scripting proposto dal software Grasshopper.PrerequisitiPer affrontare il corso è richiesta una conoscenza di base del software Rhino attraverso esperienze teoriche e pratiche. I partecipanti dovranno venire muniti di proprio laptop e con software Rhinoceros 5 o Rhinocero 4 perfettamente funzionanti.AttestatoAlla fine del corso verrà rilasciata l’attestato di partecipazione ad un corso qualificato McNeel valido per l’ottenimento di crediti formativi universitari.LuogoLe lezioni si terranno presso lo studio il Pedone in Via Muggia 33, 00195 ROMA…
rids Surface divisions Panel creation in Rhino Panel morphing and aggregation Panel placement via attractors and colors Panel smoothing with Weaverbird Parametric panel modules TIME 3pm – GMT, London 4pm – Paris, Brussels, Rome, Vienna, Budapest, Bratislava, Warsaw 7pm – Dubai, Abu Dhabi, Baku 6:30pm – Tehran 6pm – Baghdad, Moscow, St Petersburg 5pm – Istanbul, Athens, Helsinki, Cairo, Johannesburg 1pm – Rio de Janeiro, São Paulo, Montevideo 12pm – Buenos Aires, Santiago 10am – Toronto, New York City, Bogota, Lima 9am – Mexico City 7am – Los Angeles ADVANCED SESSIONS (live) The Advanced sessions put the essential knowledge into practical use. The advanced sessions explain specific design strategies, lead you through complex Grasshopper® definitions, show tips and tricks, put plug-ins into use and show you how to connect Grasshopper® to external software and devices. MICHAEL PRYOR Designer, working in the architecture field for four years now on a variety of major built and in construction projects in NYC and China. Co-partner to 3D-Dreaming: Architecture from a digital point of view. Daily user of grasshopper: both in work and exploration, as well as a constant contributor to the grasshopper help forums. Tutor to a variety of digital design and parametric workshops hosted by the Architecture Association with [AY]A Studio, Rese arch, and 3D Dreaming. Creator of the grasshopper tutorial blog [FORMul[a]RCH]. Currently in process of writing his first grasshopper plug in. WEBINARS The rese arch Grasshopper® sessions are unique for their thorough explanation of all the features, which creates a sound foundation for your further individual development or direct use in the practice. The webinars are divided into four groups: Essential, Advanced, Iterative and Architectural. If you are a Rhinoceros 3D or Grasshopper® newcomer, you are advised to take all the Essential sessions before proceeding to the next level. If none of the proposed topics suit your needs or if you require special treatment, you can request a custom-tailored 1on1 session. All sessions are held entirely in English. The webinars are series of on-line live courses for people all over the world. The tutor broadcasts the screen of his computer along with his voice to the connected spectators who can ask questions and comment in real time. This makes webinars similar to live workshops and superior to tutorials.…
Added by Jan Pernecky at 9:39am on January 8, 2015
erona, nei giorni 01,02 e 03 dicembre 2016.
Il comfort visivo e la gestione dell’illuminazione naturale in relazione al risparmio energetico diventano sempre più rilevanti per una progettazione innovativa degli edifici. Ad esempio, il nuovo protocollo LEED 4 riconosce crediti per le simulazioni di daylighting e conferma l’importanza degli aspetti progettuali per “collegare gli occupanti con lo spazio esterno, rinforzare i ritmi circadiani, ridurre i consumi di energia elettrica per l’illuminazione artificiale con l’introduzione della luce naturale negli spazi”. Senza strumenti software per la simulazione della luce non è possibile ottenere risultati di qualità. Radiance è un software validato, utilizzato sia a livello di ricerca che dai progettisti ed è tra i più accurati per la simulazione professionale della luce naturale e artificiale. Non ha limiti di complessità geometrica ed è adatto a essere integrato in altri software di calcolo e interfacce grafiche. Queste ultime facilitano le procedure di programmazione. Le principali e più versatili saranno oggetto del corso (DIVA4Rhino e Ladybug+ Honeybee, plug-in per Grasshopper e Rhinoceros 3D).
Il corso è rivolto a progettisti e ricercatori che vogliano acquisire strumenti pratici per la simulazione con Radiance al fine di mettere a punto e verificare le soluzioni più adatte alle proprie esigenze. Sono previste lezioni di teoria e pratica con esempi ed esercitazioni volte a coprire in modo dimostrativo ed interattivo i concetti trattati.
Le domande di iscrizione devono essere presentate entro il 16 novembre 2016.
La brochure con i contenuti del corso e tutte le informazioni sono disponibili su questo link
Il corso è sponsorizzato da Glas Müller.…
. BIM and Parametric.
Posts and files over at Design By Many:
http://www.designbymany.com/content/model-pattern-american-cement-building
I am equally comfortable on both of these platforms, and built the same parameters into each model. My modeling experience was very similar to that of Santiago. The Revit model took 4 hours to build, while the GH deff. took 16 hours to build. Time invested is certainly not the only metric to be compared; however, it is a good demonstration of the immediacy with which modifications can be made to the component system if parameter adjustment is not satisfactory.
With credit to Andrew Kudless for his process work on Manifold, I have adapted a similar workflow tracing diagram to the two models:
My general observation is that both tool sets approach the same problem, namely providing a structured relationship between components and wholes, but from opposing directions. BIM excels at compartmentalizing individual components, while parametric modelers like GH excell at global system-wide manipulations.
In the case of the American Cement Building, modeling the cast component seems to have fit in the box of 'the whole being reducible to its parts' the best. Although i anticipated Revit having more trouble with the surface generation, I found it to be more flexible on all accounts. Building up the component in a Pattern Based Curtain System family, the direct interaction with the rig (specifying control point work planes, and offsets) allowed the network of interactions to be accessible and editable throughout the build process. This family was then applied to a curtain panel grid which itself could be flexed in proportion, and cell count.
With the GH build I originally had the intention of utilizing data trees for parallel component construction so that changes to the base grid would affect offset normals and the like. However, after i had spent three hours constructing one parametric rail curve, I was unable to continue keeping track of the parallel data structure, and reverted to building a singular component. While GH certainly has the capacity to handle this task, I have found personally that the user does not.…
component I just used different components and GH tools to do the same - and this become part of my short paper submission for SimAUD 2016). My solution compares the height of the same points of different solar envelope and then chose the lowest one. I read about the improvement you are working on and it is good but I think it is not yet what I need (or how the solar envelope tool could be more complete).
What I need is a solar envelope that would guarantee on different facades with different orientations (the example I sent you) a certain amount of direct sunlight, say 4h per day in a given period for example all the month of June at 60°N. So to guarantee the south facing facade I should chose the vectors from 10 to 14. But these are not ok for all the other facades because in this timeframe the East and West facing facades get only 2 hours and the North get 0 hours.
So the fist step would be have the possibility to chose different sun vectors for different facades. For the example I did (the 4 hours in June at 60°N) the south facing facade would need from 10 to 14, the East facing for example from 8 to 12, the West facing facade from 12 to 16 and the North facing facade from 6 to 8 and from 18 to 20.
If I would chose a single longer time frame that could get all these hours, from 8 to 20 then the resulting solar envelope would result probably smaller than the sum of the four solar envelopes.
But this is not complete yet. I mean the use of different sun vectors on different facades. The reason is that for example when I chose the sun vectors from 8 to 12 for the four hours on the East facing facade how do I know that the sun hit on the facade in that time frame or maybe it is obstructed by surrounding buildings? Since the sun at 60°N (where I live) in June rise at around 3.15 then maybe for that specific facade the sun hit from 4 to 8 and not from 8 to 12.
I did an extreme case talking about 60°N and that maybe the sun hit on a facade at 4 instead than 12, but it is just to make understand the logic. My suggestion for a more advanced solar envelope it should be integrated with the Sunlight Hours tool of ladybug. So the input should not be the sun vectors because I don't know when the sun hit on the facade but the input should be just the desired number of hours and the possibility to specify different number of hours for each facade. Then this last component that sum different solar envelope (I didn't use it yet but I understood what it does) should be integrated yes so the result would be one single solar envelope more likely using the lowest points (the highest I don't understand what for).
Let me know what you think!
…
u can still find some wonky behaviour in GH related to datatrees. My experience is that new users quite quickly get the hang of it once they learn that a tree is in fact not a tree but in the first place set of lists, where the path shows how the pieces of data used to be grouped.
Branch Count checking A component has multiple tree inputs, but has different amount of branches, each having branch count > 2. (While I understand the logic of combining multiple trees, I've not once encounted once that combining a component with e.g. an input of 2 branches and an input of 4 branches to give any kind of sensible output.
Desired behaviour: If a component has branches (each being > 2 path count), the component should throw a warning. ("Strict branches behaviour?). For example: take an offset component, with 6 branches of curves and 5 branches of offsets. It is extremely likely that this is the result of an error earlier in the definition. This works however without a problem - the last branch is repeated again, and it's later on quite hard to discover something went wrong.
Checking branch Count The most important numeric is the amount of branches, and the amount of items in the tree. It's desired that the hovers show the amount of data and the amount of branches.
Desired behaviour
Trees with paths of different rank Trees that contain {0;0} and {0} and {0;0;1} is usually a sign of trouble of not well merged trees, faulty C# components, or just nasty coding habits.
Trim as undo graft instead of flatten Having the trim in the context menu would provide an easy way to undo a graft. Right now the easiest way for many people is to flatten it, and then start all over again - while just getting rid of the last index keeps the underlying history and makes it easier to write reuseable pieces of code when you prepend datatrees to it.
Component to get branch by index, not by path Would be great. Suppose you have a grid of points, grouped by row. It would help to show: "look, this is in the first path, it's called {0;0;1}, it's got 10 points, these points are the first row".
Analogue to using list item to show what is the first point, second point, and so on.
Semantic path names (maybe far fetched) But what if we can add a short name of each method that was executed to the path list, so it can show:
{Slider 0; Series 0; Point 0}{Slider 0; Series 0; Point 1}
{Slider 0; Series 0; Point 2}
{Slider 0; Series 0; Point 3}
{Slider 0; Series 1; Point 0}
{Slider 0; Series 1; Point 1}
{Slider 0; Series 1; Point 2}
{Slider 0; Series 1; Point 3}
Make the input/data matching inside components explicit Can we make it even more obvious that a component is not a black box that's executed once, but in fact an iteration machine that tries to make sense of the inputs that's fed to this box?
Show data combination. How data input A relates to data input B and data input C, is currently very implict and is just plain hard to learn., and required the ability to be able to relate the output back to the input. If we can textually or even graphically show what data matching occured inside a component, it would greatly help the understanding (and debugging) of "what's going on here in this component"
A verbose explanation of the data matching in component A
Iteration one: - Geometry: We take the data item from Branch 0, Position 0: (Point 0,0,0) - Motion: We take the data item from Branch 0, Position 0: (Vector 0,0,0)
Iteration two:
- Geometry: We take the data item from Branch 0, Position 0: (Point 0,0,0)
- Motion: We take the data item from Branch 0, Position 1: (Vector 10,0,0)
Iteration three:
- Geometry: We take the data item from Branch 0, Position 0: (Point 0,0,0)
- Motion: We take the data item from Branch 0, Position 1: (Vector 20,0,0)
etc.
A verbose explanation of the data matching in component B
Iteration one: - Geometry: We take the data item from Branch 0, Position 0: (Point 0,0,0) - Motion: We take the data item from Branch 0, Position 0: (Vector 0,0,0)
..
Iteration seven:
- Geometry: We take the data item from Branch 0, Position 0: (Point 0,0,0)
- Motion: We take the data item from Branch 7, Position 0: (Vector 0,70,0)
..
Iteration 27:
- Geometry: We take the data item from Branch 0, Position 7: (Point 80,0,0)
- Motion: We take the data item from Branch 2, Position 0: (Vector 0,20,0)
…