Karamba.
I am using your plug-in for normal forces evaluation in the transvere wires and spreaders of a sailboat. Mast is solved in another way, so I am not taking forces from Karamba in that case.
Basing on the forces value an adequate wire size (diameter) is choosen. Then masses of wires are being calculated. Loads (forces) on longitudinal wires are calculated without Karamba. The problem is when choosing transverse wires’ mass minimization as a criteria, the Octopus doesn’t get any results - is changing the sliders (genes) too fast for Karamba to calculate the forces (so Octopus gets only nulls):
When minimization of a e.g. longitudinal wires’ mass (calculated without Karamba) is taken as a criteria Octopus works fine.
Which suggests that the problem is in interaction of two plug-ins.
Any ideas how to avoid that problem?
Thanks,
M.
Below some screenshots of definition part with Karamba:
1675×807 200 K
image.png1680×789 398 KB
Despite the ‘orange warning’ the values are correct (double checked with other software).However I don't know why does it say that there is a part that can move freely without deformation,as the model looks like this:
image.png1239×343 55.5 KB
…
the data structure of the input.
I'll create a component that aims to write all the GH_Paths inside the input data structure into separate output parameters. I'll add a menu item to the component that allows users to synch the number of outputs with the current data.
Note that there are some bugs I found related to Undo here, but I'll attempt to fix those asap. The mechanisms employed in this example are correct.
Let's start with the Component class definition and the constructor:
Public Class GH_ExampleComponent_VarOutput
Inherits GH_Component
Public Sub New()
MyBase.New("Extract Paths", "ExPath", "Extract all the paths from a tree", "Sets", "Tree")
End Sub
End Class
Now, the RegisterXXXXParams methods:
Protected Overrides Sub RegisterInputParams(ByVal pManager As GH_Component.GH_InputParamManager)
pManager.Register_GenericParam("Tree", "T", "Data tree to examine", GH_ParamAccess.tree)
End Sub
Protected Overrides Sub RegisterOutputParams(ByVal pManager As GH_Component.GH_OutputParamManager)
'We'll add one output parameter, just to not have a jagged output.
pManager.Register_PathParam("Path 1", "1", "1st path in tree")
End Sub
SolveInstance() is somewhat special, but not very complicated:
Protected Overrides Sub SolveInstance(ByVal DA As IGH_DataAccess)
'We have only one input parameter and it is set to Tree,
'so SolveInstance will only be called once for every solution.
'We don't actually need the data inside the input, we're only interested in the paths.
'So we don't actually need to call DA.GetDataTree, we can just go in and extract the
'paths directly:
Dim paths As IList(Of GH_Path) = Params.Input(0).VolatileData.Paths
'Abort if there is no tree.
If (paths.Count = 0) Then Return
'Post a warning if the number of output parameters does not
'equal the number of paths in the tree.
If (paths.Count < Params.Output.Count) Then
AddRuntimeMessage(GH_RuntimeMessageLevel.Warning, "There are more outputs than paths in the tree.")
ElseIf (paths.Count > Params.Output.Count) Then
AddRuntimeMessage(GH_RuntimeMessageLevel.Warning, "There are fewer outputs than paths in the tree.")
End If
'Iterate over all paths and assign to output parameters.
For i As Int32 = 0 To Math.Min(Params.Output.Count, paths.Count) - 1
DA.SetData(i, paths(i))
Next
End Sub
Adding a menu item to the component menu is relatively straightforward, however handling the menu command requires a fair bit of logic:
Protected Overrides Sub Menu_AppendCustomComponentItems(ByVal iMenu As System.Windows.Forms.ToolStripDropDown)
'Add a single item to the component menu.
Menu_AppendGenericMenuItem(iMenu, "Synch outputs", AddressOf Menu_SynchOutputClicked)
End Sub
Private Sub Menu_SynchOutputClicked(ByVal sender As Object, ByVal e As EventArgs)
'Here we have to synch the number of output parameters with the number
'of paths in the volatile data tree in the input parameter.
'This requires a few steps:
'1. Determine whether something needs to happen at all.
'2. Record an undo event.
'3. Remove excess outputs or add missing outputs.
Dim paths As IList(Of GH_Path) = Params.Input(0).VolatileData.Paths
If (paths.Count = Params.Output.Count) Then Return 'yay, nothing needs to be done.
'Something needs to be done, record an undo state.
RecordUndoEvent("Synch output")
'We either have too few or too many outputs, determine which is the case.
If (paths.Count > Params.Output.Count) Then
'Add the missing outputs
For i As Int32 = Params.Output.Count + 1 To paths.Count
Dim param As New Grasshopper.Kernel.Parameters.Param_GenericObject()
param.Name = "Path " & i.ToString()
param.NickName = i.ToString()
If (i.ToString.EndsWith("1")) Then
param.Description = i.ToString() & "st path in tree"
ElseIf (i.ToString.EndsWith("2")) Then
param.Description = i.ToString() & "nd path in tree"
ElseIf (i.ToString.EndsWith("3")) Then
param.Description = i.ToString() & "rd path in tree"
Else
param.Description = i.ToString() & "th path in tree"
End If
Params.RegisterOutputParam(param)
Next
Else
'Remove excessive outputs
Do
If (Params.Output.Count <= paths.Count) Then Exit Do
Dim param As IGH_Param = Params.Output(Params.Output.Count - 1)
Params.UnregisterOutputParameter(param)
Loop
End If
Params.OnParametersChanged()
ExpireSolution(True)
End Sub
Finally, we must make sure that the component properly (de)serializes. This means we have to override the Write and Read methods and add additional information to the GHX archive:
Public Overrides Function Write(ByVal writer As GH_IO.Serialization.GH_IWriter) As Boolean
'We must make sure that the number of output parameters is correctly stored.
'We'll use a special function on the GH_ComponentParamServer to accompish this
'without too much sweat.
Params.WriteParameterTypeData(writer)
Return MyBase.Write(writer)
End Function
Public Overrides Function Read(ByVal reader As GH_IO.Serialization.GH_IReader) As Boolean
'Very important, we must make sure all parameters exist before we
'start with the main deserialization.
Params.Clear()
Params.ReadParameterTypeData(reader)
Return MyBase.Read(reader)
End Function
I attached a VB file that contains the code outlined above.
--
David Rutten
david@mcneel.com
Seattle, WA…
Added by David Rutten at 11:43pm on October 27, 2010
isseminated at the firms I've worked at:
Always write your scripts as though someone else is going to have to use and debug them without any instruction from you. This is kind of an overall governing principle that drives a lot of the other best practices.
Structure your definitions left to right. This way it is clear what is dependent on what, what executes in what order, and makes it easy to use the "Moses" tool (alt-click and drag on the canvas to spread components apart) to insert intermediate functionality to an already-existing definition.
For a given functional group (a set of components that does a well-defined thing) keep all the data going in to the group as labeled parameters on the left, and everything going out of the group as labeled parameters on the right. This is the intent of my "Best Practicizer" tool in Metahopper (now a menu item instead of a component). In essence, you're treating each group as though it's about to be clustered - you've defined what it does, what its inputs are, and what its outputs are. This makes troubleshooting much easier - if something is going wrong, you can easily isolate which group is causing the trouble by looking at inputs and outputs.3b. If you're grabbing some value or data (e.g. "STEP COUNT") many times from elsewhere in the definition, don't make a bunch of long wires that connect all the way back to the original source - grab that data into ONE labeled parameter and then connect all your inputs that need it to that - makes for one long wire instead of 20.
Annotate, annotate, annotate. Label your params (and if you're in icon mode, switch them manually to text). Label your groups. Use scribbles to mark larger regions of functionality. Use panels for "instructions" wherever it might not be clear how someone is supposed to use your tools.
Avoid "wireless" (Hidden Wires) connections. If you MUST use them, make sure you create params at both ends with matching names so it's clear what the data represents and where it comes from.
Cluster where possible. It's extremely helpful to isolate functional groups into clusters - it makes debugging faster and easier, since you don't have to wait for the whole definition to recompute when making small edits to the inside of a cluster, and it sets you up well to create code that can be re-used later on. However, don't take whole definitions and cluster them. As a rule of thumb, if a cluster has more than ~10 inputs, it should probably be broken into multiple clusters. There is a slight performance impact when clustering, because unlike an un-clustered group of components, which only executes the parts of the definition where something has changed, any time ANY input to a cluster changes, the WHOLE cluster re-computes. Because of this, a cluster shouldn't generally wrap any groups of components that are not related / don't connect with each other.
Color code your groups. Many firms develop a standard around group coloring so that it's easy to understand what parts of a definition are doing what kind of task. For instance, at Woods Bagot where I work, we have different colors for component groups that highlight inputs, outputs, rhino references, baking, and visualization. You may find that a different set is useful to you, but having a consistent standard can improve legibility. That's my 2c. At the end of the day, everyone works a little bit differently, and that's unavoidable (and not even a bad thing!) As long as you keep #1 in mind, all the rest will follow.
…
you will need to deal with all of the curves that intersect the boundry curve, but you will also need to sort through all of the circles inside because the planar surface algorithm won't sort those out for you. The good news is that because you are using circles and linear segments, you can use "pure" geometry equations for some of these intersections instead of relying on NURBS curve "physical" intersections. In the end this means faster and also "more" reliable intersections (especially with the circles).
Method 1: Dealing with everything as a phyisical curve...
First things first, i guess the "easiest" way to do this would be to translate everything into an OnCurve derived class, and then use the IntersectCurve method to find the intersections. You will need to sort through the resulting ArrayON_XEVENT to find the parameter of each intersection. There should always be 2 intersections, and you're always going to be interested in the intersections of the circle not the boundry curve.
To trim the curves, you'll want to use the Split method along with one of the parameters on the curve that you retrieved from the intersection. The only issue is that the split method gets a bit complicated when using it on closed curves. You could either split at both parameters that you retrieved from the intersection results, then sort through the 3 resulting curves to join the two that you need. Or move the start point of the circle to where one of the intersection points happened, translate the other intersection point to the new curve parameter (ie the parameter will be a different number, but it will be physically in the same place), then split with that new curve parameter.
Method 2: Try and work with the circles as circles
Because you can tell if a circle intersects something by seing if the distance to its center point is less than the radius of the circle, this might be a quicker way to go. If you have the boundry curve as an OnCurve derived class, then you can use the GetClosestPoint method and use all of the center points for each of the circles. The nice thing is that after the 3Dpoint in, and the parameter on the curve that you'll get out, you have the option of supplying a maximum distance. If you do supply that value (use the radius of the circles), then you'll only get a result when the distance is less than or equal to that value. In which case there will be an intersection.
To go even further, you can treat the segments of the boundry curve each as a line, and find the closest point/distance to that. That's maybe more complex than your looking to go, but speed wise, it might just be worth it. Take a look at the following link for more code/discussion on the subject.
http://www.codeguru.com/forum/showthread.php?t=194400
Part 2: Circle-Circle intersections
If you're going to want to make a planar surface out of those circes and the boundry curve, then you'll need to resolve all of the intersections that you have there. Again this is probably something that would be best taken care of by doing some distance tests between the center points of all the circles and seeing if that distance is less than the radius your using. After you've found circles that intersect, you can be try intersecting the curves using the same method mentioned above, or even manually generating the intersection with some trig, but ultimately creating a final result might take a bit of work, especially where you have more than two circles intersecting. The "lazy" way out of this is what's used by the curve boolean command, which is to take each individual curve, make a planar surface from that individual curve, and use standard Rhino booleans to get the result. Luckily you're looking for the union of all those areas, which will be the easiest to create and deal with. After you create the planar surface of each one (RhUtil.RhinoMakePlanarBreps), you can use either RhUtil.RhinoBooleanUnion or the more specialized version, RhUtil.RhPlanarRegionUnion. Note that RhPlanarRegionUnion only takes 2 breps at a time and needs the plane of the intersection.…
occur more than once in the same list, and different elements with identical values can occur more than once. Also, a list may contain lack of elements, referred to as "nulls".
Sets. Strictly speaking a Set is a mathematical construct which adheres to a strict collection of rules and limitations. Basically, a Set is the same as a List, with the exception that it cannot contain the same element more than once, or indeed two or more different elements with the same values. You see, in mathematics there is no difference between a value and an instance of that value, they are the same thing. In programming however it is possible to store the number 7 in more than one spot in the RAM. Grasshopper does not enforce this rule very strongly though, you can use a lot of Set components on lists that have multiple occurrences of the same value. The big difference between Lists and Sets in Grasshopper is that Sets are only defined for simple data types that have trivial equality comparisons. Basically: booleans, integers, numbers, complex numbers, strings, points, vectors, colours and intervals. Lists can contain all kinds of data.
Strings. Strings are text. There's nothing more to it. I don't know why early programmers chose to call them strings, but I suppose it's a better description of the memory representation of them. Strings are essentially sequences of individual characters.
Trees. Trees are the way all data is stored in Grasshopper. Even when you only have a single item, it will still be stored in a tree. A tree is a sorted collection of lists, where each list is identified by a path. A specific path can only occur once in a tree, when you merge two trees together, lists with identical paths are appended to each other. Trees are an attempt to losslessly represent not just the data itself, but also the history of that data. Imagine you have 4 curves {A,B,C,D} and you divide each into 3 points {X,Y,Z}. Then, for each of those points you create a new line segment {X',Y',Z'} and then divide each of those line segments again into 5 points each {K,L,M,N,O}. The way data is stored in trees, it should be possible to figure out whether a point M belongs to X' or to Z', and whether that X' or Z' came from A, B, C or D. This is why paths are often quite long after a while, because they encode a lot of history.
Paths. A Path is nothing more than a list of integers. It's denoted using curly brackets and semi-colons: {A;B;...;Z}. A Path should never be empty {} or have negative integers {0;-1}, but it is certainly possible to create a path like this and it probably won't even crash Grasshopper. Paths are 'grown' by components that (potentially) create more than one output value for a single input value. For example Divide Curve. It creates N points for every single input curve. In cases like this a new integer is appended to the end of the path.
In the next release the Path logic in Grasshopper is somewhat different. I fixed a number of obscure bugs (hopefully without introducing new fresh bugs) and special cased certain operations to somewhat reduce the speed at which paths grow. This may well break files that rely on a specific tree layout, but I hope the temporary sacrifice will be worth the long-term benefits.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
http://www.pilkington.com/) dominates the planar market. Charges "around" 1K Euros per m2 for a "plain" system. Personally in bespoke projects I design my own stuff but due to economies of scale ... they cost a bit more (but they look far more sexier, he he) . On the other hand only in a bespoke project I could dare to suggest such a solution (for a large scale building we are talking lots and lots of dollars).
3. Several scales below (aesthetics) you can find static alu systems (either structural or semi-structural):
Or hinged systems (either structural or semi-structural) capable to adapt in contemporary double curvature facades/roofs/envelopes/cats/dogs etc etc ... pioneered worldwide many years ago by my best friend Stefanos Tampakakis (everybody in UAE knows that genius man: http://www.alustet.gr/company.html):
4. With the exception of some paranoid things that Guru Stefanos does for Zaha these days we are talking about planar "facets" (obviously a triangle is such a planar facet). The current trend is: the more edges the better (humans excel in vanity matters). But achieving planarity in, say, quads (like yours) it adds another "restriction" on what you are doing. Until recently Evolute Tools Pro was the only answer. But right now ... well let's say that in short time you'll be greatly surprised by some WOW things in this Noble Forum, he he.
5. MERO (and obviously custom systems) can adapt (at almost no extra charge) in anything imaginable. But in a bespoke building ... well.. you know ultra rich people: they don't want MERO anymore since "everybody" does MERO solutions. Vanity, what else?
6. Smart Glass would become a must in the years to come: Eco-Architecture MUST dominate everything you do. On the other hand spending millions to do some extra WOW stuff (Vanity) ... it doesn't look to me very Eco-Friendly/Whatever ... but let's pretend so, he he.
7. I'm Architect but a bit different from the norm: for instance I smoke cigars (highly politically incorrect stuff) I always talk openly (ditto) and I ride lethal bikes (ditto).
may the Force (as always the Dark Option) be with you: go out there and kill them all.
best, Peter
…
Ladybug + Honeybee:
(Follow steps 0-4 for basic functionality and 0-9 for full functionality)
0. If you have an old version of LB+HB, download the file here (https://app.box.com/s/ds96em9l6stxpcw8kgtf)
and open it in Grasshopper to remove your old Ladybug and Honeybee version.
1. Make sure that you have a working copy of both Rhino and Grasshopper installed.
2. Open Rhino and type "Grasshopper" into the command line (without quotations). Wait for grasshopper to load.
3. Install GHPython 0.6.0.3 by downloading the file at this link (http://www.food4rhino.com/project/ghpython?ufh) and
drag the .gha file onto the Grasshopper canvas.
4. Select and drag all of the userObject files (downloaded with this instructions file) onto your Grasshopper canvas.
You should see Ladybug and Honeybee appear as tabs on the grasshopper tool bar.
(If you are reading this instruction on github you can download them from http://www.food4rhino.com/project/ladybug-honeybee)
5. Restart Rhino and Grasshopper. You now have a fully-functioning Ladybug. For Honeybee, continue to the following:
6. Install Radiance to C:\Radiance by downloading it from this link (https://github.com/NREL/Radiance/releases/download/4.2.2/radiance-4.2.2-win32.exe) and running the exe.
7. Install Daysim 4.0 for Windows to C:\DAYSIM by downloading it at this link (http://daysim.ning.com/page/download) and running the exe.
8. Install EnergyPlus 8.1 to C:\EnergyPlusV8-1-0 by going to the DOE website (http://apps1.eere.energy.gov/buildings/energyplus/energyplus_download.cfm), making an account, going to "download older
versions of EnergyPlus, selecting 8.1 and running the exe.
9. Copy falsecolor2.exe (http://pyrat.googlecode.com/files/falsecolor2.exe) and evalglare.exe (http://www.ise.fraunhofer.de/en/downloads-englisch/software/evalglare_windows.zip/at_download/file) to C:\Radiance\bin
10. You now have a fully-working version of Ladybug + Honeybee. Get started visualizing weather data with these video tutorials (https://www.youtube.com/playlist?list=PLruLh1AdY-Sj_XGz3kzHUoWmpWDXNep1O).
After I've done all the above I followed this video
https://vimeo.com/96155674
And everything works well.
…
ake a network of lines (i.e. a graph) and make a Plankton Mesh, from which you can use Cytoskeleton to make a solid mesh (and then smooth it with Weaverbird).
Works with ngons (polygons with 3 or more sides). Other examples I found only worked with tris and quads.
Works on open or closed surfaces
While these examples start with a surface, you could start with a network of lines and make a patch surface
This is meant for 2D networks/surfaces. I haven't attempted filling a 3D volume. My guess is this wouldn't work as it would require a non-manifold mesh that Plankton wouldn't handle.
Note similar results could be achieved with the following:
TSplines
MeshDual (dual of a tri mesh, not as much freedom/control)
Working backwards, here is the GhPython script from Will Pearson that builds a Plankton Mesh from vertices and faces. The vertices are a list of 3D coordinates, the faces are a tree a lists, with each list containing the indices of vertices that form a closed loop. From Will, "Plankton only handles manifold meshes, i.e. meshes which have a front and a back. This orientation is determined by the "right-hand rule" i.e. if the vertices of a face are ordered counter-clockwise then the face normal will be out of the page/screen."
# V: list of Point3d # F: tree of int
import Grasshopper appdata = Grasshopper.Folders.DefaultAssemblyFolder
import clr clr.AddReferenceToFileAndPath(appdata + "Plankton.dll")
import Plankton
pmesh = Plankton.PlanktonMesh()
for pt in V: pmesh.Vertices.Add(pt.X, pt.Y, pt.Z)
for face in F.Branches: face = list(face)[:-1] pmesh.Faces.AddFace(face)
These vertices and faces are precisely the output from Starling. Starling takes in a list of Polylines which form the (properly oriented) face loops.
The polyline face loops can be generated...
Directly from Panels on a surface using LunchBox
Using any network of lines/curves on a surface (curves will need to be converted to polylines before Starling)
The latter was achieved using the Surface Split command, then converting the face edges (converted to curves) into polyline loops to represent faces.
…
nted" in space (at instance definition creation phase): indicates the obvious fact that if garbage in > garbage out (try it).
2. Load the GH thing. Task for you: Using Named Views locate the points of interest as described further and make a suitable view. That way you can navigate rather easily around (hope dies last).
3. Your attractors are controlled from here:
The slider in blue picks some attractor to play with. You can use this while the K2 is running.
4. Don't change anything here (think of it as a black box: who cares how it works? nobody actually):
5. Enable the other "black box": job done your real-life stuff is placed:
6. Enable the solver: your "real-life" things start to bounce around:
7. Go there are play with the slider. A different attractor yields an other solution:
8. With real-life things in place if you disable the C# ... they are instantly deleted and you are back in lines/points and the likes:
9. Either with instance definitions or Lines/points change ... er ... hmm ... these "simple" parameters and discover the truth out there:
10. Since these are a "few" and they affect the simulation with a variety of ways ... we need a "self calibrating" system: some mini big Brother that does the job for us. Kinda like applying safely the brakes when it rains (I hate ABS mind).
NOTE: the rod with springs requires some additional code ,more (that deals with NESTED instance definitions) in order to (b) bounce as a whole and at the same time (b) elongates or shrinks a bit.
More soon.
…