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 …
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 …
hat aren’t completely there. BIM will have to continue to evolve some more if their supporters want to get to realize the promise that still is. I can’t say much about PLM, but I would say that both BIM and PLM should be considered in future developments of GH and Rhino. David has said several times that some GH limitations regarding geometry and data structures (central to interoperability) are actually Rhino limitations. So, I wouldn’t put so much pressure on David for this, or at least I would distribute the pressure also on the core Rhino development team.
Talking about Rhino vs. GH geometry, there is one (1) wish I have: support for extrusion geometry. GH already inputs extrusion elements from Rhino, but they are converted to breps. Is not a bad thing per se. The problem is when you need to bake several breps that make the Rhino file to weight several hundred MB. When these breps are actually prismatic, extrusion-like solids, is a shame that they aren’t stored as Rhino V5’s extrusion geometry in a file of just a couple of MB (I overcame this once with an inelegant RhinoScript that wasn’t good for other people). This was one of RhinoBIM’s main arguments. We can develop a structural model made of I-beams in GH using the Extrude components. We should be able to bake them as extrusions. That would also work for urban models with thousands of prismatic massing buildings (e.g. extruded footprints). Even GH’s boxes are baked as breps! Baking boxes as extrusions could be practical for voxelated or Minecraft-like models.
(2) Collaborative network support. Maybe with worksession handling, or something that aloud project team members to work on a single definition or in external references or something alike. I know there is another Rhino limitation on this, but maybe clusters are already going in that direction?
And maybe on the plug-ins domain:
(3) Remote control panel that could be really “remote”, like from other computer or device. There is an old Android App for that, but is not only a matter of updating. I mean, it would be great to control a slider with the accelerometer of an Android phone, but to have that on an iPhone will require another development team. If GH could support networks, a remote counterpart of a RCP plug-in could be developed as a cross-platform web app. I don’t know if you can access accelerometer functionality through HTML5 already, but for now, asking a client (or an spectator or any stakeholder for that matter) to control your sliders from gestures of his/her own phone would be awesome (maybe Firefly will fill that hole?).
(4) GIS support. GH already imports .shp files. Meerkat can even access the database, but what about writing to shapefiles or generating our own with databases processed/generated in GH?
(5) SketchUp support. Not only starchitects and corporations are using GH in the AEC. There are a lot of small firms, freelancers and students interested. Most of them use SketchUp for 3D modeling (not CATIA, neither Revit). Yes, you can import/export .skp from Rhino, but if GH could support nested block at bake time (also mentioned by others), it could write .skp files with complex relations of blocks (that are called components in SketchUp) and nested groups, going beyond what Rhino can export.
(6) Read/Write other formats. There are some challenges with proprietary formats that are not completely supported by Rhino, but they’re still a lot of open formats that are relevant to the fields of GH users, like stl and ply for 3D-printing. It could be nice to write mesh colors to a ply for 3D-printing a colored prototype based on GH colors. There are others, like IGES, STEP, COLLADA, etc. and 2D, like svg, odg and pdf. Some of them could offer special formatting options like custom data that the format supports but nobody uses just because is impractical to access this from direct modeling environments (but not from visual programming).
--Ernesto…
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.…
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?
…
rtitions." (http://wias-berlin.de/software/index.jsp?id=TetGen&lang=1)
To continue with my wrapping career, TetRhino (or Tetrino) is a .NET wrapper for the well-known and pretty amazing TetGen mesh tetrahedralization program. It provides one new GH component for discretizing or remeshing objects using TetGen. Basic tetrahedralization functionality is exposed with a few different output types that can be controlled. At the moment, the only control for tetrahedra sizes is the minimum ratio, which is controlled by a slider. This is hardcoded to always be above 1.0-1.1, as it is very easy to generate a LOT of data (and crash)...
The libs are divided again into different modules to allow flexibility and fun with or without Rhino and GH, so have fun. All 4 libs should be placed in a folder (maybe called 'tetgen') in your GH libraries folder. Remember to unblock.
Once again, the libs are provided as-is, with no guarantee of support for now, as I use them internally and do not intend to develop this into a shiny, polished plug-in. If there is enough interest, I can tidy up the code-base and upload it somewhere if someone more savvy than me wants to play.
TetgenGH.gha - Grasshopper assembly which adds the 'Tetrahedralize' component to Mesh -> Triangulation.
TetgenRC.dll - RhinoCommon interface to the Tetgen wrapper.
TetgenSharp.dll - dotNET wrapper for Tetgen.
TetgenWrapper.dll - Actual wrapper for Tetgen.
Obviously, credit where credit is due for this excellent and tiny piece of software:
"The development of TetGen is executed at the Weierstrass Institute for Applied Analysis and Stochastics in the research group of Numerical Mathematics and Scientific Computing." See http://wias-berlin.de/software/index.jsp?id=TetGen&lang=1 for more details about TetGen.
To wrap up, some notes about the inputs:
These are the possible integer Flags (F) values and resultant outputs for the GH component:
0 - Output M yields a closed boundary mesh. Useful for simply remeshing your input mesh.
1 - Output M yields a list of tetra meshes.
2 - Output I yields a DataTree of tetra indices, grouped in lists of 4. Output P yields a list of points to which the tetra indices correspond.
3 - Output I yields a DataTree of edge indices, grouped in lists of 2. Output P yields a list of points to which the edge indices correspond. Useful for lots of things, very easy to create lines from this to plug into K2 or something for some ropey FEA (or not so ropey!) ;)
As this component can potentially create a LOT of data, especially with dense meshes, care should be taken with the MinRatio (R) input. This will try to constrain the tetra to be more or less elongated, which also means that the lower this value gets, the more tetra need to be added to satisfy this constraint. Start with very high values and lower them until satisfactory.
Hopefully shouldn't be an issue, but it's possible that you need the 2015 Microsoft C++ Redistributable.
Happy tetrahedralizing...
UPDATE: The tetgen.zip has been updated with some fixes.
UPDATE2: This is now available on Food4Rhino: http://www.food4rhino.com/app/tetrino
…
Added by Tom Svilans at 1:27am on October 24, 2017
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…
as the design table? I think this could be 'drawn' and constrained in Inventor in a lot less time. I know the GH model would have a lot of flexibility, but in this case, what can you do with it that wasn't provided by an Inventor model?
Only the 27 lines mentioned were modeled in Rhino, the rest is modeled with GH.
The 5 hrs involved thinking about the approach, defining vertical lines, tilts, elevations, pitch of the roof, intersections.
Once I had decided what my approach would be, and tested the logic with those first lines, points and data path arrangements, it only took one more hour to get to this:
Which is actually quite fast, compared to MCAD workflows.
If you already have components (columns, beams, etc.) modeled and ready to drop into a project, of course it is lightning fast to model simple projects like this example.
I am not as much interested in those situations, because improving efficiency is straightforward and obvious.
I'm more interested in situations where there are no pre-defined families of objects, in which case you need to start from scratch.
The GH model I'm showing is modeled from scratch, except for the 27 lines in Rhino.
Here's one obvious advantage to modeling with GH, once the definition is set-up, it's virtually effortless to change inputs and alter the overall design. Here's an example, lets say we wanted to extend the roof 3 more units, curling away from the original direction.
Plan view before:
And after:
An MCAD app will also allow you to do this, as long as the location of additional elements follows the existing geometric method of definition. What happens if you want completely change the way you locate columns, roof slope, intersection points?
In MCAD, you'll need to re-model the underlying geometry, which will take the same effort as the first round. In GH, this process is not only much faster, it's open to algorithmic approaches, galapagos, etc. and it just takes some simple re-wiring to have all down-stream elements associate themselves to this new geoemtric definition.
For instance, here's the same definition applied to two curves, which are divided in GH, the resulting points are used as a starting point for lines directed at normal from curves.
This is not so easy to do in MCAD.…
Added by Santiago Diaz at 7:55pm on February 24, 2011