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…
alluded to:
By the way, Riccardo, as you surely know, for this app, it really only makes sense to use odd integer values on the slider for "half-twists total counts"... When I used "2" with the chain, it froze GH/Rhino twice - perhaps because I didn't disable the offset surface code, I'm not sure - not enough time to explore that further.
So here is what I came up with for offsetting a holed surface - much less code!
Instead of offsetting the surface and using the two offsets as input for 'SrfMorph' to map the holes curves:
I accept the trimmed surface with holes (only one 'SrfSplit' operation instead of two).
'Untrim' the holed surface before doing the offsets.
'Copy Trim (Trim)' from the original holed surface to the two offset surfaces.
Get all the 'Edges' from both surfaces, 'Flip' and 'Loft' them to get all the edge surfaces (hole walls and outer edges).
'Brep Join' the offset holed surfaces and edge surfaces together.
The result is interesting... a "Open Brep" and two "Untrimmed Surface", which are the hidden, internal ends of the shape. Not quite what I wanted. Then I discovered that using 'DeBrep' to get the 'Faces (F)' and 'Brep Join' once more, I get a "Closed Brep" (a solid)!!?? Not sure why but glad it works. I ignore the two end surfaces using 'List Item'.
I suspect that the holes may be slightly different than the way I did it yesterday, but they look good to me. I have no idea how effective this will be with arbitrary, complex surfaces but I encapsulated this code into a 'Thicken' cluster, also enclosed in the attached code:
…
Added by Joseph Oster at 9:01am on October 10, 2015
ents (e.g. only fabric between 2 radial cable). But if I try to simulate a completely whole structure like picture below + if I trying to model a material that has more degree subdivision + adding diagonals (as resistance to shear deformation which causes the creases like Daniel Pikels example of tablecloth drop), then I have huge problem to deal with my hardware.
(I am using Intel Xeon 4 cores, 2.93GHz with 4GB RAM and running in Win7 in 64 bit but with Rhino 32 bit.)
(Roof geometry can be completely asymmetrical, so let’s assuming that we can’t array the resulting geometries!)
There are some discussions about how to increase the processing power of grasshopper:
http://www.grasshopper3d.com/forum/topics/is-there-a-plan-to-suppor...
http://www.grasshopper3d.com/forum/topics/performance-of-grasshopper?
http://www.grasshopper3d.com/forum/topics/grasshopper-cpu-optimization
As I know that the GH is single threaded, we could over clocking the CPU + give lot of RAM.
I am curious if Kangaroo and other Apps are following the same performance-rule (single thread) like Rhino/ G.H? And what would be the key-feature to increase the power of Rhino/GH/Kangaroo in order to process the case I mentioned before (completely retractable roof)?
- Which level of CPU? Or constraint of CPU over clocking when necessary and capacity of RAM)
- How fine tuning my PC for best performance? (Parallel computing, c-flex…)
- is GPU a matter? (E.g. in Animation standard: Nvidia CUDA Quadro 4000+)
Or probably just a suggestion of workstation ;-)
Sorry I am not expertise of computer technical…
Thanks!…
w elements (e.g. only fabric between 2 radial cable). But if I try to simulate a completely whole structure like picture below + if I trying to model a material that has more degree subdivision + adding diagonals (as resistance to shear deformation which causes the creases like your example of tablecloth drop), then I have huge problem to deal with my hardware.
(I am using Intel Xeon 4 cores, 2.93GHz with 4GB RAM and running in Win7 in 64 bit but with Rhino 32 bit.)
(Roof geometry can be completely asymmetrical, so let’s assuming that we can’t array the resulting geometries!)
There are some discussions about how to increase the processing power of grasshopper:
http://www.grasshopper3d.com/forum/topics/is-there-a-plan-to-support-multicore-in-the-future
http://www.grasshopper3d.com/forum/topics/performance-of-grasshopper?
http://www.grasshopper3d.com/forum/topics/grasshopper-cpu-optimization
As I read that the GH is single threaded, we could over clocking the CPU + give lot of RAM.
I am curious if Kangaroo and other Apps are following the same performance-rule (single thread) like Rhino/ G.H? And what would be the key-feature to increase the power of Rhino/GH/Kangaroo in order to process the case I mentioned before (completely retractable roof)?
- Which level of CPU? Or constraint of CPU over clocking when necessary and capacity of RAM)
- How fine tuning my PC for best performance? (Parallel computing, c-flex…)
- is GPU a matter? (E.g. in Animation standard: Nvidia CUDA Quadro 4000+)
Or probably just a suggestion of workstation ;-)
Sorry I am not expertise of computer technical…
Thanks!
…
Added by Jon to Kangaroo at 3:31am on June 27, 2014
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) :-)
…
folder. There are several possibilities for this.
The first that comes to mind is using symbolic links (also known as symlinks). They are like a special kind of shortcut. Whereas a shortcut is a small file itself that links to another location, a symlink is a link that to the operating system and pretty much anything else is indistinguishable from the actual thing. That's why a certain care has to be taken with them, but they are used by the OS much more than might be obvious at first. I have used them on OS X a lot (and in fact all of Time Machine works almost entirely through the use of symlinks). There is a good article on how to use Symlinks easily on Windows as well, using the Link Shell Extension.
So once it's installed you can go to your Grasshopper folder in Roaming and pick it as the link source like so:
Then you change to a location in for example your Dropbox or wherever else you fancy. I have a folder inside my personal Dropbox (we use Dropbox for Business at work, thats why I have 2 Dropbox folders), there is a folder called Apps, which is used by all sorts of Apps that sync using Dropbox. So just right-click in there and create a symlink like so:
So now it will create the symlink and when you double-click it, it will contain the contents of your Grasshopper folder and start syncing:
Sure enough, after some uploading you now have your folder in Dropbox and continually updating:
I will leave this now and see how I get on, but it should be fine and shouldn't cause any issues. Now doing this the other way round, for example to sync the folder on a second computer, that might be another story as things like permissions start to come into play, although it should theoretically work. I have done similar things in the past with other software, but Dropbox is not the best in keeping permissions. Or rather in most cases you DONT want the permissions to stay the same, but for them to be changed to whoever the user is on a different computer and that does not always work as expected. But worth a try. I don't have another computer at hand to try this. On the other computer you would to the steps in opposite order and pick the folder in the Dropbox as the link source and then drop the symlink in the roaming folder (rename the Grasshopper folder that is already in there, so in case it doesnt work you can delete the symlink and rename it back to what it was).
This should theoretically also work with other cloud backups or a file server, but I have not tried those.
You can delete the symlink in the dropbox without problems and it will just delete the link. If you delete something in the Grasshopper folder inside the dropbox it will also be deleted in the roaming folder.
Disclaimer: No guarantees, do this at your own risk, backup your grasshopper folder just in case, be careful with symlinks and use them sparingly, take notes of what you are doing, especially when doing this on more than one computer.
I know on OS X there are several tools specifically for Dropbox that basically do exactly the same like MacDropAny, I am sure there is similar stuff for Windows.…
Added by Armin Seltz at 2:56am on January 25, 2016
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
…
whole design intent, but this is what Inventor is good at. The way it packages bits of 'scripted' components into 'little models' that can be stored and re-assembled is central to MCAD working.
The Inventor model shown is almost 5 years old. We don't model like that any more, however it does offer a good idea of general MCAD modeling approaches.
iParts is useful in certain situations, it could've been useful in the above model, its usefulness is often in function of the quantity of variants/configurations.
So much is scripted in GH, maybe it should also be possible to script/define/constrain/assist the placement/gluing of the results?
...
Starting point: I think we are talking across purposes. AFAIK, the solving sequence of GH's scripted components is fixed. It won't do circular dependencies... without a fight. The inter-component dependencies not 'managed' like constraints solvers do for MCAD apps.
Components and assemblies are individual files in MCAD.
Placement of these within assemblies in MCAD is a product of matrix transforms and persistent constraints. There is no bi-directional link, the link is unidirectional (downflow only), because of the use of proxies.
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.
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.
You notice the dilemma, if you generate 100 parts, and then you realize you only need 20, you've created 80 extra parts which you have no need for, thus generating wasteful data that may cause file management issues later on.
GH remains in a transient world, and when you decide to bake geometry (if you need to at all), you can do that in one Rhino file, and save it as the state of the design at that given moment. Very convenient for design, though unacceptable for most non-digital manufacturing methods, which greatly limits Rhino's use for manufacturing unless you combine it with an MCAD app.
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.
The other thing that MCAD apps like Inventor have, is the 'structured' interface that offers up all that setting out information like the coordinate systems, work planes, parameters etc in a concise fashion in the 'history tree'. This will translate into user speed. GH's canvas is a bit more freeform. I suppose the info is all there and linked, so a bit of re-jigging is easy. Also, see how T-Flex can even embed sliders and other parameter input boxes into the model itself. Pretty handy/fast to understand, which also means more speed.
True. As long as you keep the browser pane/specification tree organized and easy to query.
:)
Would love to understand what you did by sketching.
I'll start by showing what was done years ago in the Inventor model, and then share with you what I did in GH, but in another post.
Let's use one of the beams as an example:
We can isolate this component for clarity.
Notice that I've highlighted the sectional sketch with dimensions, and the point of reference, which is in relation to the CL of the column which the beam bears on. The orientation and location of the beam is already set by underlying geometry.
Here's a perspective view of the same:
The extent of the beam was also driven by reference geometry, 2 planes offset from the beam's XY plane, driven by parameters from another underlying file which serves as a parameter container:
Reference axes and points are present for all other components, here are some of them:
It starts getting cluttered if you see the reference planes as well:
Is I mentioned earlier, over time we've found better ways to define and associate geometry, parameters, manage design change, improving the efficiency of parametric models. But this model is a fair representation of a basic modeling approach, and since an Inventor-GH comparison is like comparing apples and oranges anyways, this model can be used to understand the differences and similarities, for those interested.
I haven't even gotten to your latest post yet, I will eventually.…
Added by Santiago Diaz at 10:36am on February 26, 2011
GH works (b) creating feature driven very complex parametric parts manually (the trad way) ... and then combining them in assemblies derived from (a) with components derived from (b).
Exactly what Generative Components does (if we forget the bugs, the extremely slow response, the lack of any development, the bugs, the bugs and finally the bugs).
Creating collections (libraries) of components in Rhino it's pointless since he doesn't support feature driven modeling. This means constrained driven geometry (solids NOT surfaces - another reason for totally excluding Rhino for the scope) that describe the actual components (that belong to nested assemblies etc etc).
So back to (a) : The only thing that Rhino/GH can do (in real-life) is to outline an abstract topology with "basic/primitive" geometry in place (= lines in this case). Exactly what this WIP script does, in fact. Of course it can do calculations as well (clash detection AND drilling axis related stuff).
But never say never: let's inspect an example from some WIP project (AECOSim + Generative Components) of mine to see what can GH/Rhino additionally do (in real-life):
Imagine a rigid "ring" (the truss shown) that manages tensional forces (via cables) in a "ring like" formed tensile membrane combo. Membranes (inverse cones) pull the ring thing downwards and mast attached cables pull it upwards = equilibrium (or disaster if some cable fails, he he).
So assume that the abstract layout (lines, that is) is made with a similar GH script with the one posted here. Rhino can't even imagine doing the parametric fasteners shown - thus we exclude them from the equation.
But GH could(?) "indirectly" feed a proper CAD app (from AECOSim to CATIA) with "seed" information in order to help making the components and the assemblies of components.
For instance assume that every truss linear member is a classic MERO system (ball - sleeve - cone - tube -cone -sleeve - ball). It's pointless to create (in GH) and bake a nested Block structure with "real geometry" (surfaces, that is) and export it via STEP : we can export lines + coordinate systems instead (ACS) ... that could be sufficient for AECOSim to replace "parts containing lines + ACS" with real-life "parts containing constrained/feature driven solid objects".
So the real challenge here is to mastermind a suitable nested block structure (and an equivalent GH_structure) that could pass the right assembly/component info.
I'll be back soon with some add-on script that takes truss lines and makes them MERO style "surfaces" in order to practically outline the issue(s) and the goal.
…
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