of branches - you could consider using Prox2D or Prox3D to get individual line segments in between your points. If you tweak the maximum radius you could get a quite reasonable approximation. It's then possible to use a Prune tree to extract certain points (your branch "end points") that only have 1 line segment extending out from them. Then you can draw lines in between your branch "base" and "tips" (base will probably be furthest out in some direction, so might do a directional sort to isolate - these lines are the ones in light blue below) and feed the network into Shortest Walk. This should give you polylines from the base of your branch to all the individual tips, which you can then simply trim in order to get your branch lines.I've attached a short script that does the trick. Note that you'll need to have Shortest walk installed. The parameters work for this branch, but they might need some fiddling for other branches. Let me know if you have any questions!
…
Added by Dan Cascaval at 9:44pm on September 4, 2017
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
…
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…
ion, extract structural data, produce 2d drawings, and exchange data with other external software. Nemo also includes free tools to create parametric shapes, such as Naca profiles, hydrofoils, keels, rudders, blade propellers, and sail plans.
Born in 2018 as an academic research project at ENSTA Bretagne, Nemo grew up since, immersed in professional naval architecture practice with L2Onaval.
From 2021, Nemo is now available for purchase with commercial or educational licenses. Following license levels are provided to fit every needs depending of user activity :
Free (Designer)
Level 1 (Section + Hydrostatics + Visualization)
Level 1 + 2 (Section + Hydrostatics + Visualization + Resistance + Structure)
We can also help you make best use of our software, provide project guidance, establish specific workflow and create custom tools.
Requirements
Microsoft Windows 10 or Apple Mac OS 12 Monterey :
McNeel Rhinoceros 7 SR26
(Other Rhinoceros, Windows and Mac OS versions have not been tested but may work)
Additional info
Food4Rhino Download
Discourse Forum
Facebook Page
Linkedin Page
Nemo Website
Credits
Authors : Mathieu VENOT
Contributors : Paul POINET, Laurent DELRIEU
…
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.…
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…
All example files below are updated and compatible only with Wasp 0.1.0
Download it here: Food4Rhino
01_Basic_Aggregation
02_Multi_Part_Aggregation
03_Field_Driven_Aggregation
04_Part_Geometry_Rep
bi-directional link, the link is unidirectional (downflow only), because of the use of proxies.
Matrix transforms and persistent constraints: I don't think this is true. The parts can have mates to other parts that preserve geometric relationships like 'coincident' , 'aligned' etc. These are essentially bi-directional. GH's algorithmic approach does not do relationships in the same / flexible way. In GH, the 'relationship' has to be part of the generation method that dependent on the creation sequence. I.e. draw line 2 perpendicularly from the end of point of line 1. If you are thinking about parts or assemblies sharing, or referencing parameters as part of the regen process, this is also possible. iLogic does this, and adds scripting. So does Catia. Inventor/iLogic can also access Excel and have all the parameter processing done centrally, if required.
Consequently, scripting the placement of components is irrelevant in GH, unless you decide that each component needs to be contained in its own separate file.
I wouldn't be too hasty here. Yes, you are right about compartmentalisation. I think this needs to happen with GH, in order to deal with scalability/everyday interoperability requirements. Confining projects to one script is not sustainable. MCAD apps have been doing this for ages with 'Relational Modeling'.The Adaptive Components placement example illustrates that it is beneficial to be able to script some 'hints' that can be used on placement of the component. Say, if your component requires points as inputs, then its should be able to find the nearest points to the cursor as it moves around. I think Aish's D# / DesignScript demo'd this kind of behaviour a few years ago. Similarly, Modo Toolpipe reminds me how a lot of UI based transactions can be captured as scripts (macro recorder etc). Allowing this input to be mixed in and/or extended by GH I think will yield a lot of 'modeling efficiency' around the edges. This is a (mis)using GH as an user-programmable 'jig' for placing/manipulating 'dumb' elements in Rhino. It may even give the 'dumb elements' a bit more 'intelligence' by leaving behind embedded attributes, like links to particular construction planes etc.Even if we confine ourselves to scripting. GH is a visual or graphic programming interface. A lot of 'insert and connect' tasks can be done more easily using graphic methods. If we need to select certain vertices on a mesh as inputs for, say, a facade panel, its going to be quicker to do this 'graphically' (like the AC example), then ferreting out the relevant indices in the data tree et al. The 'facade panel' script would then have some coding to filter/prompt the user as to what inputs were acceptable, and so on.
This also brings up the point that generating components and assemblies in MCAD is not as straightforward. In iParts and iAssemblies, each configuration needs to be generated as a "child" (the individual file needs to be created for each child) before those children can be used elsewhere.
Not sure what you mean here. If the i-parts are built up using sketches /profiles or other more rudimentary features (like Revits' profile/face etc family templates) then reuse should be fairly straight forward. I suppose you could make it like GH scripting, if you cut and paste or include script snippets that generate the desired Inventor features.
One of the reasons why the distributed file approach makes perfect sense in MCAD, is that in industry you deal with a finite set of objects. Generative tools are usually not a requirement. Most mechanical engineers, product engineers and machinists would never have any use for that.
I don't think this is true. Look at the automotive body design apps, which are mostly Catia based. All of the body parts are pretty much 'generative' and generated from splines, in a procedural way, using very similar approaches to GH. Or sheet metal design. It's not always about configuration of off-the-shelf items like bolts. And, the constraints manager is available to arbitrate which bit of script fires first, and your mundane workaday associative dimensions etc can update without getting run over by the DAG(s) :-)
…