ocessed once Grasshopper is done with whatever it's doing now.
3) Grasshopper tells the Slider object that the mouse moved and the slider works out the new value as implied by the new cursor position.
4) The slider then expires itself and its dependencies ([VB Step 1] in this case, but there can be any number of dependent objects).
5) When [VB Step 1] is expired by the slider, it will in turn expire its dependencies (VB Step 2), and so on, recursively until all indirect dependencies of the slider have been expired.
6) When the expiration shockwave has subsided, runtime control is returned to the slider object, which tells the parent document that stuff has changed and that a new solution is much sought after.
7) The Document class then iterates over all its objects (they are stored in View order, not from left to right), solving each one in turn. (Assuming the object needs solving, but since in your example ALL objects will be expired by a slider change, I shall assume that here).
8) It's hard to tell which object will get triggered first. You'd have to superimpose them in order to see which one is visually the bottom-most object, but let's assume for purposes of completeness that it's the [VB Step 1] object which is solved first.
9) [VB Step 1] is triggered by the document, which causes it to collect all the input data.
10) The input parameter [x] is asked to collect all its data, which in turn will trigger the Slider to solve itself (it got expired in step 4 remember?). This is not a tricky operation, it merely copies the slider value into the slider data structure and shouts "DONE!".
11) [x] then collects the number, stores it into its own data structure and returns priority to the [VB Step 1] object.
12) [VB Step 1] now has sufficient data to get started, so it will trigger the script inside of it. When the script completes, the component is all ready and it will tell the parent document it can move on to the next object (the iteration loop from step 7).
13) Let us assume that the slider object is next on the list, but since it has already been solved (it was solved because [VB Step 1] needed the value) it can be skipped right away, which leaves us with the last object in the document which is still unsolved.
14) [VB Step 2] will be triggered by the document in very much the same way as [VB Step 1] was triggered in step 9. It will also start by collecting all input data.
15) Since all the input data for [VB Step 2] is either defined locally or provided by an object which has already been solved, this process is now swift and simple.
16) Upon collecting all data and running the user script, the component will surrender priority and the document becomes active again.
17) The document triggers a redraw of the Grasshopper Canvas and the Rhino viewports and then surrenders priority again and so on and so forth all the way up the hierarchy until Grasshopper becomes idle again.
[end boring]
Pretty involved for a small 3-component setup, but there you have it.
To answer somewhat more directly your questions:
- The order in which objects are solved is the same as the order in which they are drawn. This is only the case at present, this behaviour may change in the future.
- Adding a delay will not solve anything, since the execution of all components is serial, not parallel. Adding a delay simply means putting everything on hold for N milliseconds.
- [VB Step 1] MUST be solved prior to [VB Step 2] because otherwise there'd be no data to travel from [GO] to [Activate]. The only tricky part here is that sometimes [VB Step 1] will be solved as part of the process of [VB Step 2], while at other times it may be solved purely on its own merits. This should not make a difference to you as it does not affect the order in which your scripts are called.
--
The Man from Scene 24…
Added by David Rutten at 4:43pm on December 10, 2009
dellatore nurbs, Rhinoceros. Attraverso una serie di esercizi che si svolgeranno durante il corso, si spiegheranno i temi fondamentali che stanno alla base della modellazione generativa e del design parametrico.
Il corso è rivolto a chi ha già una familiarità minima con la modellazione attraverso Rhinoceros e vuole ampliare le proprie competenze verso il campo della modellazione parametrica e generativa, e si terrà da martedì 22.10.2016 a giovedì 24.10.2016 – dalle 10:00 alle 17:00.
Potete scaricare qui il PROGRAMMA DEL CORSO.
Il calendario dei corsi è consultabile qui.
VEGA Parco Scientifico TecnologicoVia della Libertà 12 – VeneziaEdificio Porta dell’Innovazione – Piano Terra
Per iscriversi al corso è necessario essere registrati al sito.Per tesserarvi al Fablab Venezia, diventare maker, usufruire dei vantaggi, clicca qui.
Le iscrizioni chiuderanno giovedì 17.11.2016.
Il corso ha un costo di 270,00 euro + iva (329.40) per i tesserati e convenzionati,per i non tesserati il costo sarà di 330,00 + iva (402.60) euro.
Vuoi risparmiare? Iscriviti entro tre settimane dalla data di inizio corso, usufruirai automaticamente dell’offerta “early bird” ovvero uno sconto del 20% sul costo a te dedicato.
Per iscriversi:
http://www.fablabvenezia.org/parametric-design-with-grasshopper/…
ne diverse digital design methodologies and the use of different tools such as Autodesk Maya, Rhinoceros and Grasshopper.
Building up technical skills will provide the attendees with a solid platform from which to start rethinking and exploring innovative architectural ideas in collaboration with the team and the tutors.
URBAN FIELDS
Phase I
In the first part of the workshop attendees will be looking at field conditions and how to generate and design such fields that can help structure a possible urban condition in Florence.
We will be exploring dynamic systems, geometric systems and network theories to generate and design an abstract field condi- tion that extends the urban experience of the city onto the vertical dimensions of towers. Simple operations that would span variations from an initial state will give rise to high level of com- plexity.
The goal of this exercise is to create a rich and diversified intel- ligible urban space that can be later on subjected to local inter- ventions and zooming in to locally enhance each design.
AGENT - BODIES POLYMORPHISM
Phase II
The second part of the workshop will build upon first phase; par- ticipants will select one archetype (high rise tower) as a study model for further development.
Besides engaging with multi agent algorithms design strategies, attendees will address strategic utilisation of structurally and environmentally generated morphologies to design coherent and highly differentiated tower exo-skeletons.
Tutors will introduce agent-bodies polymorphism in order to explore the generation of structural aware and capable geom- etries through agent based formation of non-linear hierarchies and emergent patterns. These agent-bodies will operate in a complex spatial manner to form structure, partitions or enclo- sure and will operate across scales, creating a poly-scalar level of detail.
Attendees will speculate how autonomous systems can cre- ate new structures and intelligent distribution of structural elements, about new collaborative strategies of construction and the performativity they will evoke (performance, effects, responsiveness, interaction).
Fees
Early registration (before 1st June)
Students 390€ - Professionals 440€
Late registration (after 1st June)
Students 490€ - Professionals 540€
More info and Applications
https://www.ax-om.com/edu/polymorphism/
…
ed four workshops, each featuring a partnership of a creator of hardware technology and a software developer. The outcomes of the four workshops will form a single structure.
Workshops:
1. Facade panels with RoboFold & Kangaroo/Lobster
2. Cantilever CNC wooden lattice with Archiwaste & SMART Form by BuroHappold
3. Corian freeform surfaces by Cutting Edge & Evolute Tools
4. Milled foam and cast concrete with Cordek & Galapagos/David Rutten
Book on the Shape To Fabrication website or via SimplyRhino on 0208 498 9900. Tickets are limited to 10 per workshop at £500+VAT (professional) and £400+VAT (student).…
Added by Gregory Epps at 5:15am on September 29, 2011
izing strength/spring stiffness and even the unit of your 3DM file setting.
sometimes the same pattern that can be planarized in one file would stop working once something else is modified. and sometimes the force can't even planarize one single cell.
I think you can find some idea from the following post:
http://www.grasshopper3d.com/forum/topics/planar-polygons-by-using-kangaroo
'Reply by Daniel Piker on December 17, 2013 at 10:25am
Making the faces of a polygonal mesh planar is not always possible without dramatically changing the shape of either the polygons or the surface.
When the target surface has only positive Gaussian curvature it makes things somewhat easier, but the surface in your file also has regions of negative Gaussian curvature.
To approximate a surface of negative curvature with a discrete mesh, we need the angles around some of the vertices to sum to less than 360°. This is impossible to do in a mesh with 3 hexagons around each vertex without making some of these hexagons non-convex.
There are a few possible approaches, but I would say how to automatically cover an arbitrary surface with nicely shaped planar hexagons is still an unsolved problem.'
I have uploaded some test files for you to look at. …
make sure I add this information to groundTerrain_ inputs in the next few days.
So if you are using "Gismo Terrain Generator" component (former "Ladybug Terrain Generator 2" component), only the following types are allowed for groundTerrain_ input: type_ = 2 (surface with rectangular edges)
type_ = 3 (surface with circular edges)If you are using "Ladybug Terrain Generator" component, then only the:
type_ = 1 (surface with rectangular edges)
is allowed.
As for terrain not being colored when it is created as a surface, you can analyse it additionally with "Terrain Analysis" component for Elevation analysis type. It can even be colored for rendering afterwards by using the "OSM Render Mesh" component. Check the attached file below.Have in mind that in urban areas "Ladybug Terrain Generator" component produces much more precise terrain than "Gismo Terrain Generator" component. On the other hand, the latter component can generate much larger terrain areas (up to 10 000 sq km2, at least in theory).
The reason why component might still work even though a terrain mesh has been added to the groundTerrain_ input is probably because once groundTerrain_ input fails to convert a mesh to a brep, this results in it being equal to None. Component then considers as if groundTerrain_ input is empty and runs as if nothing has been added to it (the buildings are laid down on a flat plane with 0,0,0 as the plane origin).
Thank you once again for all the testing you are doing!!! It really makes Gismo a better plugin!!…
Added by djordje to Gismo at 12:45pm on February 8, 2017
s the "Surface Populating" definition: I manage to populate my geometry over the surface, but after I bake it, I have to delete the boxes that define my components limits as well! Is there any way of populating and baking only the chosen component, without having to delete the boxes afterwards?
Secondly:
Basically: I am trying to cover a surface with two types of components [ an open one and a closed one] , which will be proliferated over my tubular surface according to the main sunlight direction.
1. I introduce the surface component.
2. I use "Divide Interval2" in order to have division into U and V.
3. i generate the target boxes [ "surfaceBox"] .
4. I use "Isotrim" ( same intervals) and "BRepArea" to find centroid of each area.
5. My "Curve" component introduces sun angle, with its "End Points".
6. I use "Vector 2Pt" to specify sun-light direction.
7. I want to measure the angle between sun-light and the surface normals, at the position of each component; after generating the centre points, I need the normals of each centre point to get the surface's points' UV, and "Evaluate" the srf at points.
8."Angle" and "Vector" components: I use them in order to evaluate the angle between the sun direction and the srf.
9. I convert this angle to degree by using a "Function" [ to see if the angle is bigger from the max.angle or not...]
10. Function "x,y" gives me boolean data.
11. Data become "Dispatch"ed...
12. Two "Morph" components , each one linked to one part of the "Dispatch" data, generate "closed" and "open" components over the srf.
The result should have been different types of components, based on the surface's curvature, diraction and sun-light direction...
I do not understand where the mistake is in this definition...
Thx in advance1
Spyros K.…
t to work. I was getting an error message on the OSMshapes components. I searched the forums and followed these steps:Close your Grasshopper and Rhino.2) Restart your PC3) When it boots up again, in your Start menu's search box type: "UAC". Click on it, and a new User Account Control Settings window will open. Set the bar on the left to "Never notify".4) Completely turn off your Antivirus.5) Check once again if your access control to the C:\MapWinGIS_installation_folder\gdal-data\osmconf.ini file is still set to the values you previously reported in this post.6) Right-click on "Rhino 5" icon and then choose: "Run as administrator".7) When Rhino boots up, run Grasshopper, and open the newest create_3dbuildings_trees_streets.gh file from here.This got the script to work and eliminated all of the error messages. The thing is... The omsconfig file's settings switch back after a some time passes, so I have to keep going back to change them. Also If I don't right click on rhino and choose "open as an adminstrator" the script won't work. I'll get those same error messages when I open Rhino normally. I'm also not super comfortable turning off my antivirus software during the time that I am working.Are there more permanant solutions that I can employ without going through these steps every time?
Thanks,
Robert…