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.
…
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.
…
ng/702/30
EDIT: DK2 works, not with positional tracking yet (14/09/15)
Source is here:
https://github.com/provolot/RhinoRift
Steps:
1) Download these files (also attached below):
https://github.com/provolot/oculus-grasshopper/raw/master/oculus-grasshopper_v0.4.ghx
https://github.com/provolot/oculus-grasshopper/raw/master/OpenTrackRiftGrasshopperUDP.ini
https://github.com/provolot/oculus-grasshopper/raw/master/oculus-grasshopper-test_v0.1.3dm
2) Download OpenTrack - http://ananke.laggy.pk/opentrack/, and setup/install. Once installed, double-click to open.
3) In OpenTrack, load the 'OpenTrackRiftGrasshopperUDP.ini' profile. Click the 'Start' button and move your Rift around - make sure that it looks like the Yaw/Pitch/Roll data is being sent. TX/TY/TZ will all be 0, as Oculus doesn't have absolute positioning data.
4) In Rhino, open the test 3dm. You'll notice that there are two viewports - called 'LeftEye' and 'RightEye'. These have been placed to mimic where the screens should be for the Oculus Rift --- but only when Rhino is in fullscreen mode, with the command 'Fullscreen'. The placement needs to be tweaked, but should work.
If you want to use your own model, you can load your own .3dm file in Rhino, then you can right-click on the viewport name, and go to Viewport Layout > Read from File. If you then load my test file, Rhino should open my two viewports, sized correctly, onto your model.
The placement of these viewports need to be tweaked; if you find a better viewport layout, upload an empty Rhino file with your viewports, and we can share eye-layout 'templates'!
5) In Grasshopper, open the .ghx definition. Everything that is multiple-grouped is a value that can be changed. Two things here:
- IPD: Set this and convert it to the proper units for your model.
- Left/right viewport names. In this case, leave this as-is, since you're using my example file.
6) Turn on the Grasshopper Timer, if it isn't on already.
7) In the GH definition, toggle 'SyncEyes' to be True. Then, in the left viewport, try orbiting around with the mouse. The 'RightEye' viewport should move around as well, pretty much simultaneously.
8) In OpenTrack, click 'Start', then toggle 'ReadUDP' to be True. You should see the 'OpenTrackInfo' panel fill with data that's constantly changing.
9) Move around the landscape with your camera, and when you set on a starting view that's ideal, click the triangle of the Data Dam component to 'store' the data.
10) Finally, toggle 'OculusMove' to be true. If all works correctly, both viewports should move based on the Rift's movement.
Let me know if you have any problems!
Cheers,
Dan…
Added by Dan Taeyoung at 11:47pm on December 10, 2013
iece could be easily cut using the "plan" curve, the wall need extra attention and manual work to prepare.
This script attempts to automate the preparation of lasercutting curves with some control:
1) Height: The parameter is set using the "Name" property of the Rhino "plan" curve object. Number of storeys (e.g. 5) is to be entered in that field and the script will read it after you press F5 (recompute) in grasshopper. If the block models are not multiples of standardised storey height, you could set "Storey height" in grasshopper to 1 and set exact height to individual "plan" curves in Rhino.
(Special mention: This part of script including reading "Name" property in Rhino and auto-correcting curve direction is attributed to Victor Leung's Laser Cutting Tool for Block Models)
2) Mode of wrapping: The wall could either be "sitting" on the bottom plate and being completely covered by the top plate, or wrapping outside both the bottom and top plate. In either case, material thickness is taken into consideration and the finished model will remain the same size.
3) Extra height option: In preparing flat roof models, one may like to add extra height for parapet wall to make the model more appealing.
4) Easy picking up: Each individual piece has some uncut part (red lines for engrave) to hold itself in place after cutting. There is no need to use masking tape to stick. Individual pieces could be taken out when you are ready to use.
There are also known issues to this script:
1) At internal corners, the adjacent wall will be longer (in wrapping outside mode) or shorter (in sitting inside mode). You have to manual cut at this point.
2) It could not work with only one input curve. (Although it may be a stupid bug,) A dummy rectangle nearby could be created to make it work.
Enjoy,
Sa
Lasercutting Tool for Block Models (Fold and Wrap) by Sa Ng is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Based on a work at http://www.grasshopper3d.com/forum/topics/laser-cutting-tool-for-block-models.
…
The PC actually stops working because after a few seconds the simulation starts the fan inside the PC all of a sudden stops and for the next 5-10 mins I cannot do anything, even alt+ctrl+canc. After I wait for that time i get the followig error:
the ReadMe says:
{0;0;0}0. Grid-based Radiance simulation1. The component is checking ad, as, ar and aa values. This is just to make sure that the results are accurate enough.2. -ar is set to 300.3. Good to go!4. Current working directory is set to: C:\Users\Luigi\Desktop\Prova__\Prova_1\gridBasedSimulation\5. Found a trans material... Resetting st parameter from 0.85 to 0.011276004966. WMIC PROCESS get Commandline7. WMIC PROCESS get Commandline8. WMIC PROCESS get Commandline9. WMIC PROCESS get Commandline10. WMIC PROCESS get Commandline11. WMIC PROCESS get Commandline12. WMIC PROCESS get Commandline13. WMIC PROCESS get Commandline14. WMIC PROCESS get Commandline15. WMIC PROCESS get Commandline16. WMIC PROCESS get Commandline17. WMIC PROCESS get Commandline18. WMIC PROCESS get Commandline19. WMIC PROCESS get Commandline20. WMIC PROCESS get Commandline21. WMIC PROCESS get Commandline22. WMIC PROCESS get Commandline23. WMIC PROCESS get Commandline24. WMIC PROCESS get Commandline25. WMIC PROCESS get Commandline26. WMIC PROCESS get Commandline27. WMIC PROCESS get Commandline28. WMIC PROCESS get Commandline29. WMIC PROCESS get Commandline30. WMIC PROCESS get Commandline31. WMIC PROCESS get Commandline32. WMIC PROCESS get Commandline33. WMIC PROCESS get Commandline34. WMIC PROCESS get Commandline35. WMIC PROCESS get Commandline36. WMIC PROCESS get Commandline37. WMIC PROCESS get Commandline38. WMIC PROCESS get Commandline39. WMIC PROCESS get Commandline40. WMIC PROCESS get Commandline41. WMIC PROCESS get Commandline42. WMIC PROCESS get Commandline43. WMIC PROCESS get Commandline44. WMIC PROCESS get Commandline45. WMIC PROCESS get Commandline46. WMIC PROCESS get Commandline47. WMIC PROCESS get Commandline48. WMIC PROCESS get Commandline49. WMIC PROCESS get Commandline50. WMIC PROCESS get Commandline51. WMIC PROCESS get Commandline52. WMIC PROCESS get Commandline53. WMIC PROCESS get Commandline54. WMIC PROCESS get Commandline55. WMIC PROCESS get Commandline56. WMIC PROCESS get Commandline57. WMIC PROCESS get Commandline58. WMIC PROCESS get Commandline59. WMIC PROCESS get Commandline60. WMIC PROCESS get Commandline61. WMIC PROCESS get Commandline62. WMIC PROCESS get Commandline63. WMIC PROCESS get Commandline64. WMIC PROCESS get Commandline65. WMIC PROCESS get Commandline66. WMIC PROCESS get Commandline67. WMIC PROCESS get Commandline68. WMIC PROCESS get Commandline69. WMIC PROCESS get Commandline70. WMIC PROCESS get Commandline71. WMIC PROCESS get Commandline72. WMIC PROCESS get Commandline73. WMIC PROCESS get Commandline74. WMIC PROCESS get Commandline75. WMIC PROCESS get Commandline76. WMIC PROCESS get Commandline77. WMIC PROCESS get Commandline78. WMIC PROCESS get Commandline79. WMIC PROCESS get Commandline80. WMIC PROCESS get Commandline81. WMIC PROCESS get Commandline82. WMIC PROCESS get Commandline83. WMIC PROCESS get Commandline84. WMIC PROCESS get Commandline85. WMIC PROCESS get Commandline86. WMIC PROCESS get Commandline87. WMIC PROCESS get Commandline88. WMIC PROCESS get Commandline89. WMIC PROCESS get Commandline90. WMIC PROCESS get Commandline91. WMIC PROCESS get Commandline92. WMIC PROCESS get Commandline93. WMIC PROCESS get Commandline94. WMIC PROCESS get Commandline95. WMIC PROCESS get Commandline96. WMIC PROCESS get Commandline97. WMIC PROCESS get Commandline98. WMIC PROCESS get Commandline99. WMIC PROCESS get Commandline100. WMIC PROCESS get Commandline101. WMIC PROCESS get Commandline102. WMIC PROCESS get Commandline103. WMIC PROCESS get Commandline104. WMIC PROCESS get Commandline105. WMIC PROCESS get Commandline106. WMIC PROCESS get Commandline107. WMIC PROCESS get Commandline108. WMIC PROCESS get Commandline109. WMIC PROCESS get Commandline110. WMIC PROCESS get Commandline111. WMIC PROCESS get Commandline112. WMIC PROCESS get Commandline113. WMIC PROCESS get Commandline114. WMIC PROCESS get Commandline115. WMIC PROCESS get Commandline116. WMIC PROCESS get Commandline117. WMIC PROCESS get Commandline118. WMIC PROCESS get Commandline119. WMIC PROCESS get Commandline120. WMIC PROCESS get Commandline121. WMIC PROCESS get Commandline122. WMIC PROCESS get Commandline123. WMIC PROCESS get Commandline124. WMIC PROCESS get Commandline125. WMIC PROCESS get Commandline126. WMIC PROCESS get Commandline127. WMIC PROCESS get Commandline128. WMIC PROCESS get Commandline129. WMIC PROCESS get Commandline130. WMIC PROCESS get Commandline131. WMIC PROCESS get Commandline132. WMIC PROCESS get Commandline133. WMIC PROCESS get Commandline134. WMIC PROCESS get Commandline135. WMIC PROCESS get Commandline136. WMIC PROCESS get Commandline137. WMIC PROCESS get Commandline138. WMIC PROCESS get Commandline139. WMIC PROCESS get Commandline140. WMIC PROCESS get Commandline141. WMIC PROCESS get Commandline142. WMIC PROCESS get Commandline143. WMIC PROCESS get Commandline144. WMIC PROCESS get Commandline145. WMIC PROCESS get Commandline146. WMIC PROCESS get Commandline147. WMIC PROCESS get Commandline148. WMIC PROCESS get Commandline149. WMIC PROCESS get Commandline150. WMIC PROCESS get Commandline151. WMIC PROCESS get Commandline152. WMIC PROCESS get Commandline153. WMIC PROCESS get Commandline154. WMIC PROCESS get Commandline155. WMIC PROCESS get Commandline156. WMIC PROCESS get Commandline157. WMIC PROCESS get Commandline158. WMIC PROCESS get Commandline159. WMIC PROCESS get Commandline160. WMIC PROCESS get Commandline161. WMIC PROCESS get Commandline162. WMIC PROCESS get Commandline163. WMIC PROCESS get Commandline164. WMIC PROCESS get Commandline165. WMIC PROCESS get Commandline166. WMIC PROCESS get Commandline167. WMIC PROCESS get Commandline168. WMIC PROCESS get Commandline169. WMIC PROCESS get Commandline170. WMIC PROCESS get Commandline171. WMIC PROCESS get Commandline172. WMIC PROCESS get Commandline173. WMIC PROCESS get Commandline174. WMIC PROCESS get Commandline175. WMIC PROCESS get Commandline176. WMIC PROCESS get Commandline177. WMIC PROCESS get Commandline178. WMIC PROCESS get Commandline179. WMIC PROCESS get Commandline180. WMIC PROCESS get Commandline181. WMIC PROCESS get Commandline182. WMIC PROCESS get Commandline183. WMIC PROCESS get Commandline184. WMIC PROCESS get Commandline185. WMIC PROCESS get Commandline186. WMIC PROCESS get Commandline187. WMIC PROCESS get Commandline188. WMIC PROCESS get Commandline189. WMIC PROCESS get Commandline190. WMIC PROCESS get Commandline191. WMIC PROCESS get Commandline192. WMIC PROCESS get Commandline193. WMIC PROCESS get Commandline194. WMIC PROCESS get Commandline195. WMIC PROCESS get Commandline196. WMIC PROCESS get Commandline197. WMIC PROCESS get Commandline198. Runtime error (IndexOutOfRangeException): index out of range: 0199. Traceback: line 320, in script
The thing is that if I raise the -aa parameter from 0.05 to 0.1 all works fine..
Is this only related to my PC then?? What should I do to solve this issue?
Thanks again for your help
Luigi…
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
of them. If they were already suggested and deemed impossible, i apologize.First, it would be really cool to have a right-click menu item for any geometry retaining module, that does the following: bakes the geometry, then disconnects all inherited data from the module, and assigns the baked version as locally defined. This is a one-time only thing, of course - it would be cool because if you have a "step-definition", that is, you have clear bottlenecks in your dataflow, and at some point you become satisfied with what you have so far, and only need to manually tweak some stuff to move on, you can discard the "already solved part of your definition. It's just a sort of "casting in stone" of partial results, that helps especially with simple work-defs or helper-defs. You could also call it something kickass like "manual override" or "emergency/hand b(r)ake".Second, if you have a component that outputs to a lot of others, and you want to change it with something else, you usually have to painstakingly reconnect all those wires, and if it doesn't work out, you do it right back or undo until you fingers bleed. Just as there is an extract parameter upstream for locally defined values, a downstream "extend parameter" with one rightclick menu item would make switching between various components easier.
Third, maybe a hot-key that you press and then click on a wire, which creates a "data" component at that point, splitting the wire and effectively allowing you to hijack it.
Lastly, maybe this is a stupid question, but what happened to the "clusters"? I mean i know they ended abruptly because of technical difficulties, but collapsing a group to a single component like that was totally awesome.Oh, and a minor bug repor from the v7.053 - it's not important, but mildly annoying: when you have an embedded graft, flatten, reparam or expression into a plug, the component extends to the left with the nifty little icons, and that looks very nice, but the wires still go in the old place, so at first glance i always think the wires are plugged in wrong. Is it possible to move the plug along with the component icon edge, or at least make those little indicators smaller, so that the error is minimized?
Thanks for your time,Hope i was pertinent
Andrei I.ps: the lolcat component is adorable, but i do believe that overall worldwide grasshopper productivity has dropped by various increments of those 20 sec it takes for it to refresh. Sadly accustomed with the feeling of guilt associated to watching around 50 lolpics refresh, I suggest that every 5 refreshes or so, you get a "stop looking at this and get back to work" message. It is at least a good way to derogate responsibility for tempting people to watch kitty-pics all day. :D…
es at the beginning. But as I make changes to the input (or just hit the recompute button) the time it takes to execute increases. This has happened to me with other scripts I've written with the python component. Why does this happen? And how do I fix it? Does python hold onto data from one execution to the next? The only solution I have found is to relaunch Rhino. Even if I copy the component into a fresh grasshopper canvas, the computation time does not return to original.
The images below illustrate the time increase. I simply hit the recompute button between each pass. All inputs remain the same the whole time. There are 6400 curves being projected. I will say that with fewer curves, the increase in time is nonexistent or perceivable. (I have 24 GB RAM and it is did not even reach 50% of usage during the tests)
My python code:
import ghpythonlib.components as ghcompimport ghpythonlib.parallel
def project (tempc): tempresult=ghcomp.Project(tempc,B,D) return tempresult
a=ghpythonlib.parallel.run(project,C,True)
I have attached the GH file with the inputs internalized if anyone wants to try for themselves.
Pass 1= 444ms
Pass 5= 610ms
Pass 10= 908ms
Pass 15= 1.2s
Pass 20= 1.4s
…
Added by Lawrence Yun at 3:19pm on December 10, 2014