ng in Grasshopper?
As a general recommendation for developers in Grasshopper who are writing a part of their library which is performance-sensitive (please note: often the performance sensitive part is very limited) is to write it in C#, or maybe even C, or maybe even assembly :). Of course, the closer to the machine you will be, the easier it will be to harness all minimal optimizations. However, there is always a compromise between "getting things done" and "making them best" and this boundary is not very easy to catch, right?
If you want to have significant speed improvements for numerical calculations, I would at least recommend developing with C# in a compiled component using Visual Studio or SharpDevelop. The reason is: in order to provide the line number of possible errors, Grasshopper compiles C# scripts in debug mode! They will be much less optimized than what is possible even with today's technology. This does not preclude keeping the project open-source, if that is one of your goals.
Regarding the actual list:
1) Yes, the implied loop will probably be slower than just a simple for loop. This is because Grasshopper code has to keep track of more things than the ones you could be considering with your knowledge of of your very-special case. However, a factor of 10 is simply not acceptable and is likely a symptom of something else. In fact, I think I remember fixing a bug around that in Rhino WIP. However, it appears to be still slower also there. I've added a bugtracking item here.
2) If you are able to do all casts that are involved, and do them as Grasshopper does, please write that code that way. For example, if you supply a curve to an input with number hint, Grasshopper computes the length of the curve. There will have to be an "if" that checks if the input is a curve somewhere (or some similar construct). This aid for designers is what slows down the hint input.
3) Grasshopper has to keep side effects at bay. For example, components B and C are both connected to outputs of A. If you edit data in component B, and that data came from A you of course expect that data to be unchanged in C. This means that, for even lists of numbers, Grasshopper has to perform a deep copy of the output for each input. Otherwise, what happens if B sorts the list and C finds the index of the smallest number? This could be improved if GH components had some way of flagging themselves as non-data-mutating (constant). The fact that, by supplying special types, Grasshopper has no way of performing copies will likely speed things up. But be aware of possibly very annoying side effects creeping in if data is not immutable. Another option is performing the copy "optimally", just where you need it, because you know where your data is used. This is not information that is available to GH at present.
Does this help?
Thanks again for your input,
Giulio--Giulio Piacentinofor Robert McNeel & Associatesgiulio@mcneel.com…
onents to the latest version and, as you can see, everything works fine:
Over the next week, I am going to be adding in several new capabilities to the Adaptive model in LB+HB that are not an official part of ASHRAE or ISO standards but they are endorsed by the experts and researchers who have helped build the standards. Mostapha, I will be sure to have the component give a comment any time that these un-standardized methods are used and I will be clear that I have made them a part of LB because I have found these insights from new research to be particularly helpful to design processes for passive architecture. Also, I think many of us recognize that both ASHRAE and ISO were initially founded to produce standards for conditioned or refrigerated spaces and that, understandably, they . Among the features that I will be adding in:
1) You will have the option of using either the American ASHRAE adaptive model or the ISO EN-15251 model (see the CBE's comfort tool for a visual of the differences - http://comfort.cbe.berkeley.edu/).
2) In addition to a different comfort polygon, the European standard also uses a "running mean" outdoor temperature instead of the average monthly outdoor temperature. This "running mean" is computed by looking at the average temperatures over the last week and weights each of the daily average temperatures by how recent it is. This makes more sense to me than the ASHRAE method and addresses the issue that you bring up, Alejandro. Needless to say, the updated adaptive model will allow you to use either a running mean or average monthly temperature with either the American or European polygon.
3) The WIP adaptive chart currently has an option for a "levelOfConditioning". This input allows you to make use of research the was conducted along-side the initial development of the adaptive model, which showed that the findings did not contradict the PMV model when people were surveyed in fully conditioned buildings. This parallel research ended up producing a different correlation between the outdoor and desired indoor temperatures and this correlation had a much shallower slope than the official adaptive model for fully naturally-ventilated buildings. The levelOfConditioning allows you to make a custom correlation for full natural ventilation, full conditioning or (presumably) somewhere in between for a mixed-mode building. This levelOfConditioning will become an official input for all LB components using the adaptive model (not just the chart at the moment).
At the end of all of this, I will put together a new video series on Adaptive comfort so that we are all on the same page about how to use the model.
-Chris…
... er ... hmm ... I would strongly suggest Plan B:
How to get the gist of C# in just 123 (+1) easy steps (I've already posted that 3-4 times if memory serves well):
Step 0: get rid of the computer (press the OFF button), buy some cigars:
Step 1: get the cookies
The bible PlanA: C# In depth (Jon Skeet).
The bible PlanB: C# Step by step (John Sharp).
The bible PlanC: C# 5.0/6.0 (J/B Albahari) > my favorite
The reference: C# Language specs ECMA-334
The candidates:
C# Fundamentals (Nakov/Kolev & Co)
C# Head First (Stellman/Greene)
C# Language (Jones)
Step 2: read the cookies (computer OFF)
Step 3: re-read the cookies (computer OFF)
...
Step 120: re-read the cookies (computer OFF)
Step 121: tun ON computer
Step 122: do something
Step 123: shut down computer permanently, forget all that
May The Force (the Dark Option) be with you.…
l, you can find examples of parametric design using LB/HB, specifically the HB component pollinator workflows.
In these examples, a GH component (data recorder) is used to locally store either input parameters or output values of different model configurations and transmit them to pollinator. I can imagine, depending on how your facade is made parametric in GH, that you could save those input parameters (e.g. angle of surfaces or height of extrusion) and output variables for each iteration (e.g. annual shading).
This a search process through the design space. I do think that if you would set up the model as such, then it would be ok that the components in the PV workflow resetted after each iteration as the results would be saved. There is even a really good visualization platform Mostapha has shared to go along pollinator.
You can find examples of these workflows in the forum, simply search pollinator. I have one that I shared somewhere as well, although it was doing rudimentary things it would help.
This design space approach is a bit different than the optimization approach utilizing components like galapagos. It gives you an idea of the space of possible different desings and allows you to compare alternatives. Plus, it usually allows me to avoid all these issues of losing results between components in the workflo.
I also find it very handy and much more efficient than simply allowing a component optimize everything for me. However, it can ncrease almost exponantially (or is it geometrically, I am always bad at this) to the range and number of your input parameters. So, if each square on the wall has more than a couple of input values for a a few input parameters, I would expect this to take a long time. Thankfully, the components in the workflow will let you know exactly how many iterations.
If this method is interesting to you and you follow it I would suggest a few things to hasten the process like utilizing only the squared above and on the sides of the PV panel, since the others won't really affect shading, selecting just 2 or 3 characteristic angles for extrusions, and perhaps approximating energy production through annual shading numbers (since I imagine they have an almost linear relationship).
I do hope that I have understood what you want to do and the above information helps. I'm sure Djordje will give much better feedback on the specifics of the PV workflow. I will try and keep this page saved so that I can send over the example once I'm back at work mid of next week.
Good luck!
Kind regards,
Theodore.
…
ave bugs and your set-up may differ from what we tested. If you find any, please note bugs in the comments so we can fix them, thanks... Greg
The implementation is pretty logical, and open enough that you can use GH to easily link the robot toolpath and rail/table control for 1,2 and 3 axis linear rails and 1, 2 and 2x1, 1+2x1 etc. rotary tables. The 'Create External Axis' component is included so you can add you own geometry, or create other configurations.
Linear Rail: Plug External Axis into P on the robot.
The basic idea is that you instruct the rail to move the robot base plane either independently or relative to the toolpath. The later is preferable, so when you modify the toolpath the robot base position remains linked. For smooth toolpaths this works well, if you have a lot of back and forth movements, the whole robot will do that too, in which case a direct approach may suit you better, or some bracketing (we'll generate some examples for that soon).
Note: To keep the Linear Rail static while it is working on the Rotary Table, you can input a list of duplicate values to the Rail Axis input.
Rotary Table: Plug External Axis into E on the robot.
Control this through a list of angles in radians. The list of length values for the Linear Rail or the list of angles for the Rotary Table must be the same length as the number of Planes in the Path - as each value goes onto the same line of robot code.
There are two basic examples in the attached file:
Still to do:
- Integration with the IO Milling plugin.
- API calls.
- Tutorials for Create External Axis component.
For any questions, feature requests, bugs and example file requests - add your comments below... Please share you examples as well.
…
Added by Gregory Epps to IO at 12:55pm on August 12, 2015
uld help me to optimize the script, so it works reliable.
At the end the script should work only by the input of the following informations:
- Top-Curve
- Bottom-Curve
- accuracy ( like poly-count)
- is the bowl an open or closed structure?
This is an example of a good result:
From here its probably the best if you open both attached files, so you understand the problems.
1. Bug:
Offset direction of the bottomcurve needs to be set up by hand sometimes.
The script uses "loft" on a bunch of 3pt Arcs to create transitions. Arc 3pts" needs a "Point B" on the offset of the bottom line. Sometimes the offset is inverted, so i need to change it by hand.
The rule to make it work correct is: "The offset of the bottom line goes into the same direction as the top line, but on the same hight as the bottom line."
How can i implement this in GH?
2. Bug:
The floor generation needs a lot of guessing the right index numbers of lists.
The script uses 2x "Deconstruct Brep" to find the actual bottom curve of the created transition Brep. "Patch" is used to create a floor from this curve.
If the bowl is an open structure, the script creates a line between the endpoints of the bottom curve to close it, in order to create a trimmed "Patch". But again, you have to set up the right Index Numbers by hand...
3. Bug:
If the bowl is an open structure and the endpoints of the top-line and the bottom-line are the same the lofting is not working. At the moment I use a script that finds double points in the list and deletes it.
But the the result is, that the loft is not starting at the beginning or the end. Here is an Image.
I have only a little experience in gh, but i really want to learn more.
Thank you all for your help!…
pproach that will hopefully work. There's still the last part of putting it all together, but I figured I'd post my progress so you could play around with it if you wanted. This is kind of a lucky situation since its only single face breps and simple trims that are being worked with.
I've attached 3 definitions to this post. The first is my reorganization of your original definition, which creates the surfaces from the point grid and culls out any surfaces that are not "on" the surface so that we don't have to deal with them later down the line. This is done through a small VB component which determines whether any of the corner points lie on the surface. If it does it keeps the surface, if not, then it doesn't. The only issue with this is that in your example file, there are some surfaces which the corner points do not lie on the surface, yet the surface that they create spans the underlying surface. At this point I'm not worrying about those. You mentioned that you only want the surfaces that lie at the edge...this can be done by testing whether all 4 corner points lie on the trimmed surface or not.
The second definition is a coded version of the project function. In the example it will project to all the breps supplied, yet in the final version this probably won't be desired. Also, the direction (z axis) is hard code...this could be swapped out if desired.
The third definition is an shot at trimming a surface with an input curve (that curve happens to be projected). I tried this many ways, but found that the function RhinoCutUpSurface seamed to work alright. The other attempts at doing this directly with through functions available for OnBrep were unsuccessful and very complex. Luckily because the underlying brep is an single, untrimmed surface this function works well for us, but in situations where we have a trimmed or multiface brep we'd be up a creek with out a paddle. The function creates an array of breps, but in our case it will create essentially the same surface split by our curve and joined together as a single brep with two (possibly more) faces. All we have to do is find out which face we want to keep and duplicate that into a separate brep and pass it out of the component. In the example file I'm determining which on to keep based off of the distance from a test point to the centroid of each face.
The other option here, which would trump the need for projection or trimming, would be to extrude the edge curves through the surface in question, and use the BrepSplit function which requires two breps. There would still be the need to sort out what to keep, but if this approach were used, all the split pieces would be separate breps.
So, all the pieces are pretty much working separately, all that I have left to do is put them all together in the base definition. The only thing that is really the hump with that is determining exactly which face to keep. My idea at the moment is to find out which corner of the surface does not like on the base surface and use that to determine which face will be thrown out. This might be one of the easier ways, but will not be rock solid. The other option is to pull a test point that's on one of the faces to the base surface and the other face, then use the distance from test point to the point on the base surface and the distance to the pulled point on the other face to the base surface to figure out which one to keep.
As to sectioning off parts of the solution, you could do this in a number of ways, but here's two simple ones. In a scripting component just add a boolean value to the inputs and put the whole script inside of an if statement that looks at that boolean value. With components just add a boolean gate or a null pattern componet anywhere you want in the stream. Again, hook in a boolean toggle value, and that will stop the info from going to components that are downstream.…
.
as you can see I devided it into 3 parts.
part1: when I try to connect the new shape to the rest of your definition,the plan z,which gives the panels individually when baked(so I can work them individually)doesn't work,apparently there is something missing when I want to explode it.
that is why I connected it to the definition that I already had(part2)( the only cool part about that one is the attractor point)well it kind works,but not really(if you zoom in you can see that there are some parts overlapped and really not looking good).however I much rather your definition because of the option it gives me to work with individual panels when baked(planz).
however it's around 4 am. and I have decided to make some major changes in design (to prepare some closed and open space,I'm talking about part3 that works with the fibonacci like shape,I know it doesnt look really good,but seriously 4am.!).the major problem is that I tried to make a form like that with kangaroo so the shape would be smoother but I wasnt really able to make it with kangaroo,that's why I made it manually in rhino.I was wondering if you can help me make something like this ( not exacly like this) with kangaroo or (if impossible to be made with kangaroo)even helping me optimizing it so it doesnt look as bad,as you can see when I try to work the grasshopper definition on this shape,it gives me different panel sizes for each surface and all of them are to small compared with the overall size of the so-called pavillion(give it 200-500 sq feet (20-50 sq.m).and any suggestions about the shape would be appreciated,please forgive my basic knowledge of rhino and grasshopper,and let's say I wanted to make a shape like these(don't laugh please!)
u promised not to laugh!!!
please help me find the right way!
…