milar real-life AEC things that in fact are complex assemblies ... then your next (actually the first) step should be top-dog MCAD apps (but try Microstation + Generative components as well).
But given the opportunity there's 2 kind of "parametric" things out there:
1. The Topology (an abstract collection mostly of coordinate systems) that can been handled via graphical editors like GH. If there's some logic behind ... then ... maybe ... we can talk about algorithmic stuff (but who cares about names? not me anyway).
2. The real-life 3d things that are designed via dimension driven design, history based modeling, feature modelling etc etc (using exclusively high end solid modeling apps NOT surface modellers like Rhino). Basically you design these "by hand" (by mouse in fact) and then you "export" their "events" that "matter" to the app that does the 1 > then either you change them (clash/cost/structural/aesthetic reasons etc) or you change the topology. If these are ready parts from the market (kinda like the Norsman cable tensioners used) then ... you just keep them in RDBMS controlled repositories and use them accordingly. But if the project is really bespoke you can design them too as well (blame client's vanity).
So you have 2 kinds of "parametric": the theory and the reality ... whilst the "ideal" solution is some kind of equilibrium between "I want" and "I can".
On the other hand doing FEA on real-life bespoke complex parts ... well .... as I said months ago > what about some other Project? he, he.
But ... hope dies last ... there's a "middle" solution as well: wait for the 4 horsemen (the 4 C# that in fact are 5).
You'll be surprised…
(http://www.food4rhino.com/app/quelea-agent-based-design-grasshopper) take like 40 seconds when the toggle activates to go from one end of the ramp to another.
With proximity 3d i'm analyzing each instance the agents are closer than x units. In picture 3 we can see that in 212 instances the agent are closer than those x units.
Finally all the genes that controll the ramps are connected to the G of octopus component and one of the conflicting objectives connected to the O of octopus component is the number of instance quelea agents get close.
So the thing I need is to iterate the ramps controling the genes with octopus but activating the boolean toggle (quelea run) each time the ramps are modified so the agents take 40 seconds to perambulate the environment, analyze the instance they get close and let octopus iterate again searching for a optimized environment.
…
well!
Also works reliably in another app I have (Hydrostatics) to adjust 'Z-Offset' and re-establish buoyancy equilibrium.
I wasn't able to get it working inside a cluster due to the GH restriction against recursion, unfortunately, because that would be AWESOME!!! Instead, the code is sprawling and exposed...
Note the 'Feedback' input and 'Value' output in the white group (Inner Circle).
Cheers and Happy New Year!
P.S. Geometry internalized, no Rhino file needed.…
Added by Joseph Oster at 4:53pm on January 1, 2016
size sets the resolution of the blob(s) and smoothing comes after to have a smooth mesh describing your points.
best
alex
edit
well this post was unanswered with refresh, until i posted, when it turned out 5 minutes earlier Kim was there.…
gt; most probably > adios Amigos.
3. WP Loop VS ... > see above
4. Daniel VS ... > see above.
There's other dedicated apps for handling huge amount of data (using very fast ball pivot algorithms for dealing with the gazillion of points).…
Get plenty of RAM. Windows 32-bit can assign 2MB of Ram per process, so if you have lots of RAM, you can run Rhino+Grasshopper in memory all the way. I'd say get at least 4GB, and preferably 8GB. If you have a 64-bit machine, then it pays off to go even higher than that.
2) Get fast RAM. Memory access is the main bottleneck in many applications, so the faster the RAM the faster most apps will work.
3) Get a fast processor, rather than lots of slow processors. Only a few apps out there can truly use Multi-Threading (Rhino and Grasshopper cannot). These days, CPU manufacturers try and dress up multi-core CPUs as the next best thing. It is not. It is a lie. Until software can truly run on multiple cores there is no benefit to this. If rendering is a big part of your job, then it does pay off to have a multi-core machine though.
4) Get a good graphics card. I've always preferred NVidia over ATI, but there are many good ATI cards as well. You can go for a gaming card (they're cheaper), but note that these are optimised for drawing triangles. If you get a professional card, it will draw lines and curves much faster.
--
David Rutten
david@mcneel.com
Robert McNeel & Associates…
on) ... the only way to do something meaningful/realistic is to follow Bentley System's way: they had 3 rendering engines (all highly problematic and archaic), a bunch of highly paid "gurus" to "develop" the dead fish and an export to Maxwell capability as well (Maxwell is very slow and has no chance VS Nexus, see below). PS: "Gurus" had no idea about Quest3D and the likes.
At the time, I was near to some permanent ban (he he) from all Bentley Forums due to my acid writings about how stupid these methods were. In fact I openly proposed to Bentley (to Ray Bentley to be exact) to fire all "gurus" involved ... and follow the outsource path.
Finally Ray (he's very smart) did the right thing: after an agreement with Luxology ... now Microstation (the core product) uses the Nexus engine (as found in Modo). This means that the Nexus is fully integrated across the whole vertical suite of BIM AEC Bentley apps the likes of AECOSim (that includes Generative Components as well).
And as everyone knows THIS is the real McCoy (US movie industry is behind that thing).
Additionally Modo has the best GUI known to mankind (US movie ... blah blah) and astonishingly innovative thinking (US movie ... blah blah).
…
ee. That said these things (masterminded by a certain David R) are not bad at all ... but if you write code that is "supposedly" transferable (kinda) to other CAD apps ... well ... I would strongly recommend the other classic nested C# collections.
2. The HLP method is one out of many: for instance for a better approximation of the required fitted plane we can use the divide Curve method etc etc.
3. GH components use (in most of cases) methods exposed in Rhino SDK > get the thingy and start digging into the rabbit hole. Of course David did some other components as well that use "less" classic SDK methods (if at all).
4. HLP is a classic approach to count the beans in nurbs curves. Of course I could use PolyCurves and recursive explosion blah, blah ... but here we are not after segments (at least at present time). On the other hand if that was a Faceted Dome (planar Polylines) ... well getting the nodes that way it could be an overkill (this means business for V2).
5. Mastermind some plane orientation policies in order to finish(?) the @$%@$ thing. For instance: Given Plane plane, define a Plane.WorldXY at plane.Origin and section these 2 > then get the cross product (sectionVector, plane.ZAxis) for the new orientedPlane Y axis etc etc (this presupposes that any plane Z axis points "outwards": use Dot Product and a center point as apex etc etc).…
quite know where I'm going wrong. I can say that I have successfully put together a separate file which will send data directly to the Arduino (switch on a boolean toggle and watch an LED light up... how fun:) but receiving the data is a bit more complicated. For a long time, I was getting a continuous loop error, which would freeze my app. I've changed around the code (see attached file), but I'm still not receiving any data from my COM port (which I know is definitely working because I can turn on the Serial Monitor from the Arduino IDE and see the data coming in). I did have one question: Can you call different routines inside the script class (from Grasshopper), or do you have to always call the run script subroutine? If you guys have any suggestions I would greatly appreciate it. I understand it's a bit tricky to trouble shoot this issue since you may or may not have an Arduino handy to stream the data to your computer... but let me know if you see any glaring issues with the code.
Cheers,
Andy…
this, you'll have no horizontal force at the roller, but you will have it at the pinned support. If you wouldn't, then the structure will be displaced.
Usually, in 2 dimensional structures, if you want to know if an articulated structure is isostatic (as opposed to hyperstatic, which is what you have right now) is to use the following formula:
b+c-2·n=0;
b being the number of bars, c the number of constraints you have and n the number of nodes. In your case: b=19, c=3 (displacements constrained in X, Z at your pinned support and only constrained in Z at your roller support) and n=11, so: 19+3-2·11=0.
I recommend you to download the app SW Truss, as it's very useful to check your results instantly.…