sion app (Modo, Z Brush etc) in order to get "as equal" as possible mesh faces.
For instance ... see a W depth truss (tri mesh > meaning that the "out" grid is hexagons) out from a Kangaroo "inflated" mesh:
2. A space frame is NOT a collection of abstract lines ... meaning that clash members detection (via trigonometry and NOT by checking boolean intersections) is far more important than the "concept" it self. If "live" alterations are required for addressing local clash issues ... well ... that's 100% impossible with native components.
See a typical clash detection capability:
3. A truss without proper connectivity Data Trees means nothing in real-life (vertices to edges, vertex to vertex, edges to vertices).
4. Each "standard" truss member (say: sleeves, cones and the likes) should be an instance definition placed in space according appropriate orienting planes. That way you may be able to handle thousands of components that in real-life participate in any truss of a certain size.
All the above are far easier to do with code (V4 is impossible with components).…
le] demo):
1. A transformation Matrix is a 4*4 collection of 16 values that "deform" 3d things according the values in the cells. The orthodox way is to deploy "cells" left to right and top to bottom. Rhino does the opposite (why?) hence we need the transpose method.
2. Since "translate" and "perspective" are "symmetrical" the transpose boolean toggle (within the C#) "flips" rows with columns ... so we get perspective or move.
3. When in perspective "mode" the vanishing points are computed internally within a min/max limit (per X/Y/Z axis) thus avoiding the usual havoc with "extreme" perspective angles (very common "glitz" in pretty much every CAD app - CATIA excluded). Vanishing points (and limits) are oriented with respect the pos/neg value of a given control slider.
Note: slider values are percentages between min/max (mode: perspective) and/or actual values*100 (mode: move).
4.In order to start mastering the whole thing: don't change anything: just play with these 4 sliders selected:
5. The 123 sardine cans challenge: even with DeusExMachine = true (see inside C#: that one redirects the transformation per BrepFace and then joins the breps instead of applying it on a brep basis)... odd things (and/or invalid breps) occur ... thus what is required in order to make things working 100% ??.
he, he
best, Lord of Darkness …
wing2D
Imports System.Reflection
Imports System.Collections
Imports System.Collections.Generic
Imports Microsoft.VisualBasic
Imports RMA.OpenNURBS
Imports RMA.Rhino
Imports Grasshopper.Kernel.Types
Class Grasshopper_Custom_Script
#Region "members"
Private app As MRhinoApp
Private doc As MRhinoDoc
Public P, C As System.Object
#End Region
Sub RunScript(ByVal x_range As OnInterval, ByVal y_range As OnInterval, ByVal attractors As List(Of On3dPoint), ByVal factor As Double)
'''
If (attractors.Count = 0) Then Return
If (factor <= 0.0) Then Return
Dim Rnd As New Random(123456)
Dim failed As Int32 = 0
Dim Pts As New List(Of On3dPoint)
Dim Rad As New List(Of Double)
Dim Crc As New List(Of OnCircle)
Do
If (failed > 100) Then Exit Do
Dim x As Double = x_range.ParameterAt(Rnd.NextDouble())
Dim y As Double = y_range.ParameterAt(Rnd.NextDouble())
Dim pt As New On3dPoint(x, y, 0.0)
If (IsTaken(pt, Pts, Rad)) Then
failed += 1
Continue Do
End If
failed = 0
Dim d As Double
Dim i As Int32 = NearestAttractor(pt, attractors, d)
Dim radius As Double = factor * (Math.Pow(d, 0.8) + 0.5)
Pts.Add(pt)
Rad.Add(radius)
Crc.Add(New OnCircle(pt, radius))
Loop
P = Pts
C = Crc
'''
End Sub
#Region "Additional methods and Type declarations"
#End Region
End Class
Hope you can see an error :)…
nda like a T-Rex).
BTW: The real thing:
(a) accepts different top-bottom nurbs controlled by a variety of ways including attractors etc etc.This is the reason that several components are not "minimized" (this def is a "bit" garrulous I confess, he he).
(b) has clash detection capabilities in order to avoid embarrassing moments when talking with these Germans.
(c) has images of nice looking girls (for inspiration purposes).
(d) has images of MERO cases.
(e) uses about 50% less components.
(f) exports (EXCEL) drilling axis for those Germans.
...
(z) can manage cladding support systems/corrugated sheets/etc without them... this def is 100% academic (see the unfortunate Roissy 2F and a myriad similar cases). Given the opportunity use Foamglas (1 "s") and avoid a myriad of issues.
BTW: this is a classic case about why we desperately need a decent block management at bake time: assume that you want to export something to your favorite AEC app (AECOSim, Revit, Allplan blah blah). By what means can you do it? (other than exporting a myriad of "individual/stand alone" balls/cones/tubes etc etc).
best, Peter
…
n fact) according a vast variety of "modes" PLUS the required clash detection (ALWAYS via trigonometry). In plain English: outline any collection of Breps and "apply" a truss that is topologically sound (planarization in case of quads etc is an added constrain). PLUS outline/solve what comes "next" after that truss (like the planar glazing "add-on" brackets of yours [ the ones that need redesign, he he], or some roofing/facade skin system [secondary supports, corrugated sheet metal, insulation, final cladding, dogs and cats])
2. Imaging doing this in real life (nothing to do with "abstract" formations of "lines" or "shapes" or whatever). This means primarily adopting a BIM umbrella: in plain English AECOSim, Revit or Allplan (I'm a Bentley man so I use AECOSim + Generative Components). This also means using "in-parallel" a top MCAD app for 1:1 details, FEA/FIM and the vast paraphernalia required for real-life studies destined for real-life projects (made with real-life money by real-life people). My choice: CATIA/Siemens NX.
3. What to send to Microstation (if not using Generative Components, that is) and/or CATIA? In what "state"? To do what exactly? For instance even if you could design this feature driven tensile membrane anchor custom node in Rhino (you can't) it could be 100% useless in CATIA:
4. Imaging masterminding ways to send them nested instance definitions of ... er ... a coordinate system (all what you need). In plain English: since is utterly pointless to send them nested blocks that can't been parametrically controlled (variations/modifications/PLM management/BOM/specs etc etc)... send them simply the "instructions" to place coordinate systems of components that ARE parametrically designed within Microstation and/or CATIA (classic feature driven design approach blah blah). So GH solves topology et all (working on data imported via, say, Excel sheets related with sizes of components etc etc) and sends to Microstation simply this (a myriad of "this" actually):
I do hope that the gist of the "method" (the ONLY way to invite GH to the party) is clear.
best, Peter…
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 …
ave the bytes available, they also need to be adjacent. All 4 frikkin trillion of them (assuming you need a million 1000x1000 pixel tiles). That's just not going to happen.
It could be that Photoshop has very clever memory management that allows it to store image data in non-consecutive chunks, but .NET does not allow this.
In fact this can be a real problem with much smaller images as well. In 32-bit Windows you're allowed 2GB of memory per application (sometimes 3). If Rhino+Grasshopper are already using up 1.5GB it's not like you can fit in an extra 0.5GB image before running into problems. Memory is almost never used in a consecutive fashion.
Rhino uses a clever memory manager (not the default Windows one) that results in less memory fragmentation and Grasshopper uses the .NET memory allocator and garbage collector which is capable of defragmenting memory usage. But even with these two optimizations memory fragmentation will occur (and the longer Rhino runs the worse it will get) making it less and less likely that you'll be able to find large consecutive areas of free memory.
The Grasshopper hi-res image exporter creates image tiles of 1000x1000 pixels and saves these files immediately. So it never requires more than 4MB while running. Once it's done making the images, it will start a different application that will stitch these images together. That's what the GrasshopperImageStitcher.exe in your screenshot is. Since this is a new app, it has 2GB of absolutely pristine memory to play with so it's a lot longer before it runs into problems. And when it does run into memory problems it won't bring down Rhino with it.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…