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…
r.
Jon has already done some very interesting stuff with regard decomposing matters using IFC schema (I'm not a strong admirer of any schema policy mind - for a variety of reasons).
Now the chaotic case:
1. This is deliberately fuzzy, faulty and chaotic in order to indicate the need (at least IMHO) for a next step with regard handling and visualizing (on a per individual data item basis, not on a per branch basis) data trees.
2. Why this Tree Manager future thing could boost GH up to an unseen level? Exploit the PDF attached - use Saved views and/or the Model Tree "decomposer" (file is greatly reduced in detail - only 1 out of 5 floors shown, no envelope stuff, stripped out of everything actually etc etc etc). Among a variety of things observe that there's transformations that are "selectively" applied whilst various components remain intact (in other words: invite existed "static" objects into the smart chaos) - this means that we need a far better control VS the series (of various type of data) that outline the solution of similar things.
3. What could/should do such a "visual" Tree Manager? Could he function within the existed "one Canvas for all things" environment? Do we need N "sub-canvas" (kinda the Views in any CAD app these days) to handle and visualize complex tree operations? Do we need control on a per data item basis? Do we need a re-mapper of a totally different kind? Do we need a Bake Manager? Do we need a Scenario (parameter combos stored etc) Manager?
Let's the debate begin
Best, Peter
…
pending on registered students
Who is it for > Aimed to professionals or students in engineering, architecture, art, design (interior, industrial, product, jewelry, furniture...) and backgrounds related
Requirements > Zoom app and Rhino 6 or 7 for Windows or Mac.
Is previous knowledge in Grasshopper required?
It is expected students know the Grasshopper interface, connections, basic operations and transformations, simple data list structures: longest list, flatten, graft... We do recommend check the program of the course "Grasshopper Basics" HERE in order to make sure you have knowledge on these tools.
Dates April 9-10
Registration deadline Monday April 4
Schedule: Saturday and Sunday. 3,30 - 8,30pm
More info:
https://controlmad.com/eng/formacion/curso-grasshopper-intermedio/
…
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.…
cálculos de otra manera imposibles de llevarse a cabo. La idea es mostrar una introducción a estos plugins explicando su funcionamiento general, ventajas y características con una serie de ejercicios prácticos a modo de ejemplo.
De esta manera se hará hincapié en conceptos muy presentes en el diseño e ingeniería avanzada: topología, form-finding, optimización estructural, fractales, loop, algoritmos genéticos y repetitivos, etc.
También, se dedicará un tiempo para sacar partido a tus definiciones y hacer más atractivo el diseño. Esto es, con una correcta exportación, animaciones, vistas...
ESTRUCTURA
- Geometría interactiva flexible
- Diseño generativo
- Reacción difusión
- Geometría desde parámetros ADN
- Visualización de estrategias generativas
- Simulación de crecimiento con sub-D
- Algoritmos generativos genéticos
- Técnicas de visualización
Los plugins que se verán asociados a estos conceptos son:
> Kangaroo: El plugin de Grasshopper más conocido y descargado que ya viene instalado en Grasshopper para Rhino 6. Es un motor físico que permite visualizar en tiempo real simulaciones interactivas y estrategias de form-finding.
> Galapagos: viene ya instalado con Grasshopper, es una plataforma que viene ya incluida en Grasshopper, para aplicar algoritmos evolutivos que se puede usar en situaciones y cálculos sin necesidad de conocer programación.
> Biomorpher: Muy parecido a Galapagos pero más sencillo y visual, Es un optimizador heurístico de cálculo de algoritmos evolutivos y genéticos, obteniendo la mejor solución en función de los parámetros o condiciones impuestos.
> Anemone: Usando algoritmos repetitivos, permite crear loops o estructuras secuenciales como los fractales.
También en función de la dinámica del curso se pueden ver otras apps como Weaverbird (subdivisión de mallas), Firefly, etc…
ts connectors and slots that allow CNC machining the facets and connectors for assembly.
https://www.youtube.com/watch?v=34OvgflJEmI
We developed this construction methodology earlier this year while working on a large scale parametric structure for Midburn, the Israeli Burning Man. While doing so I used grasshopper to generate the facets for the geometry, while a friend on the team (Matan Zohar) wrote a javascript app that translated the mesh into connectors and slots for CNC manufacturing. You can see more about the project here:
http://www.shlomimir.com/triped/
I wrote this component as an exercise in learning rhinoscript and python, with the purpose of bringing the functionality into the grasshopper workflow. It's now to the point where it is working for triangle and square welded meshes while outputting the connectors and slots as an unorganized list.
Questions and To Do List
1. I'm new to object oriented coding and functions, and basically just wrote the whole thing as a series of conditional loops with two dimensional arrays holding the data. Planning on restructuring this better, would love any tips.
2. Right now outputting the connectors and slots on the input mesh itself in 3D, planning on setting this up layed out on one plane to organize for cutting. I was wondering if there are any existing tools for this or if I need to do this manually.
3. Labeling connectors and slots. Is there anyway to output text from python that can be later baked into the rhino for labeling?…
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?
…
st shortest path. The guiding splines would work like a forcefield so that paths are "drawn" towards them with a user defined strength and radius of influence.Since each path is basically independent, it should be relatively straight forward to multithread. I downloaded the C# code for the pathfinding node and have to see if I'm up to it.
Would also be interesting to know how far away the first beta of a multithreaded GH 2 is.
I also had some hopes when "Fabric Engine" showed a demo of a Rhino exporter, since its "Canvas" is an extremely optimized node system that's fully multithreaded and optionally uses the GPU, which could be interesting to explore for some heavy lifting if they for instance would attach it to GH. But I guess it does not make much sense for them as a target.
Above image uses 20000 random points. In Softimage XSI ICE this would not be much, since it's nodes are fully multithreaded and optimized for huge numbers of particles and point deformation. In GH, with anything above 500 points, things get rather "meditative".
Illustrator takes up to half an hour after each and every change to colour, line style, blending mode etc. I have one even more complex file with over 3 GB size and there Illustrator (CS6 x64) goes into some kind of trance and after some hours of thinking moves on to some advanced psychotic, catatonic state to never fully return... ;-)So usually I run it in the background while doing something else...
I recently tried different other vector graphics apps (Inkscape, Affinity Designer, Xara) but they were even worse if they were able to open the files at all. Maybe I should give Corel a try too.
Cheers and thanks for your offer! Your work is a major inspiration for me while learning Grasshopper!
Tom…
dings,roads and 600meters radius for the terrain:
Which corresponds to what openstreetmap is offering if you search for your location:
https://www.openstreetmap.org/search?query=33.585289%2C%2051.588740#map=17/33.58750/51.59100
Google Earth is a commercial product, and it can have better data than openstreetmap and opentopography. There are people who are payed to create map content at Google Earth, while openstreetmap relies itself on volunteer work.You can also contribute to openstreetmap - you can draw outlines of each building in Abyaneh village, and assign a number of floors to those outlines - this is a simplified way on how to add height information to openstreetmap buildings. I did this for example for my hometown. Once you do this - this data will be recorded and anyone else using either openstreetmap or Gismo will be able to benefit from it.Here is tutorial on how to add number of levels information:https://github.com/stgeorges/gismo/blob/master/resources/tutorials/How%20to%20tag%20OSM%20geometry.pdfThere is no tutorial on how to draw building outlines, but in the upper tutorial you will see a "Line" button starting from step number 4. It really is that simple, just draw four lines to make one building outline.If you are not interested in mapping the Abyaneh village building outlines, then you would have to use some other plugin, like GHowl. It can import Google Earth meshes.…
Added by djordje to Gismo at 10:54am on January 26, 2022