an almost planar tissue (your case) can cause a variety of issues up to the undo able state (metal parts/components grow in size as well for no reason). See forces estimated by FF below.
2. Therefor I strongly suggest to consider Plan B (a) mastermind a secondary "anchor" capability in order to achieve a far more stable system (b) use a mount design that can support this (and comply with the attractor concept of yours). Here's a variable mount custom system (mostly machined AND not cast) that is suitable for the scope (Rhino reads the stp file OK .... but makes a colossally big file - thus I attach here the original).
3. On first sight lot's of things in this system appear "odd". For instance: is it stable? Why these double cables are used? How far can be adjusted? (that's a classic case for feature driven parametric design - not doable with Rhino).
4. This concept (strut axis exported only) is tested in FORMFINDER and some other far more complex membrane apps that I use quite often (not RhinoMembrane). Here's is what FF tells us about:
Observe a different kind of "stress" when this is converted to radial type:
5. If you insert the stp file to the Rhino file provided (exactly as exported from FORMFINDER - no mods of mine of any kind) you'll see what goes where (and why). That way the usage of double cables is rather obvious (and a lot other things - for instance the way that the struts achieve "equilibrium", see the slots in the base mount plate.
6. If this approach is worth considering your definition requires some serious rethinking (far more simpler/manageable with the drawback that the real parts they are "static" they can adjust only as far this particular solution allows them to do - controlling them parametrically is clearly impossible with the current state of R/GH capabilities).`
All in all: this case works because the cables push the anchor points downwards and the struts push them upwards.
more in a while
…
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.…
nd then writes some data to a certain range of cells, but currently I am missing the small bit of code to save the file and then close that certain excel workbook. One other thing to note is that I'm writing into another excel file concurrently from another set of VB componenets, which must remain open, so I don't want to save & close that file. - Only the file which I'm writing data to from this VB component needs to be saved & closed. Any help would be appreciated.
Here is the current bit of code:
Rhino.Runtime.HostUtils.DisplayOleAlerts(False)If _write = True Then'Dim val As DoubleDim row As IntegerDim column As IntegerDim Pole As StringDim Angle As DoubleDim cellValue As StringDim rowstart As Integer
Dim xlApp As ObjectxlApp = System.Runtime.InteropServices.Marshal.GetActiveObject("Excel.Application")Dim wb As Object = xlApp.Workbooks.Open("W:\Bay Bridge Aiming\Knuckle Plate Aiming\Re-work_Field-Aim_20m.xlsx")Dim sheet As Object = wb.Worksheets("Factory-Aim")
rowstart = 0
Dorowstart += 1cellValue = sheet.cells(rowstart, 1).valueLoop Until cellValue = ""
row = rowstartcolumn = 1For Each Pole In Pole_IDsheet.Cells(row, column).value = Polerow = row + 1Next
row = rowstartcolumn = 2For Each Angle In KnucklePlt_Anglesheet.Cells(row, column).value = Anglerow = row + 1Next
End IfA = 0
Much thanks,
Joel…
Added by Joel DeBoef at 12:29pm on October 23, 2012
j), runs simulation in Contam and re-imports results back into Grasshopper for visualization and data processing. Contam (developed by NIST) is a multizone indoor air quality and ventilation analysis computer program. It can be used to determine infiltration, exfiltration, and room-to-room airflows in building systems driven by mechanical means, wind pressures acting on the exterior of the building, and buoyancy effects induced by the indoor and outdoor air temperature difference. You can read more about Contam at NIST website: https://www.nist.gov/services-resources/software/contam
Installation
In order to run Pigeon and and correctly re-import the results back into Grasshopper, you need to have installed the following:
1. Contam 3.2 on your C drive. You can downlaod Contam at: http://www.bfrl.nist.gov/IAQanalysis/CONTAM/download.htm
2. SimRead3 in your Contam folder. SimRead3 is a utility provided to enable you to create text files from SIM files. You can downlaod it at: http://www.bfrl.nist.gov/IAQanalysis/docs/simread32.zip. Please extract the content of the SimRead3 zip file into your Contam folder.
We would like to improve the Pigeon plugin, so please let the us know if you notice any mistake in the .prj input file, or if you have any other suggestion about the plugin's usability.
Disclaimer
The authors reserve the right to not be responsible for the performance and results of the plugin. The entire risk as to the quality and performance of the program is with you. Should the program prove defective, you assume the cost of all necessary servicing, repair or correction.
Credits
Pigeon plugin was developed by Rusne Sileryte and Antonio D'Aquilio as spin-off from a research project at TU Delft supervised by Michela Turrin and Eric van den Ham.…
ou mean by 'Activate Direct Rhino Modifying'. Perhaps you could expand?
I like the idea of mixing and matching script and 'direct' modeling. There seems to be a lot of potential platforms for this:
1. Implict History: Is there a way for GH to read the direct modifications (with History activated) and translate this as a component (or cluster of components?)? IH seems to record the UI events and the associated elements. GH would need to write as well as read the IH info, in order to preserve as much flexibility downstream as possible. You mentioned Houdini. H seems to record all 'implicit' or direct mods, done via the CAD mouse-based UI, in its network graph. Maybe, this should be captured in the IH cluster/component mentioned above.
2. RhinoParametrics: RP has done a lot of work to intercept and translate Rhino commands into its version of Implicit History. Seems to be centred on points, which makes sense as so much of the traditional 'dumb' way of inputing CAD info is based on mouse clicks on screen (points) predicated by commands, active locks, workplanes etc.
3. Gumball: Rubberduck's use of the new Gumball tool to capture 'direct' modeling inputs thru the Gumball points to a good source for capturing this kind or input, that is related to the 'macro recorder' approach taken by RP and IH.
4. The new Geom Cache component seems to be able to preserve a lot of info about the baked object. There may be even a way to read tagged info generated both GH baked with the "reference" object, and external to GH (by IH, the gumball or even third party apps like RP).
Would be interesting to know what kind of info is 'preserved'. Houdini seems to have a pretty consistent approach to geometric data, that seems to allow parallel NURBS/subD/mesh versions of the geometry. It also seems to have a coherent heirarchical approach to vertices/edges/loops/faces etc that allows the subelements to be arbitarily grouped for 'direct' modeling, and still be part of a procedural script.
I guess the polygon / mesh approach to geometry lends itself to this. If all the procedural commands/components all understand mesh geometry in either vertex, edge, face format, then combining direct and script modeling is doable in transparent way?
In your example above, the Geo Cache node 'flattens' the object to dumb geometry which is manipulated using Rhino, then used as a Reference object, in the next section of the graph. I guess there is nothing to stop the follow on components reading the precedenting graph for parameters, for additional intelligence?
Does GH 'get' or 'put' parameter data?
…
when you get external events that occur on a different thread, as might well be the case for hardware controls or sensor data.
Here's essentially what happens:
Something expires (part of) a Grasshopper document, and the NewSolution() method is called upon to rectify this. It starts by iterating over all the objects inside the document and whenever it encounters an object which has the 'expired' flag set to true, it will tell it to recompute itself. This object cannot recompute itself unless all the objects it depends on are also 'solved', so it might cause a shock-wave of recomputes across the entire document. Eventually though all the inputs are available and it recomputes itself and then hands control back to the document solver.
The document solver now continues on its quest to find more 'expired' objects. It might find some in which case the above story is repeated, or maybe there was only ever one expired object, or maybe the object we just found caused all other expires objects to solve themselves, leaving nothing to do for the document solver.
When the document solver has iterated over all the objects and determined that none of them are still 'expired', it will place a call to redraw the Grasshopper canvas and the Rhino viewports.
That is what happens during a proper, single-threaded solution. When there's two (or more) threads operating on the same document, all hell breaks loose:
Let's assume the document solver is halfway done with its job of resolving all expired objects. At this point an external event comes in on a different thread, which is handled immediately by some component. This component places a call to ExpireSolution(True), which sets the 'expired' flags of a bunch of components. Some of these components will already have been handled by the solver in the first thread, so even though the solver thinks all is fine and dandy, these components have in fact expired again. Other components might still be expired because the solver hasn't gotten to them yet. Worst case scenario, a component just finished solving itself on the first thread and the data inside of it is being harvested by a downstream component. While it's collecting this data the second thread wipes the data, causing a mismatch and probably a crash.
The Grasshopper core algorithms are not thread-safe and if you start calling methods from different threads, you will run into clashes.
What you need to do is 'invoke' the first thread from your second thread. That way the first thread is allowed to finish what it's doing before getting around to your request. Invoking is a very important concept when you're writing a multi-threaded app with a GUI and there's plenty of online resources explaining how it works. Here's two:
http://weblogs.asp.net/justin_rogers/pages/126345.aspx
http://www.yoda.arachsys.com/csharp/threads/winforms.shtml
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
Added by David Rutten at 4:04am on February 25, 2011
ake a network of lines (i.e. a graph) and make a Plankton Mesh, from which you can use Cytoskeleton to make a solid mesh (and then smooth it with Weaverbird).
Works with ngons (polygons with 3 or more sides). Other examples I found only worked with tris and quads.
Works on open or closed surfaces
While these examples start with a surface, you could start with a network of lines and make a patch surface
This is meant for 2D networks/surfaces. I haven't attempted filling a 3D volume. My guess is this wouldn't work as it would require a non-manifold mesh that Plankton wouldn't handle.
Note similar results could be achieved with the following:
TSplines
MeshDual (dual of a tri mesh, not as much freedom/control)
Working backwards, here is the GhPython script from Will Pearson that builds a Plankton Mesh from vertices and faces. The vertices are a list of 3D coordinates, the faces are a tree a lists, with each list containing the indices of vertices that form a closed loop. From Will, "Plankton only handles manifold meshes, i.e. meshes which have a front and a back. This orientation is determined by the "right-hand rule" i.e. if the vertices of a face are ordered counter-clockwise then the face normal will be out of the page/screen."
# V: list of Point3d # F: tree of int
import Grasshopper appdata = Grasshopper.Folders.DefaultAssemblyFolder
import clr clr.AddReferenceToFileAndPath(appdata + "Plankton.dll")
import Plankton
pmesh = Plankton.PlanktonMesh()
for pt in V: pmesh.Vertices.Add(pt.X, pt.Y, pt.Z)
for face in F.Branches: face = list(face)[:-1] pmesh.Faces.AddFace(face)
These vertices and faces are precisely the output from Starling. Starling takes in a list of Polylines which form the (properly oriented) face loops.
The polyline face loops can be generated...
Directly from Panels on a surface using LunchBox
Using any network of lines/curves on a surface (curves will need to be converted to polylines before Starling)
The latter was achieved using the Surface Split command, then converting the face edges (converted to curves) into polyline loops to represent faces.
…
). 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 …
eventually found out about genetic algorithms on which I found extensive researches, projects,... ! I looked into it and ended up on a few papers which I believe are the jumpstart for my master thesis.
"Galapagos; on the logic and limitations of generic solvers" by David RuttenArticle in Architectural Design 83(2) March 2013
"Black-box optimisation methods for architectural design" by Thomas Wortmann and Giacomo NanniciniConference Paper: CAADRIA 2016, At Melbourne, AU, Volume: 177-186
So I started looking into alternatives to genetic algorithms in architectural design.So far, I've ended up on :
Thomas Wortmann's work with the surrogate(or model) based optimization approach!You can check out the tool he developped for GH (Opossum):http://www.food4rhino.com/app/opossum-optimization-solver-surrogate-models
Judyta Cichocka's work, specially with the Swarm approachYou can check out the tool she developped for GH (Silvereye):http://www.food4rhino.com/app/silvereye-pso-based-solver
And that's it !!! I've been researching through article references (mainly on "researchgate") but I'm now stuck in a loop of references I already visited!That probably means the litterature on the subject is not (yet) extended but I might probably be missing something.The keywords make it difficult to search : "optimisation", "algorithms", "architecture", send me most of the time to computational engineering and deep mathematics papers I unfortunately do not have the background knowledge to comprehend ! So there it is ! If you have any clue of where (or how ! ) I should be looking, please tell me :)I know Mr Rutten is pretty active on the forum so hopefully... (fingers crossed :p) !Also if you have any good tips for getting into algorithms in general (you think could help), I'd be glad to hear(read) it ! A book, tutorials maybe ?!So, autors, architects, projects books, articles, conferences I should go to,specialized architecture offices/studios (I'm also looking for an internship so ...).If you know about a more appropriate forum please let me know !If you want to get deeper into this, you can contact me at :
e1635331@student.tuwien.ac.at
tdissaux@student.ulg.ac.be
My master thesis is due for may 2018 but I have a paper to write for January 2018 in order to be elligible for a PHD program afterwards.What I mean by that is that if you read this message in 6 month, I'll still be open to discussion !
I am right now an erasmus student at TUWien (Vienna) but my main university is The university of Liège in Belgium.I can handle French, English, Italian litterature and eventually Dutch if really you think it's worth it ! I have access to most online libraries via my university's portals so access shouldn't be an issue !I'm very excited to hear from you I wish you all a great day,Cheers,Thomas
…
can work in any node of a given hierarchy tree (loaded in your work session) by making the node "active". "Nodes" can be other things as well (like workplane, clip definitions etc).
Why to do that weird thing? Well, think any design being "flat" > meaning that all objects are placed in a single file (and in a single layer). Not that good > although the items are present you barely can handle them (because power is nothing without control, he he).
Let's go one step further: we can start classifying objects in "groups" (like a directories/files organization in any O/S). This means, in MCAD speak, creating assemblies (a void thing kinda like a directory) that contain components/entities (kinda like files).
Several steps further we end up with severely nested "arrangements" of entities (an assembly could be parent of something and child of something else).
For instance, it could be rather obvious the logical classification of a "geodetic" (so to speak) structure like this : a 40000m2 "hangar" defining some thematic park.
I mean : a void master that owns 4 equal void segment sets that own 4 "legs" that own various geodesic structural members + cables + membranes + you name it etc etc.
Each "leg" owns the concrete base (Shared) and a rather complex set of objects.
Notice that some tensile membrane "fixture" combos (see above)...act as perimeter light fixtures as well...meaning that the membrane tension plate may could be a child of a void "light" parent...or may could be a "stand alone" assembly etc etc.
These arrangements can be internal (belonging in, say, a x node within the current active file) or external (belonging in a y node within another file). If they deal with the same (topologically speaking) object they define clusters of Shared entities (or variations)- where only the view transformation matrix changes (in the simple scenario, he he). For instance the disk shown above is a Shared Assembly that owns the bolts, the plates, the tension member etc etc. Selective Instancing allows modifying some attributes without affecting the topology (i.e. the geometry).
The whole (terrible) mess is controlled by some tree like "dialog" (in Catia is "transparent") that is called Structure Browser. By controlled I mean (1) display/display mode with regard any tree member combo/selection set (assembly and/or component) in any View (2) clip state control (3) active status (for modifications/variations) (4) workplane control (5) drag and drop ownership control (6) ....
Now...what if I would chan…