e actual method.
Below, I descibe how they work:
1) drag "scheduleDay" onto the canvas
2) drag some Gene Pool lists onto the canvas and connect a number slider - from 0 to 3.
3) connect the Gene Pool list to _genePool input. The component change some important features of the Gene Pool list automatically. Now you have LB_GenePool!!
4) choose the template that it's suitable for you.
5) disconnect LB_GenePool and if templates are not good, you can change them manually
6) drag "Ladybug annual schedule" onto the canvas
7) Connect LB_GenePools to inputs for the days of the week, Epw file and if you want to "_holiday" (in this way you consider holidays). Now you have your simple schedule.
8) a small workflow to visualize it into Rhino..
9) Connect "Ladybug annual schedule" to "Honeybee_Create CSV Schedule" to make your csv Schedule
You could make a schedule more complex than the one in the example above.
You can do that with _analysisPeriod input.
Bests
Antonello…
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
e's a ton of things that can be done with GH. If the desire to do 1000 different things is there, then its hard to not have that be expressed as 1000 different components. I think this is part of the learning process of GH.
On the other hand, I believe that there are opportunities for component consolidation. For instance, there's a curve frame component that takes a curve parameter, and a curve frame component that takes an integer for multiple curve frames. There doesn't need to be two different components for this, but their are. The trade off is that if you want to do multiple curve frames with the single curve frame component you have to add a few more components to get it done. So its the question of the extra real estate of an icon versus a few more components on the canvas and a few extra steps to get the same thing done. For beginners, I think having the extra icon is more useful, and although I expect advanced users could deal with it either way, having a definition that's less crowded and cluttered would be considered a positive.
The other opportunity for component consolidation (because I doubt any components will just be tossed) would be to make certain operations, such as creating a circle, articulate itself as one component which can change its format as opposed to individual components of the several operations that can create that object. So keeping with the circle example, the standard circle component, circle 3 pt, cen nrml rad, and possibly the InCircle component would all be one uber circle component, and you'd have to select the type or method of circle creation within the component, probably by right-clicking. I'm not sure this is a good thing for new users either as it hides functionality just as much, if not more, than having an icon for each operation. Yes, it would save screen space, but at what cost.
So as I see it, its a push as to whether saving the screen space of the icons is actually worth it. There are opportunities for saving space, but at a cost that may not be worth price being paid. A lot may hinge on the changes made to the interface.…
Added by Damien Alomar at 7:48am on December 30, 2009
ode, I get the start points and end points of lines, in the output list there are duplicates of points and I don't know why. For example if I input 3 lines, instead of 6 points as the output, it gives me 17 points. How can I solve this problem?
Protected Overrides Sub RegisterInputParams(ByVal pManager As GH_Component.GH_InputParamManager)
pManager.Register_LineParam("Line", "L", "my lines")
End Sub
-----------------------
Protected Overrides Sub RegisterOutputParams(ByVal pManager As GH_Component.GH_OutputParamManager) pManager.Register_PointParam("point", "sp", "my points")
End Sub
----------------------
Protected Overrides Sub SolveInstance(ByVal DA As IGH_DataAccess)
Dim Edge As Rhino.Geometry.Line = Rhino.Geometry.Line.Unset If (Not DA.GetData(0, Edge)) Then Return
StartPointList.Add(Edge.From)
EndPointList.Add(Edge.To)
DA.SetDataList(0, StartPointList)
DA.SetDataList(0, EndPointList)
End Sub
-------------------------
In this case to pass a list I used DA.SetDatalist and also I tried this :
For i = 0 To StartPointList.Count - 1
DA.SetData(0, StartPointList.Item(i))
Next i
For i = 0 To EndPointList.Count - 1
DA.SetData(0, EndPointList.Item(i))
Next i
in this case, it gives me just End points!!! of course without any duplication of points.
I really appreciate your help!
Nick…
hich are integers between 0 and 255 each) to XYZ which could be any floating point values, is as follows:
Dim factor As Double = 1.0 / 127.5 x = (colour.R * factor) - 1.0 y = (colour.G * factor) - 1.0 z = (colour.B * factor) - 1.0
So if a colour channel has the lowest value of 0, the corresponding coordinate will be -1.0. If the channel has the highest value of 255, the coordinate will be +1.0. In the case of [255,161,161] it does:
Dim factor As Double = 1.0 / 127.5x = (255 * factor) - 1.0 which equals 1.0y = (161 * factor) - 1.0 which equals 0.262745 (rounded to 6 decimal places)z = (161 * factor) - 1.0 which equals 0.262745
So the length of the vector with these xyz coordinates is:
SquareRoot of (1.0² + 0.262745² + 0.262745²) which equals 1.066803 (rounded again)
It also follows the largest possible length of a vector created this way is the Square root of 3, which roughly equals 1.732050
This conversion works both ways incidentally, so as long as you convert unitized vectors into colours you'll always get a non-clipped result.
--
David Rutten
david@mcneel.com
Poprad, Slovakia
…
o tutorial.
¿Por qué esta diferencia entre el componente "meshgraph desenróllese", y el mismo que puedo ver en el tutorial en VIMEO?
La misma diferencia que encuentro con otros componentes.
Es que una versión antigua de hiedra, .... o hay otro?, Que se utiliza en los tutoriales? Gracias
Hace falta que el plugin comprar?…
Added by Cfeldman to Ivy at 10:04am on September 17, 2017
Vertices.Count * 3]; int[] facesizes = new int[m.Ngons.Count]; List<int> faces = new List<int>();
int j = 0; for (int i = 0; i < m.Vertices.Count; ++i) { verts[j] = m.Vertices[i].X; ++j; verts[j] = m.Vertices[i].Y; ++j; verts[j] = m.Vertices[i].Z; ++j; } for (int i = 0; i < m.Ngons.Count; ++i) { MeshNgon mngon = m.Ngons.GetNgon(i); facesizes[i] = mngon.BoundaryVertexCount; for (int j = 0; j < mngon.BoundaryVertexCount; ++j) { faces.Add(mngon[j]); } }
CarveSharp.CarveMesh cm = new CarveSharp.CarveMesh(); cm.Vertices = verts; cm.FaceIndices = faces.ToArray(); cm.FaceSizes = facesizes;
return cm; }
Going the other way should be similar, though I don't know if you need to define Mesh faces and then N-gons, or if you can just define N-gons right away and it'll take care of the Faces list for you... Haven't tried the Rhino 6 API... Not sure if you can just use the index operator on MeshNgon directly or you have to go mngon.Item[i] or whatever.
And then instead of
Rhino.Geometry.Mesh res = CarveRC.CarveOps.PerformCSG(...)
do
CarveSharp.CarveMesh res = CarveSharp.PerformCSG(CarveMeshA, CarveMeshB, CarveSharp.CSGOperations.Union);
Mesh m = res.ToRhinoMesh();
or your own CarveMesh-to-RhinoMesh function which preserves N-gons.
…
Added by Tom Svilans at 8:45am on September 25, 2017
ve Intermediate Insight of Computational Design Strategies While Exploring Rangoli Art form in 2 Dimension and 3Dimesion in which Participants will not only be trained to Digitally Design using Parametric software's but they will also be trained to Fabricate them in reality.
This Course will be explored in manner where Participants will understand inter-dependency of Rhinoceros3D & Grasshoper3D through a unique Hybrid Teaching Method While Exploring Rangoli Geometry .
The course will also take participants through Topics such as - Computational Thinking, - Computational / Parametric Design, - Computational Rangoli Exploration, - Digital Fabrication, - 3D Visualization ( Rhino3D 6), - Making Info-graphics & Design Diagrams ( Rhino3d 6 ).
Participants will also be doing a Project at the last Leg of Workshop in which they will implement the skill they gained in first Few Weeks.
{ Tutor } Nitant Pixelkar (Computational Artist / Designer, Mumbai)
Nitant Hirlekar A.k.a. Pixelkar, is a Computational Artist. He graduated from Rachana Sansad school of Interior Design 2011, Mumbai. In Academics He Bagged Two Gold and One Silver Medal on National Level.
In his post academic days, he came across the Emerging Computational Techniques in Design industry in which Algorithm serves as a main Functional part. He uses Algorithms to Deconstruct the Captured images in Pixelated form using the Grid of the Desired Indian Art Forms.
He Heads Collective Group Named "Mutation Lab” which is a multidisciplinary Design & Art Cell. Where they Explore Computational Approach while Designing Various Scales Spatial Installation, Digital Fabrication, Interactive Installations and Computational Consultancy for Various Architects.
He has exhibited his first artwork in Kalaghoda Arts Festival for in 2014 And further in 2016 and 2017.In 2015 he exhibited in Dharavi Biennale” organized by Wellcome Trust,London & Sneha Organisation, Mumbai Which was internationally acclaimed. In 2016 he got Featured on a TV show - The Creative Indian's as an Absolut Creative Indian of the Week.
Academically he is been involved in Many Computational Design Workshops / Elective Studios for School of Interior Design (Rachna Sansad), LS Raheja College of Architecture & Rat-Lab (Delhi).
{ Participants } The Course is aimed at Architecture, Interior Design, Product Design,Furniture Design & Fashion Design Students and Professionals. However we would be thrilled to have any Interdisciplinary Artist / Creator/ Maker to join the Course as well.
{ Level }
Intermediate
{ Timing } Monday To Friday - 6:00 PM to 9:00 PM (15 Hours/ Week = 5 Week X 15 Hours = 75 Hours )
{ Dates } Registration Ends - 24th April 2020 **Subejct to Availablity
{ Workshop Dates } 4th May 2020 To 5th June 2020
{ Venue } Lower Parel,Mumbai ( Details To Be Announced )
{ Schedule }
{Registration Form}…
lan to add some more documentation about the units.
There are actually 2 different types of triangular 2d elements I've been working on, and I decided to hold them back from this release to avoid confusion until I have them both working correctly.
One is for simulating soap-film like behaviour, and tries to reduce its area to zero, to give true minimal surfaces. However, I realized that the cotan weighting option I've already added to the Laplacian smoothing component is exactly equivalent, so perhaps one doesn't really need both.
The other is a constant strain triangle, which (unlike the soap-film element) also allows simulation of shear resistance and non-zero rest area. Still working on this one - will post any new developments here.
However, since you talk about "near zero stretch", I suspect neither of these elements really matter in this case, as I get the impression (and correct me if I misunderstand) that you are mainly interested in the interaction between pressure and the concrete load, and the exact amount of stretching is not important as long as it is very small.
Because of the nature of the relaxation process, things will always stretch some amount, as they do in reality. To make the stretch of some elements small, the stiffness of those elements should be high relative to the other forces in the simulation, and this may necessitate using some high (fictitious) mass values to avoid numerical instability.
Finally, this release also contains the GasVolume component, which I think might be an easier to use alternative here. It is similar to the Pressure force, except also taking into account the volume of the gas (following Boyle's law).
…