oto )
I tried so many different ways but none worked !i need 3 layers, each layer has a different number of points, so there will be different size of holes. ( I think I've reached this point )I used a pop2d -> 2D Voronoi -> Scaled ( dist from curve ) but I want all three layers connected to each other, i tried also 3D Voronoi and the Voronax Plugin and none worked !I'm so confused :D
…
Added by Arian Sadafi at 3:59am on January 30, 2017
ay to make some real-life proper nodes for that kind of T truss (we use machined balls solely for MERO KK type of normal trusses).
3. I'll post here soon a modular demo system suitable for this case (real-life for AEC purposes - NOT for decorative/artistic stuff, I don't care about that since I'm an engineer). This would include a policy for the X struts that require a variable linkage (the X angle). and in the same time a multi cable tensioner "bracket".
4. "Basic" coding next week for T trusses ? Er ... well ... are you kidding me right? I mean that ... hmm ...
5. C# things (about 2+K) around me are classified into 2 "groups": things that are weapons in the right hands and others that serve as demos/start points for mostly abstract cases. The former are internal the latter for public use. I'll remove some sensitive lines from a T truss C# maker and I'll post it here as a "guideline" ... for ...hmm... 4.
All in all:
Provided that you have system(s) on hand (see 3) that work 100% OK in an ideal world you'll need:
A. Something that does the general topology AND (especially) clash detection. Maybe Kangaroo as well as a "first pass" with regard rigidity of the structure in case that you don't adopt a classic T "configuration" (there are many > Google tensegrity).
B. Connectivity trees that relate nodes/edges and maybe faces (say for roofing panels/curtain walls etc etc). Without them is impossible to assemble the T thingy.
C: Something that places real-life "parts" as instance definitions and/or (optional) a "tracking variants history" ability.
D. A bullet proof way to EXPORT things (on an assembly/component schema, say: STEP214 - see C) into a proper BIM app (the likes of AECOSim/Revit) and/or into a MCAD app (the likes of CATIA/NX).
E. FEA/FIM in order to validate the structural ability of the components and the T truss itself.
F. Roofing/cladding/envelope components.
G. "Interactive" cost estimation(s) - T trusses are hideously expensive at least versus "classic" trusses (exactly like a planar glazing system that retails 3++ times more than a humble semi-structural one)…
ject that involves the design of an app that allows people to interact with a 3d model through some sliders.)
Ok, imagine you have a symmetrical shape like the one i drew:
What I intend to do is to have different 3 sliders that allow me to adjust the 3 distances (x, y, z) independently of one another.
-1st question: my idea is to draw the curves in rhino, then use the "divide" and "list item" components to extract the points I need. Is it correct? :D
-2nd question: the "move away from" component can be used in a symmetric way?
(I try to be more specific: with only one slider, can I move both points 5 and 6 simultaneously about the axis i drew?)
-3rd question: is there a way that allows the curves to reshape themselves as I move the slider related to the distance between a couple of points?
I hope I have been clear ;) I would greatly appreciate any help you can give me!
Matteo…
to carry out without them. We will go through these plugins learning how they work, main features and advantages playing with practical exercises.
We will highlight key concepts in advanced design, architecture and engineering: topology, form-finding, structural optimization, fractals, loops, genetic and repetitive algorithms...
Also, we will see how to capture nice views and designs from your scripting, with a correct export option, animations...
This course is On-line live sessions (18hours), using our platform online.controlmad.com
STRUCTURE:
- Interactive flexible geometry
- Generative design
- Reaction diffusion
- Geometry from DNA parameters
- Generative path visualization
- Growth simulation by sub-D
- Generating and genetic algorithms
- Visualization techniques
Main plug-ins shown:
> Kangaroo: The most famous and downloaded app for Grasshopper (it is built in the current Grasshopper for Rhino 6). It is a live physics engine interactive simulation, optimization and form-finding directly within Grasshopper
> Galapagos: available in the current Grasshopper build, it is a platform for the application of Evolutionary Algorithms to be used on a wide variety of problems by non-programmers
> Biomorpher: Interactive Evolutionary Algorithms (IEAs) helping designers to explore the wide combinatorial space of parametric models without always knowing where you are headed.
> Anemone: works using repetitive algorithms to create loops or sequencial structures like those ones seen in fractals.
Dates: July 10,11,17 and 18 (total 4 days)
Registration deadline: Monday, July 5th
Timetable: Saturday and Sunday 9,30 - 2pm (Madrid Time Zone CEST)…
Added by Diego Cuevas at 3:40am on September 11, 2018
ces, cats, dogs anything.
3. Pick some in 2 and write down some algorithm (rather impossible without code) that makes "random" tree - like columns that grow with some fractal logic and "end" to the grid points in 1. Take case about some "even distribution" (see step 4). Obviously columns are made by tubes welded on site (expensive + tricky) or modular via some MERO variant (cheaper but a bit ugly).
Break: in order to do WOW tree-columns you need quality code not a mesh (or a CRAY or even ... hmm ... HAL9000). Estimated CPU time for a random tree-like column with, say, 5-20 nodes: 0.001 milliseconds.
4. place I beams (or C or IPE or IPN) along a given direction (or both) using points in 1 and support them by the ends of the tree-columns. I would recommend ball-pivot joints for obvious reasons.
Now ... this ... (as I said: I'm a bit lost). I mean ... doing this in a large scale (as your initial image suggests) is rather out of question even in Dubai (prior the D-Day). Maybe out of question even in China (where billions are aplenty).…
g that there's clash issues related with the convex edges: the "inward" ones so to speak).
2. If we call the teeth that is contained inside the Face "inside" (Length as in D) and the other "outside" (shorter Length > make a sketch > trigonometry > etc) ... then there's no clash issues ("along" each teeth: i.e. "along" the initial donor edge direction) since the inside meats always the corresponding outside.
3. However there's clash issues related with the start/end portions of the polyline (due to offset).
4. There's also clash issues ("across" each teeth, i.e. perpendicular to the initial donor edge) .. meaning that the polyline must take into account all these constrains (at creation time ... or at "offset" time)).
Guru refused to dig into more details (God knows what he actually means with all the above). He only added that the trick is an ability to watch BOTH polylines (per adjacent Face) at once (rather easy for him).
Moral: a tipple espresso for me please. …
ies of reference boxes and using the Box Morph component.
So far I've had some success, as shown in the image. However a few things have cropped up (probably not helped by my limited GH skills!)
1- The morphed geometry isn't aligned. I have ensured the original points match point for point; I have a feeling the u&v directions might have swapped?
2- So far I have been splitting the complex geometry manually in Rhino and defining manually in GH, then matching reference box to target box one by one. This was more for the sake of expedience, and to see if it worked; however I feel there must be a better way of doing this. Maybe the reference boxes split the complex geometry, then test for any contained geometry (the 'Inside' component?)
3- I feel there might be a better (existing!) solution somewhere, as I can't be the first person to try this!
I've attached an image of what I'm trying to do + the definition. The .3dm file is 12MB, I can send it upon request :D
All help would be much appreciated, thanks…
is the way the component was designed, but I love it and have used it multiple times.
You state:
Now for your position 3 the angle is either 0° or 180°. Since calculating the angle will always return both angle and reflex angle, you need to decide, which to use. AlignPlane uses minimal rotation. Hence your WorldXY will get no rotation at all for your position 3.
However... that's not actually true or what is happening. If you look closely at the image supplied in the original post you will see that the plane displayed at 180 is indeed rotated and the X vector is indeed pointing to -X. To double verify that I extracted the X vector from those planes and displayed them... clearly you can see in the image below that the AlignPlane component is rotating the plane at 180.
Now... to get back to the original issue. The problem I pointed out in my original post was not with the AlignPlane component, but rather with the OrientDirection component. It seems to me that component has an issue when fed a target direction of -X {-1;0;0} for a target vector.
To eliminate the confusion caused by the AlignPlane component I eliminated that component from the design and simply used rotated vectors as input to the target direction of OrientDirection. You will see that the results are the same... when given a target direction of {-1;0;0} the object is not rotated, while any other vector input does rotate the object.
I've attached the updated gh file demonstrating the issue using rotated vectors as the input for dB target direction of the OrientDirection component.…
ign to every location in the space is the result of the fall-off equation. F/D² in the Metaball componenty, where D is the distance from the point to the location you're measuring and F is the scaling factor:
3) You repeat this for all the points, giving you a collection of revolved hyperbola:
4) Add the elevations for all hyperbolas together, just a simple A+B+C process:
5) You intersect this final landscape with a horizontal plane. The elevation of this plane corresponds with the iso-surface value. If we do it for a bunch of planes, you get the following result:
6) The interior of each slice represents the metaball, or rather the boundary of each slice:
That is the theory anyway, in order to actually get a speedy result the algorithm approaches the problem from a very different angle, but the result should be the same shape.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
definition, you have 3 subsurfaces, so A = 0, 1, 2. For each subsurface you have a grid of points that is 76 x 76. Therefore, B = 0, 1, 2,...75, representing each of the 76 rows of points. Finally, each row has 76 points in it, so N=76 for each branch. Your data tree looks something like this:
{0; 0} N=76
{0; 1} N=76
{0; 2} N=76
...
{0; 75} N=76
{1; 0} N=76
{1; 1} N=76
{1; 2} N=76
...
{1; 75} N=76
{2; 0} N=76
{2; 1} N=76
{2; 2} N=76
Since you don't care that the points on each subsurface are organized in rows, you don't care about the B level of branches. You just need:
{0} N=5776 (76*76=5776)
{1} N=5776
{2} N=5776
So what I the Path Mapper does is get rid of the B level, flattening all the points into the A level. {A;B} --> {A} tells GH to just ignore the B level.
As for the Simplification, in this case (I think) it is just to more easily understand the data tree structure and make the Path Mapper syntax easier. If you un-Simplify the "P", "N", and "uv" outputs, you'll see the data tree structure is {A;B;C;D}, but A and B are always 0, so they aren't doing anything. If you left it like that, the Path Mapper would have to say {A;B;C;D} --> {C} since the second level of the tree, the C in this case, still represents the three subsurfaces. The Simplify on those outputs just gets rid of the unused extra levels that are always 0.
Whew! I hope that that was helpful and not more confusing.…