cript is quite large for a lack of better understanding of the program.
The idea is that we created a grid as you can see on the script, in this grid we then place pegs, we find the center and then create a radius around the pegs for the robot to not hit the peg but pass around them, we created a divide component to divide the circle in a maximum of 6 points in order to alter them and edit them if the thread is getting to close to the peg, here is were we encounter the first issue. If we change the number of divisions less or greater than 3 ( the default ) we have to weave everything again and add the extra points.
First Question, Is there a way to tell the component to always weave from 0 to the last point on its list independent of how many points it had? Meaning it goes 0 then 1 then 2 then 3 if 4 points, or 0-1-2-3-4-5 if it has 5 points.
The second question is if there is a way for the weave to always go when in its own list from 0 to max, but if its trying to weave with another list then tell it to weave between 0 and 2 but the closes 0&2 always so it does not try to cross the pattern.
----------------------
A last question but not as important, we created 4 pegs and made the script for them but lets say we wanted to add 1, 2 or 3 pegs more, is there a way to make the script more optimize as to not have to go back and re make every component/weave too include the extra pegs.
Uploaded are the 3D File ( Excluding the Robotic Files/Components ) and the GH File, I will try to upload a couple of drawings if nessesary.
Current Issues:
We used a Circle to create a radius around the pegs, and then depending on the division of this circle we then weave through it and across to create the weave polyline. This points are then sent as planes as the robot only understands planes for it to follow. The issue is that if we increase the number of divisions it breaks the weave pattern.
It seems that we weave is only 2Dinensional for some reason and it does not goes to the next level once it completed the level below, meaning its only closed loops instead of a single loop.
If we add more pegs than the 4 original, it breaks the pattern and we have to remake modules for every single extra peg and then remake the weave, Is there a way to make this faster/more elegant?
Our current trial is a simple stack weave, later on we would like to try bending the pegs in different ways, heights to make the weave more interesting but for now we are trying to understand the more optimize way to make the first step stacking work and then jump to a more complicated form.
------------
I place a Create Geometry Section in the script, the idea is that one could Move/Alter the Pegs and create different shapes and this would update/optimize to the best weave, but as of now all it does is it wither breaks the weave, or crosses in the center.
Changing the Divisions of the Circle breaks the weave, as of now there are 3 Divisions and the weave goes 0-1-2, but if you increase it it would not go from 0-Last Digit, but try to find 0-1-2 and weave incorrectly.
Any help is appreciated. And if there is a better way to do this, Please do not hesitate to edit the script, I will then follow the changes to understand them.
…
Added by Juan Alvarez at 11:28am on November 16, 2015
u can still find some wonky behaviour in GH related to datatrees. My experience is that new users quite quickly get the hang of it once they learn that a tree is in fact not a tree but in the first place set of lists, where the path shows how the pieces of data used to be grouped.
Branch Count checking A component has multiple tree inputs, but has different amount of branches, each having branch count > 2. (While I understand the logic of combining multiple trees, I've not once encounted once that combining a component with e.g. an input of 2 branches and an input of 4 branches to give any kind of sensible output.
Desired behaviour: If a component has branches (each being > 2 path count), the component should throw a warning. ("Strict branches behaviour?). For example: take an offset component, with 6 branches of curves and 5 branches of offsets. It is extremely likely that this is the result of an error earlier in the definition. This works however without a problem - the last branch is repeated again, and it's later on quite hard to discover something went wrong.
Checking branch Count The most important numeric is the amount of branches, and the amount of items in the tree. It's desired that the hovers show the amount of data and the amount of branches.
Desired behaviour
Trees with paths of different rank Trees that contain {0;0} and {0} and {0;0;1} is usually a sign of trouble of not well merged trees, faulty C# components, or just nasty coding habits.
Trim as undo graft instead of flatten Having the trim in the context menu would provide an easy way to undo a graft. Right now the easiest way for many people is to flatten it, and then start all over again - while just getting rid of the last index keeps the underlying history and makes it easier to write reuseable pieces of code when you prepend datatrees to it.
Component to get branch by index, not by path Would be great. Suppose you have a grid of points, grouped by row. It would help to show: "look, this is in the first path, it's called {0;0;1}, it's got 10 points, these points are the first row".
Analogue to using list item to show what is the first point, second point, and so on.
Semantic path names (maybe far fetched) But what if we can add a short name of each method that was executed to the path list, so it can show:
{Slider 0; Series 0; Point 0}{Slider 0; Series 0; Point 1}
{Slider 0; Series 0; Point 2}
{Slider 0; Series 0; Point 3}
{Slider 0; Series 1; Point 0}
{Slider 0; Series 1; Point 1}
{Slider 0; Series 1; Point 2}
{Slider 0; Series 1; Point 3}
Make the input/data matching inside components explicit Can we make it even more obvious that a component is not a black box that's executed once, but in fact an iteration machine that tries to make sense of the inputs that's fed to this box?
Show data combination. How data input A relates to data input B and data input C, is currently very implict and is just plain hard to learn., and required the ability to be able to relate the output back to the input. If we can textually or even graphically show what data matching occured inside a component, it would greatly help the understanding (and debugging) of "what's going on here in this component"
A verbose explanation of the data matching in component A
Iteration one: - Geometry: We take the data item from Branch 0, Position 0: (Point 0,0,0) - Motion: We take the data item from Branch 0, Position 0: (Vector 0,0,0)
Iteration two:
- Geometry: We take the data item from Branch 0, Position 0: (Point 0,0,0)
- Motion: We take the data item from Branch 0, Position 1: (Vector 10,0,0)
Iteration three:
- Geometry: We take the data item from Branch 0, Position 0: (Point 0,0,0)
- Motion: We take the data item from Branch 0, Position 1: (Vector 20,0,0)
etc.
A verbose explanation of the data matching in component B
Iteration one: - Geometry: We take the data item from Branch 0, Position 0: (Point 0,0,0) - Motion: We take the data item from Branch 0, Position 0: (Vector 0,0,0)
..
Iteration seven:
- Geometry: We take the data item from Branch 0, Position 0: (Point 0,0,0)
- Motion: We take the data item from Branch 7, Position 0: (Vector 0,70,0)
..
Iteration 27:
- Geometry: We take the data item from Branch 0, Position 7: (Point 80,0,0)
- Motion: We take the data item from Branch 2, Position 0: (Vector 0,20,0)
…
ng is deciding how and where to store your data. If you're writing textual code using any one of a huge number of programming languages there are a lot of different options, each with its own benefits and drawbacks. Sometimes you just need to store a single data point. At other times you may need a list of exactly one hundred data points. At other times still circumstances may demand a list of a variable number of data points.
In programming jargon, lists and arrays are typically used to store an ordered collection of data points, where each item is directly accessible. Bags and hash sets are examples of unordered data storage. These storage mechanisms do not have a concept of which data comes first and which next, but they are much better at searching the data set for specific values. Stacks and queues are ordered data structures where only the youngest or oldest data points are accessible respectively. These are popular structures for code designed to create and execute schedules. Linked lists are chains of consecutive data points, where each point knows only about its direct neighbours. As a result, it's a lot of work to find the one-millionth point in a linked list, but it's incredibly efficient to insert or remove points from the middle of the chain. Dictionaries store data in the form of key-value pairs, allowing one to index complicated data points using simple lookup codes.
The above is a just a small sampling of popular data storage mechanisms, there are many, many others. From multidimensional arrays to SQL databases. From readonly collections to concurrent k-dTrees. It takes a fair amount of knowledge and practice to be able to navigate this bewildering sea of options and pick the best suited storage mechanism for any particular problem. We did not wish to confront our users with this plethora of programmatic principles, and instead decided to offer only a single data storage mechanism.*
Data storage in Grasshopper
In order to see what mechanism would be optimal for Grasshopper, it is necessary to first list the different possible ways in which components may wish to access and store data, and also how families of data points flow through a Grasshopper network, often acquiring more complexity over time.
A lot of components operate on individual values and also output individual values as results. This is the simplest category, let's call it 1:1 (pronounced as "one to one", indicating a mapping from single inputs to single outputs). Two examples of 1:1 components are Subtraction and Construct Point. Subtraction takes two arguments on the left (A and B), and outputs the difference (A-B) to the right. Even when the component is called upon to calculate the difference between two collections of 12 million values each, at any one time it only cares about three values; A, B and the difference between the two. Similarly, Construct Point takes three separate numbers as input arguments and combines them to form a single xyz point.
Another common category of components create lists of data from single input values. We'll refer to these components as 1:N. Range and Divide Curve are oft used examples in this category. Range takes a single numeric domain and a single integer, but it outputs a list of numbers that divide the domain into the specified number of steps. Similarly, Divide Curve requires a single curve and a division count, but it outputs several lists of data, where the length of each list is a function of the division count.
The opposite behaviour also occurs. Common N:1 components are Polyline and Loft, both of which consume a list of points and curves respectively, yet output only a single curve or surface.
Lastly (in the list category), N:N components are also available. A fair number of components operate on lists of data and also output lists of data. Sort and Reverse List are examples of N:N components you will almost certainly encounter when using Grasshopper. It is true that N:N components mostly fall into the data management category, in the sense that they are mostly employed to change the way data is stored, rather than to create entirely new data, but they are common and important nonetheless.
A rare few components are even more complex than 1:N, N:1, or N:N, in that they are not content to operate on or output single lists of data points. The Divide Surface and Square Grid components want to output not just lists of points, but several lists of points, each of which represents a single row or column in a grid. We can refer to these components as 1:N' or N':1 or N:N' or ... depending on how the inputs and outputs are defined.
The above listing of data mapping categories encapsulate all components that ship with Grasshopper, though they do not necessarily minister to all imaginable mappings. However in the spirit of getting on with the software it was decided that a data structure that could handle individual values, lists of values, and lists of lists of values would solve at least 99% of the then existing problems and was thus considered to be a 'good thing'.
Data storage as the outcome of a process
If the problems of 1:N' mappings only occurred in those few components to do with grids, it would probably not warrant support for lists-of-lists in the core data structure. However, 1:N' or N:N' mappings can be the result of the concatenation of two or more 1:N components. Consider the following case: A collection of three polysurfaces (a box, a capped cylinder, and a triangular prism) is imported from Rhino into Grasshopper. The shapes are all exploded into their separate faces, resulting in 6 faces for the box, 3 for the cylinder, and 5 for the prism. Across each face, a collection of isocurves is drawn, resembling a hatching. Ultimately, each isocurve is divided into equally spaced points.
This is not an unreasonably elaborate case, but it already shows how shockingly quickly layers of complexity are introduced into the data as it flows from the left to the right side of the network.
It's no good ending up with a single huge list containing all the points. The data structure we use must be detailed enough to allow us to select from it any logical subset. This means that the ultimate data structure must contain a record of all the mappings that were applied from start to finish. It must be possible to select all the points that are associated with the second polysurface, but not the first or third. It must also be possible to select all points that are associated with the first face of each polysurface, but not any subsequent faces. Or a selection which includes only the fourth point of each division and no others.
The only way such selection sets can be defined, is if the data structure contains a record of the "history" of each data point. I.e. for every point we must be able to figure out which original shape it came from (the cube, the cylinder or the prism), which of the exploded faces it is associated with, which isocurve on that face was involved and the index of the point within the curve division family.
A flexible mechanism for variable history records.
The storage constraints mentioned so far (to wit, the requirement of storing individual values, lists of values, and lists of lists of values), combined with the relational constraints (to wit, the ability to measure the relatedness of various lists within the entire collection) lead us to Data Trees. The data structure we chose is certainly not the only imaginable solution to this problem, and due to its terse notation can appear fairly obtuse to the untrained eye. However since data trees only employ non-negative integers to identify both lists and items within lists, the structure is very amenable to simple arithmetic operations, which makes the structure very pliable from an algorithmic point of view.
A data tree is an ordered collection of lists. Each list is associated with a path, which serves as the identifier of that list. This means that two lists in the same tree cannot have the same path. A path is a collection of one or more non-negative integers. Path notation employs curly brackets and semi-colons as separators. The simplest path contains only the number zero and is written as: {0}. More complicated paths containing more elements are written as: {2;4;6}. Just as a path identifies a list within the tree, an index identifies a data point within a list. An index is always a single, non-negative integer. Indices are written inside square brackets and appended to path notation, in order to fully identify a single piece of data within an entire data tree: {2,4,6}[10].
Since both path elements and indices are zero-based (we start counting at zero, not one), there is a slight disconnect between the ordinality and the cardinality of numbers within data trees. The first element equals index 0, the second element can be found at index 1, the third element maps to index 2, and so on and so forth. This means that the "Eleventh point of the seventh isocurve of the fifth face of the third polysurface" will be written as {2;4;6}[10]. The first path element corresponds with the oldest mapping that occurred within the file, and each subsequent element represents a more recent operation. In this sense the path elements can be likened to taxonomic identifiers. The species {Animalia;Mammalia;Hominidea;Homo} and {Animalia;Mammalia;Hominidea;Pan} are more closely related to each other than to {Animalia;Mammalia; Cervidea;Rangifer}** because they share more codes at the start of their classification. Similarly, the paths {2;4;4} and {2;4;6} are more closely related to each other than they are to {2;3;5}.
The messy reality of data trees.
Although you may agree with me that in theory the data tree approach is solid, you may still get frustrated at the rate at which data trees grow more complex. Often Grasshopper will choose to add additional elements to the paths in a tree where none in fact is needed, resulting in paths that all share a lot of zeroes in certain places. For example a data tree might contain the paths:
{0;0;0;0;0}
{0;0;0;0;1}
{0;0;0;0;2}
{0;0;0;0;3}
{0;0;1;0;0}
{0;0;1;0;1}
{0;0;1;0;2}
{0;0;1;0;3}
instead of the far more economical:
{0;0}
{0;1}
{0;2}
{0;3}
{1;0}
{1;1}
{1;2}
{1;3}
The reason all these zeroes are added is because we value consistency over economics. It doesn't matter whether a component actually outputs more than one list, if the component belongs to the 1:N, 1:N', or N:N' groups, it will always add an extra integer to all the paths, because some day in the future, when the inputs change, it may need that extra integer to keep its lists untangled. We feel it's bad behaviour for the topology of a data tree to be subject to the topical values in that tree. Any component which relies on a specific topology will no longer work when that topology changes, and that should happen as seldom as possible.
Conclusion
Although data trees can be difficult to work with and probably cause more confusion than any other part of Grasshopper, they seem to work well in the majority of cases and we haven't been able to come up with a better solution. That's not to say we never will, but data trees are here to stay for the foreseeable future.
* This is not something we hit on immediately. The very first versions of Grasshopper only allowed for the storage of a single data point per parameter, making operations like [Loft] or [Divide Curve] impossible. Later versions allowed for a single list per parameter, which was still insufficient for all but the most simple algorithms.
** I'm skipping a lot of taxonometric classifications here to keep it simple.…
Added by David Rutten at 2:22pm on January 20, 2015
aph relaxation in 3D and more). There is much more already in our GitHub repos and more to be added. For getting an idea of our future direction check this lecture out. For getting a better understanding of graphs and graph theory watch this lecture and this lecture on a gamified spatial configuration process. Stay tuned for more and do not hesitate to post Python questions in the meantime.
ps. If you are having installation problems, please check the remedy suggested below:
Comment by Iman Sheikhansari on August 26, 2019 at 8:33amDelete Comment
HiIf you are encountering a problem with rhino 6 versions don't worryFollow these steps.1. Download SYNTACTIC from https://sites.google.com/site/pirouznourian/syntactic-design2. Install it and go to the installation folder, Drag & drop SYNTACTIC(green one) over your grasshopper canvas.3. Close your rhino and reopen it. 4. Type GrasshopperDeveloperSettings5. Tick the Memory load *.GHA assemblies using COFF byte arrays option6. Run grasshopper and enjoy plugin
…
able all the components from that group.I know it's slowing down a lot, but the rhino performance is really poor on layouts. In Rhino 6 WIP it's a lot better though.
For the issue with different amount of drill holes i made an example script, how i would go for a solution to this. It's just a suggestion.
1) Do a little script that catches those holes and bake them to a separate layer.In my example i just generated them with GH.
2) Use RhinoCount (is installed with FabTools) to name the curves in Rhino by clicking one after the other. But first diable the layers, with the other geometry, so you don't accidentally click on geometry which you don't want to count.
You have 2 counters 1 for the part the second for the holes on each object. Increment the object counter if you have counted all holes of 1 object. By clicking on each hole the counter increments all by itself. Take a look at this command!
1 Click creates 1 Dot and renames the Rhino object. You can turn on/off all specific features of RhinoCount with the checkboxes. (see settings above)
And....this should be the result after some clicks:
3) If counted, you can reference the counted geometry again to GH with the counting as Datatree. (See attached GH File).
Then estimate the maximum amount of holes on one object in your drawing.Create a template with the amount of detail views and do the process from the layout tutorial again. For all objects with less holes you will have to delete the detail view which didn't have a target point or you do a sort of grouping for the hole centers and estimate the center of that group. You can be creative ;-)
I hope this helps. Good Work,
FF…
Added by Florian Frank at 7:49am on January 21, 2016
r nodes).
2. The 4th "liquid node" mode is (obviously) related with that "temperamental" ExoW thingy: due to that I've set up the related output on a per node basis > first exploit what's possible with Exo (and adjust the variables accordingly) and then ... fire and forget.Not all topologies yield return something worth looking mind:
3. The other modes are straight stuff (always doable)... so all nodes are created at once.
4. Load Rhino file first for the demo test data.
5. I've reworked the functions by removing LINQ and other weird stuff ... in order to allow you to follow what's happening with the most "palatable" way. This means that several portions of the code are ... er ... a bit stone age, he he.
6. I strongly recommend the modular node design: simpler, faster and always doable (note that protrusions are the other way round allowing to use hollow tube struts ... instead of struts + some insert adapter)
best, Peter…
ow the steps of the successful run when step 1.2 is bypassed (note that the and OpenFOAM session is open in the background while running the Butterfly demo file):
1. create wind tunnel, and use different parameters of (4,4) for _globalRefLevel_ as suggested by Theodoro in this post
2. run blockMesh:
3. run snappyHexMesh:
4. run checkMesh:
5. connect the case from checkMesh to simpleFOAM and run the simulation:
6. the simulation converged at 1865 iteration, but the results visualization part has some problem:
7. so I revised this part according to suggestions from Hagit:
8. and the results can be visualized for P and U values:
The GH file used for the successful run shown above is attached here.
Now, the following is the error I got when the case from the update fvScheme component is used for simpleFOAM simulation:
the warning message on the simpleFOAM component is:
1. Solution exception: --> OpenFOAM command Failed!#0 Foam::error::printStack(Foam::Ostream&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #1 Foam::sigFpe::sigHandler(int) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #2 ? in "/lib64/libc.so.6" #3 double Foam::sumProd<double>(Foam::UList<double> const&, Foam::UList<double> const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #4 Foam::PCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #5 Foam::GAMGSolver::solveCoarsestLevel(Foam::Field<double>&, Foam::Field<double> const&) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #6 Foam::GAMGSolver::Vcycle(Foam::PtrList<Foam::lduMatrix::smoother> const&, Foam::Field<double>&, Foam::Field<double> const&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::Field<double>&, Foam::PtrList<Foam::Field<double> >&, Foam::PtrList<Foam::Field<double> >&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #7 Foam::GAMGSolver::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so" #8 Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so" #9 Foam::fvMatrix<double>::solve(Foam::dictionary const&) in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam" #10 Foam::fvMatrix<double>::solve() in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam" #11 ? in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam" #12 __libc_start_main in "/lib64/libc.so.6" #13 ? in "/opt/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/bin/simpleFoam"
The error message from the readMe! output node is attached below as a text file.
Hope you can kindly advise what the important steps or parameters I might have missed here. I assume it might be related to OpenFOAM rather than with the Butterfly workflow...
Thank you very much!
- Ji
…
ide con m2 y coloca el XY CPlane en este punto, para tener una referencia.
3) Selecciona todas tus lineas con un parámetro de Curvas.
4) Usa un componente de curva, análisis de Perpendicular a la curva y colocado en su inicio de cada curva = linea un CPLane.
5) Usa de XForm, un Orient to a New CPlane. Este componenete te pide, el perfil, el CPlane de referencia, que ya lo tenemos y el Target, que ya lo encontramos.
6) Usa Vector 2Puntos para encontrar los vectores de cada linea y los pones con valor Unitario. Usa un componente de Find Start and End points para encontrar estos 2 puntos.
7) Usa un componente Extrude Curve de Surfaces y a cada perfil le das una magnitud = fuerza etc... NOTA: Puedes encontrar la longitud de cada curva también y crear una lista y usar esta lista para dar el valor del Extrude...
BINGO! creo yo.... es una idea mas...
Saludos
…
h the (1) button. If the data type represents referenced geometry (Curves, Surface, Breps, Meshes, IDs) then you'll be asked to select an object in Rhino.
You can delete all selected items with the (2) button.
If the data type supports textual input (most simple types with the notable exception of points), then you can switch between visual mode (shown above) and text mode using the (3) button.
Data items can be (de)selected by clicking on them, you can use Shift and Control to modify selections. Clicking and dragging on a selected item will allow you to drag all the selected items in one go (4). You can however also drag individual items irrespective of selection state using the grip area (5).
When multiple items are selected, their combined properties will be shown in the grid on the right. When the items have different values for certain properties, the fields will remain blank (6), if they have identical values, those will be displayed (7).
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
ere needs to be an algorithm for the program to follow. (In case you don't know)
"In mathematics and computer science, an algorithm is an effective method expressed as a finite list of well-defined instructions for calculating a function. Algorithms are used for calculation, data processing, and automated reasoning. In simple words an algorithm is a step-by-step procedure for calculations."
If you were able to put together a step by step guide to how you would achieve this manually, this would be your algorithm, and with this you might be able to determine what components are needed in Grasshopper or post it online to get help.
For example it could look something like this:
1) Reference Input Geometry
2) Reference Points
3) Target Points
4) Create Lofting curves through Target Points
5) Create Target Surface by Lofting curves
6) For each reference point do the following:
___a) Find closest point on reference Surface.
___b) determine ref srf UV co-ords of ref pts
___c) Identify UV co-ords on Trgt Srf
___e) Map objects to trgt Srf
etc. etc.…
Added by Danny Boyes at 4:15am on November 3, 2011