getting answers for on the web.
Our goal is to install a scientific research lab in a forest to study the proliferation of a deadly tree disease so we would like to design a sort of big cocoon that is in part randomly generated and that would wrap around the trees inside it similar to how the disease proliferates through the forest... Unfortunately, we are having a few problems modeling it on grasshopper, here are our questions :
First off we have generated a grid on which we have attached vertical lines that represent the trees of the forest we are working on, we have also modeled a grid that is the dual to the first one (links the centers of the cells of the first grid together to form another grid). We have generated points of random z coordinates that follow the x and y coordinates of the second grid, and we have applied metaballs to those random points.
1. We would like to know how to create a surface from the curves generated by the metaballs in my grasshopper file ?
2. We would like to know if it is possible to push the surface away from the lines on the grid, as if there was a magnetic field pushing matter away from them ? we are hoping it would look a bit like this (the black lines being the trees and the big grey volume the surface wrapping around the trees, avoiding them) :
If you have any ideas of a better way of representing what we want to model please let me know (or if it isn't well explained please call me out on that). What we like about our grasshopper file for now is that you can kind of change the sizes of the metaballs pretty easily, the fact that they are randomly generated and smoothly blend together, but if you know a better way of achieving a similar result please let us know!
A few pics of what it looks like as of now :
Here is our grasshopper file attached, to generate the metaballs you just have to make a point in the center of the very first cell of the larger grid, so the corner of the second grid, and link it to the point in the grasshopper file.
Thanks, Sarah, Vincent and Nicholas…
le and grasshopper timer to simplify simulation control. Double click the main Kangaroo component to open this remote. There are buttons for Stop(reset), Play, Pause, and Step (moves the simulation forward one iteration).
Line-line force - allows interaction between line segments - they are treated as rigid cylinders. As with springs, there are settings for offset and rest distance, so this can be used to simulate colliding rods, and also for keeping cylinders tangent to one another (can be used for reciprocal structures).
Gear simulator - collision between curves in a plane, can be used for various mechanical simulations - cams, gears, rack and pinions etc.
Developablize force - adjusts vertices of a mesh locally, to make angles around each interior vertex sum to 2*Pi, so the mesh can be unfolded to a flat sheet without stretching.
Volume dependent pressure force - allows you to set a rest volume for a mesh instead of just a fixed pressure. When combined with Laplacian smoothing for area minimization, this can be used to optimize for CMC (constant-mean-curvature) surfaces. It will also work on open meshes.
Translation lock - maintains a fixed relationship between a pair of points. This can be used to enforce periodic boundary conditions for TPMS.
Equalize angles force - given a set of angles (defined by 3 points each), this tries to adjust them all to become equal.
Mirror symmetry force - can be used to minimize curvature variation, and optimize for higher order curve continuity. It can also be used for simulating torsional resistance in curved rods.
True minimal surface relaxation - Laplacian smoothing force now includes an option for cotangent weighting, which optimizes for zero mean curvature, unlike spring based methods, or uniform weighted Laplacian smoothing which only roughly approximate this.
Fast sphere collide - allows much faster collision detection between large numbers of spheres. By placing these spheres at the vertices, this can also be used for collision between meshes.
Force-density element - an experimental one, more on this later
Projected-force - adjusts its strength so the component of the force in a given direction stays constant.
New mesh tools:
WarpWeft - sorts the edges of a quad mesh into warp and weft directions. This can be used to assign them different stiffness in fabric form-finding.
Checkerboard - sort the faces of a mesh into 2 lists so that 2 faces of the same colour are never adjacent.
MeshDirection - sorts the vertices of a quad mesh to give it a sort of u-v directionality
Refine Strips - subdivision in one direction only - can be used to generate developable strips
Stripper - separates out the strips of quads from a larger mesh
Unroller - unfolds a quad strip to flat without stretching
MeshMap - maps points from one mesh to another (can be used together with circle-packing to generate conformal mappings)
Reciprocal structure - generates starting geometry for a reciprocal structure from any input mesh (using the Plankton mesh library *Note* If you already have the Plankton components installed, you will need to update to version 0.3.0, which is available from here)
ReMesher - adjusts the connectivity of a mesh by flipping, splitting and collapsing edges to make all edge lengths closer to a target value
Diagonalize - creates a new face for every edge of the original mesh. Can be used on quad meshes to easily convert to a diagrid.
Refine - simple non-smoothing subdivision, splitting quads into 4 quads, and triangles into 4 triangles
QuadDivide - subdivide quads by any number squared, not just powers of 4
Corners - finds the corner vertices of a quad mesh
ByParent - simple quad subdivision, keeping the output grouped by parent face.
User objects:
The download comes with an increased collection of user objects to simplify setting up common simulation types - Including a simple to use origami simulator, a reciprocal structure generator, and a tool to generate compact circle packings from a CP mesh.
General:
Geometry input now accepts polylines and straight curves.
Hinges can now be fold completely flat in both directions.
Various other minor bug fixes and speed improvements (including much faster removeDuplicatePoints/Lines components)
*****
I've not yet updated all the documentation and example files to reflect this new version, but over time I will keep posting here with new demos and explanation of all these new features. I'll try and add a few new examples each week. Vote in the comments below if there is a feature mentioned above that you're particularly keen to hear more about soon.
No doubt there are still some bugs to be discovered. If something isn't working the way you expect or want it to, please post in this forum (ideally with a description or sketch of what you think should be happening, and a clear description of what happens instead and any error messages).
There are also some more new features that weren't quite ready to make it into this release, but are on the way shortly...
Kangaroo remains completely free, for personal, academic, and commercial use. I'm always interested to hear about projects done using it, and suggestions for improvements or additions.
Daniel
…
ight be able to provide more insight). Whenever you run a new simulation in Radiance, it is not always necessary to re-write all of the initial simulation files from scratch. These initial simulation files include both a .rad geometry file as well as a separate .pts file that contains the test point locations. If all that you are changing in a given parametric run is the locations of the test points (like your case), it is not necessary to re-write (or reinterpret) the entire .rad geometry file. My guess is that there is some type of check for this built into either code Mostapha wrote or radiance functions that Mostapha is calling. As such, it seems that the rad geometry file is not being re-written (or re-interpreted by radiance) completely when all that you change is the test points and this actually seems to be saving you an extra 10 seconds each time that you run the component without changing the materials or the building geometry. Other times (like when you plug in custom radParameters), it seems that it re-writes (or re-interprets) the .rad geometry file from scratch since this file is probably affected by customized rad parameters.
So far, if this explanation is holding, it seems like there would be no concern on your end but I also recognize that the difference between these long and short simulations is giving you radiation results that are ever so slightly different from each other (by my estimates, they differ by about 0.2%). Compared to the other types of assumptions that the radiance model is making, though, these are mere rounding errors that probably originate from the number of decimal places in the vertices of the rad geometry file. Rather than worrying about whether your simulations are giving you the right rounding errors to give you matching results, I would encourage you to instead contemplate how much your radiance results are matching reality given all of the assumptions that you are making about the climate (with the epw file for a "typical" year) and with the number of light bounces in the radiance simulation. To give you an example, I ran your model with a higher quality of simulation type (3 ambient bounces) and this gives you results that differ by 1.1% from the original simulation that you were running with only 2 ambient bounces (this is practically an order of magnitude larger than 0.2%).
To address your unease I will say that, for a long time, I also felt uneasy any time that I encountered something that seemed unpredictable in software that I was using. Once I started coding my own stuff, though, I realized quickly that unpredictable behavior is an unavoidable aspect of all software. There is always a tradeoff between accurate results and the time it takes to get them, which produces a multitude of possible ways to arrive at a solution. Add into this complex situation the fact that you might have an almost infinite number of possible inputs to a given set of code.
Because of the unpredictable multitude of cases, there is no application that is completely free from limitations and assumptions. In this light, what ends up being more important than the actual calculation method used is the social infrastructure that is in place to help understand what is being run under the hood, hence why both Radiance and Honeybee are open source and why we try to build a robust community of support through forums like this one!
-Chris…
ts in extreme aliasing effects that carry into the 3D realm as regular steps along what should be smooth surfaces.
On sleeping on it, I realized I hadn't yet tried fast Unary Force on fine quad meshes from the standard Grasshopper meshing system that includes the meshing options component.
Bingo! It's fast now. Workable. I don't need super fine meshing since I'm not running from aliasing. I can still use rather fine local meshes since Unary Force lets Kangaroo do a simple thing just in the Z direction rather than a full 3D force.
After only a minute or so of Kangaroo initialization that slows the interface, each of a dozen needed cycles takes half a second, FOR THE ENTIRE GRAPHIC.
I just set the timer to 1 second so I can move around the interface, and I double click the Windows taskbar timer shut-off to enjoy the result.
WHILE RUNNING VIA TIMER, IF I CHANGE A SPRING/FORCE SETTING IT SUFFERS NO DELAY AT ALL AND JUST ALTERS THE OUTPUT OVER TIME. I can change Unary Force from 20 to 100 and immediately see the bigger areas balloon like crazy:
It's fast enough overall to play with, yet the individual steps are slow enough that it's fun to watch the hysteresis as it overshoots back from 100 to 20 Unary Force, going concave in the middle of bulges then back to more shallow hills.
A force of 1000 is a bit disturbing, I wonder if I can tamp it down with greater spring strength or will that just give me the same result as before?
Looks like it's the same, just the ratio matters. Makes sense I guess. At one point it blew up though. Hitting the reset button...a minute later it blows up again...and just doesn't like huge numbers, so I don't see an advantage playing with bombs. The high mesh strength is pulling the mesh apart.
With low Unary Force and moderate mesh tension, you get flat tops, as if the overall force on the mesh fighting its anchored edge vertices, is enough to displace it, but the surface itself is too stiff to care about local gravity.
Then you have less flat areas as you increase Unary Force:
Weird, there *is* some sort of absolute effects, rather than just relative, between Unary Force and spring stiffness, since now I'm getting flat tops even in the extreme:
Oh, wait, strike that, I may be seeing but a single step with the timer off, subject to hysteresis. With the timer back on...it can sit there a minute...not locked up but just idling...until you see the Display > Widgets > Profiler time start cycling to near half minute numbers...makes you want to hit the reset button...and indeed that locks the interface for another initialization...and yes, it was merely hysteresis, not an equilibrium result. My former flat tops may have been due to that too, due to my use of the Windows taskbar timer disabler. The lesson is that you can obtain different results by using a long timer setting and just stopping it before it equilibrates.
This script is a keeper, fast and fun after the relatively mild Kangaroo initialization period is over.
The uniform mostly quad meshing is all done in Grasshopper too, from any flat surface with holes, especially from images of shapes that are traced with potrace to give surfaces with holes.
Could I switch to hex meshes from triangular meshes to do the same thing with fewer vertices?
Are there other forces I can add to smooth the bulging? Letting things bulge is not so bad if you then just scale down the result in Z afterwards (though perhaps the same result could be had with lesser force):
Also, can this same thing be done with possibly faster Kangaroo 2?…
Added by Nik Willmore at 10:02pm on February 21, 2016
nd linear/planar tectonics. Within this new field of investigation, the Stuttgart VS will be researching into novel techniques of material mixtures and grading, associative design and double curvature surface generation.
For the second cycle of this exploration we will be based at the Institute for Lightweight Structures and Conceptual Design (ILEK) at the University of Stuttgart. Drawing from the Institute’s long history of experimentation and research on tensile structures instigated by Frei Otto in the 1960s and conducted at present by Werner Sobek, this year we will be focusing on the design and fabrication of materially graded membranes, as well as the application of UHPC and FGC on fabric formworks. The workflow followed will be divided into two stages:
1. Computing Membranes: Computational form finding methods will be taught by professional engineers and architects from ILEK and str.ucture GmbH. The aim will be to utilise the latest software technologies to form find membranes for textile structures, or fabric formworks for complex concrete structures. The results will be evaluated against criteria such as internal air pressure, as well as asymmetric and wind loading. The outcome of this research will inform the material grading procedures (i.e. changing the stiffness, thickness or porosity of the membranes themselves, or the consistency of the concrete poured into the formworks) that will follow in stage two.
2. Fabricated Grading: The digitally computed membranes or formworks will eventually be fabricated physically, utilising the workshop and robotic fabrication facilities at ILEK. The objective will be to rethink conventional research on tensile and concrete structures as isotropic constructs, by customising attributes such as materiality, reinforcement, rigidity, translucency, patterning, and porosity among others. The final, graded prototypes will be made up of mixtures of materials, all accurately engineered to respond to variable environmental, structural and aesthetic criteria, in essence forming multi-material structures that have finally caught up with the latest material developments.
Prominent Features of the workshop/ skills developed:
Teaching team consisting of AA diploma tutors and ILEK and str.ucture GmbH engineers.
Access to the Institute of Lightweight Structures and Conceptual Design (ILEK), the Materials Testing Institute and Concrete Spraying Robotic facilities at the University of Stuttgart, as well as to the office of str.ucture GmbH Structural Design Engineering.
Computational skills tuition on Grasshopper, Rhino Membrane, and Karamba.
Lectures series by leading academics and practitioners in architecture and engineering.
Fabrication of functionally graded membrane and/or concrete structures.
Eligibility
The workshop is open to current architecture and design students, PhD candidates and young professionals. Software Requirements: Rhino (SR7 or later) and Grasshopper.
Fees
The AA Visiting School requires a student fee of £595 and a young professional fee of £895 per participant, which includes a £60 Visiting membership fee.
The deadline for applications is 10 July 2017.
For more information, please visit:
http://www.aaschool.ac.uk/STUDY/VISITING/stuttgart?name=stuttgart
For inquiries, please contact:
mixedmatters@aaschool.ac.uk…
tically give you back all the items of the list. However, if you give it a list of lists (as you are in this example) it doesn't know to extract the items in the internal lists. The script I suggest simply reinterprets each list as a single item, and relies on the component data processing to split out the items list by list. This also has the advantage (over 筑梦NARUTO's solution) of keeping each list in its own grasshopper data tree branch.
If you'd rather avoid the clunkiness of a second script component, you'll have to compose a datatree yourself. That will look something like this:
import math as m
import Rhino
from Grasshopper.Kernel.Data import GH_Path
from Grasshopper import DataTree
pi = m.pi
angle =0
pts = DataTree[Rhino.Geometry.Point3d]()
c=0
for i in rs.frange(0,5,0.5):
angle +=(pi/30)
layer = []
for j in rs.frange(0,2*pi,pi/15):
x= 5*m.sin(j+angle)
y= 5*m.cos(j+angle)
layer.append( Rhino.Geometry.Point3d(x,y,i))
pts.AddRange(layer,GH_Path(c))
c = c+1
a = pts
…
to explain the ultimate goal in case it helps to clarify. I have all the elements i need now to pull this together thanks to your help, as you say most critical things are already implemented or not relevant to this particular thread. With your fret generator and equal spacing generator and my primitive convoluted solution for compound radius fretboard i have everything i need but need some time to cleanly implement and pull it together now.
as to your questions/coments:
1/ I don't care about Excel files in this context. The SIMPLE solution is to just copy/paste sets of string gauges into as many panels as you need and switch between them.
this was just to explain that ultimately there are a lot of different input patterns but all the data for them does already exist. for sure it is not necessary but in the end it's a feature i would like to implement since it will make the patch much more practical.
2/ What are "scale length low E string" and "scale length high e string"? Are they the actual string lengths of the bass and treble strings?
This is the initial decision taken by the luthier: which scale lengths to use for the multiscale build. While anything that makes sense goes here luthiers will probably want to choose some common values, say 24.75" (like most Gibson guitars) or 25.5" (like a Fender Stratocaster)
P.S. I did the rotations at the points where the treble string intersects the virtual bridge and nut (blue lines), so rotation has no effect on its length.
P.P.S. In case it isn't obvious, rotation has no effect on string spacing either.
This is the kind of things i don't know cause i'm zero in maths and i usually have to try out and measure to know for sure :-) as i said my initial instinct would have been to rotate around the 'zero frets' center point simply because everything is built aroun d the X axis. If you rotate around the treble string (the high e string) would the distance of the upper fretboard edge to the x-axis be the same than from the lower fretboard edge to the x-axis ?
for running data through panels, thanks for the tip, i do this mainly to visualize the values without having to hover over the outputs, good to know i shouldn't patch them onward from the panel.
PS: For the height of the strings above the fretboard (the 'action'), it's not as complicated as it sounds and most of the time an experienced luthier or guitar tech will have no problem achieving whatever low action desired if the neck is straight and built properly and the frets level and dressed properly. there's a german company who's built a machine to do the 'perfect setup': the PLEK machine
i'm sorry it takes me much longer to digest and implement all this, i will post back when i've merged everything together but i think i have evrything so far
…
hit Commit.
I'm wondering how hard it would be to have an edit box which shows the
number the user could click inside of then type in a new number, then
hit enter. :)
2) How would I go about using one line from a table and assign each
field to a variable? Then, move a slider or something and use the values
from the next row?
background: I'm recreating elbows, Tees, and other fittings using
paramatric scripts, then baking and exporting them. Here's one source
table, http://www.wardfittings.com/Assets/PDFs/0902CatalogColorOld.pdf
page 5, the uniform elbows.
Current Setup: the attached ghx file. Create a point at 0,5,0 in a blank
document with units set to inches, then assign that point to the top
left 'Center Pnt' in the ghx file.
Current workflow:
a) Modify variables A, B, H, and Nominal Dia to match one line from the
table in the linked PDF file, page 5, table of regular elbows.
b) Select the 'Nodes' and 'Surfaces' with a drag box
c) Click 'Bake'
d) Switch to Rhino window, do the 'sellast' command.
e) Drag baked objects along Y axis so the center point is at 0,0,0
f) Run 'Join'
g) Run 'Cap'
h) set the 'node' points to a layer called 'nodes'
i) set the surface to a layer called 'fit-3d'.
j) select the surfaces and nodes
k) export selected
This elbow that I'm doing only has 12 rows, so doing it the above method
doesn't take THAT long. I'm also going to be doing a couple with larger
tables like the Tee on page 8, and in other spec files. As you can
imagine, entering in EACH value into a slider is a bit tedious.
I'd love to take the pdf table, run it through an OCR program to convert
to excel, modify the headers so the ghx script knows what they are, then
paste it into grasshopper, or save it and have grasshopper read it, and
I be able to move a slider or something to to select one line at a time.
Has anyone done something similar? ie: assigned one row in a table to a
predefined set of variables, each variable coming from one field in the row?
Thanks for taking the time to read this message. :)
I'm making a rhino script to do steps d-k, so that part will be much faster.
-Suthern…
’s mid-point and whose direction is perpendicular to that edge. The following images are a summary of how I’m currently doing this. Keep in mind that the shared edge is not always parallel with the x, y or z axis… in fact it usually isn’t.
This is the vector I'm trying to get...
This is my workflow:
1- Find centroids of surfaces...
2- Find mid point of the edge. The for each surface, create vector from mid point to centroid and also reverse the direction. Place a point at the end of each vector...
3-Test to see which of the two points for each surface is contained within each surface's boundary and select that point (this parsing is necessary in some cases depending on the shape of the surfaces)...
4-Here is the kicker. In cases where one or both surfaces are skewed, the centroid of that surface is not necessarily "perpendicular" to the mid point of the edges as evident here with surface B. So I create a plane (technically its a "frame") that is perpendicular to the edge...
5-I then pull both points to that plane...
6-From there its pretty straight forward as far as getting the required vector...
So is this the best way to do this. In particular I'm curious if there is an alternative to step 4, but really any comments are welcome.
Thanks,
cbass…