edit 29/04/14 - Here is a new collection of more than 80 example files, organized by category:
KangarooExamples.zip
This zip is the most up to date collection of examples at the moment, and collects t
oxes in the most efficient way within boundaries of object and follow the following constraints. The Goal: To fit 125 boxes in the most efficient way inside the total area. Starting Variables: (1) 40% of the Boxes need to be between 60 and 85MSQ. (2) 40% of the boxes need to be between 86 and 110MSQ.
(3) 20% of the boxes need to be between 111 and 125mSQ. The breakdown doesn’t have to be exact to give the script some flexibility. Meaning you can have 41% +39% +20% = 100%.
Constraints:
1. A total MAXIMUM area of approximately 1600M per layer.
2. A maximum of 8 layers for a total of 12,800M per layer. Optimization can make as little or as many as 8 layers vertical to accommodate all boxes. So if script can achieve with 3 levels great. If needed all 8 levels, that's fine too. However, pay attention to next constraint (#3).
3. Approximately 15% of that space on each layer is off limits. (internal area) (blue area in example script) and the shape of the boundary cannot be modified to accommodate box design resulting in jagged lines for the internal area.
4. All generated squares/rectangles must have at least 3m touching an outside border (The Green lines).
5. All boxes must also be touching minimum 1M of border of the blue line.
6. If the boxes generated go outside the green boundary, they must be fillet to maintain the straight lines of the green boundaries.
7. Get as many of the boxes as possible a view towards the dots.
Could any one provide me a method or a way to start, if there are any useful links, please share with me. Thank you!…
Boxes in the most efficient way within boundaries of object and follow the following constraints.
The Goal: To fit 125 boxes in the most efficient way inside the total area. Starting Variables:
(1) 40% of the Boxes need to be between 60 and 85MSQ. (2) 40% of the boxes need to be between 86 and 110MSQ.
(3) 20% of the boxes need to be between 111 and 125mSQ. The breakdown doesn’t have to be exact to give the script some flexibility. Meaning you can have 41% +39% +20% = 100%.
Constraints:
1. A total MAXIMUM area of approximately 1600M per layer.
2. A maximum of 8 layers for a total of 12,800M per layer. Optimization can make as little or as many as 8 layers vertical to accommodate all boxes. So if script can achieve with 3 levels great. If needed all 8 levels, that's fine too. However, pay attention to next constraint (#3).
3. Approximately 15% of that space on each layer is off limits. (internal area) (blue area in example script) and the shape of the boundary cannot be modified to accommodate box design resulting in jagged lines for the internal area.
4. All generated squares/rectangles must have at least 3m touching an outside border (The Green lines).
5. All boxes must also be touching minimum 1M of border of the blue line.
6. If the boxes generated go outside the green boundary, they must be fillet to maintain the straight lines of the green boundaries.
7. Get as many of the boxes as possible a view towards the dots.
Could any one provide me a method or a way to start, if there are any useful links, please share with me. Thank you!
…
re is my problem... I need to arrange Boxes in the most efficient way within boundaries of object and follow the following constraints.
The Goal: To fit 125 boxes in the most efficient way inside the total area. Starting Variables:
(1) 40% of the Boxes need to be between 60 and 85MSQ. (2) 40% of the boxes need to be between 86 and 110MSQ.
(3) 20% of the boxes need to be between 111 and 125mSQ. The breakdown doesn’t have to be exact to give the script some flexibility. Meaning you can have 41% +39% +20% = 100%.
Constraints:
1. A total MAXIMUM area of approximately 1600M per layer.
2. A maximum of 8 layers for a total of 12,800M per layer. Optimization can make as little or as many as 8 layers vertical to accommodate all boxes. So if script can achieve with 3 levels great. If needed all 8 levels, that's fine too. However, pay attention to next constraint (#3).
3. Approximately 15% of that space on each layer is off limits. (internal area) (blue area in example script) and the shape of the boundary cannot be modified to accommodate box design resulting in jagged lines for the internal area.
4. All generated squares/rectangles must have at least 3m touching an outside border (The Green lines).
5. All boxes must also be touching minimum 1M of border of the blue line.
6. If the boxes generated go outside the green boundary, they must be fillet to maintain the straight lines of the green boundaries.
7. Get as many of the boxes as possible a view towards the dots.
Could any one provide me a method or a way to start, if there are any useful links, please share with me. Thank you!
…
ce issue with Rhino and shouldn't make an issue with EnergyPlus but just to have cleaner geometries, I untrimmed base surfaces so zones are closed brep now.
I also noticed that when you are adding multiple openings to a surface, the surface doesn't show-up in the output of createHBZoneFromHBSurfaces. The surfaces are there though and show up once you explode the zone! Again should be a tolerance issue for join. I need to take a closer look to both of these.
Also, in a number of the zones you had wall surfaces connected to createZoneFromHBSurfaces both before and after adding glazing. I removed parent surfaces so you don't end up having duplicate surfaces.
Back to adjacency which was your question, the issue happens since you have couple of zones with the same name so component was assuming them to be the same zone so it wouldn't solve the adjacency (Yes! it shouldn't. That was a bug which is fixed now). I changed the names and now it should find the surfaces that you are looking for.
Moreover, once you solve the adjacency, next solveAdjacency won't overwrite the BC unless you set remCurrentAdj to True.
Mostapha…
ey eventually recover and you can continue to working normally. This however is not very practical...
(Additional information: We have a virtualized Windows SPS environment, might this be the problem? Locally - on my hard drive - it works fine.)
Futhermore we've discovered the following bug/feature:
We export a cluster and reference it back into our .gh file, then copy the .ghcluster file to a different location and rename the copy (without opening or changing it), then also reference the copied version back into the .gh file. Now Grasshopper shows two clusters with two different file paths, but claims that they both are the same ("this cluster occurs twice in this document"). If I double click one of them, make a change and save, both clusters get changed, even though they are separate .ghcluster files.
This would follow the logic that David laid out in this entry (http://www.grasshopper3d.com/page/clusters09), that GH identifies a cluster not by its file name or location but by its internal ID.
An addition we would very much appreciate for the next GH update, would be the option to right click a referenced cluster and then not only be able to "update" it but to also to "relink" it to a new or different source.
Right now you have to rename or delete the .ghcluster file in order to relink a cluster via the update option. You can also overwrite the old cluster und update. However, sometimes we want to keep the old version or disentangle one of a clusters many instances and relink just one, with out loosing its various inputs and outputs by referencing the new version and reconnecting it.
Thanks, BB.…
ion into the world of Parametric Design using these two sofwares. Grasshopper is a graphical program language through which one can model complex geometric forms. It builds generative algorithms were outputs to these forms are tied to the inputs of subsequent components. Rhino is an advanced NURBS modeler through which one does precision modelling, project workflow and organization. Grasshopper utilizes Rhino 3-D as a modeling platform to develop parametrically controlled models with real time geometric manipulation. These two programs are a powerful combination where Grasshopper parametrically defines the model logics to explore variations and optimized solutions while Rhino models and visualizes it. These two programs are essential for architects, designers, engineers, professionals, and students interested in exploring professionally the world of parametric design."This workshop will be held in Amman/Jordan between the 15th and 22nd of January 2016 from 5pm to 10pm …
his on the programming forum I'm guessing you're looking for a VB or C# approach to this?
Here are two algorithms (pseudo code, very similar) which will simulate a droplet of water on a surface (ignoring momentum, surface tension, surface angle, collisions with other drops etc.)
Algorithm one, easy implementation, slows down on horizontalish areas:
1) Pick a point somewhere on the surface. How you get to this level is your problem.
2) Lower the point by a certain fixed amount along the z-axis. Say, 0.1 units.
3) Project the lowered point back onto the BRep using a ClosestPoint function.
4) If the newly projected point is very similar to the input point, abort, otherwise, repeat step 2.
Algorithm two, more difficult, better control over step size:
1) Pick a point somewhere on the surface. How you get to this level is your problem.
2) Find the normal vector at this point.
3) If the normal vector is (nearly) straight up, abort.
4) Find the CrossProduct between the normal vector and the straight-up vector.
5) Rotate the normal vector 90 degrees around this cross-product.
6) Scale the rotated vector so it becomes the length of your sampling accuracy.
7) Move the point along the vector and pull it back onto the surface (should be a short distance if your step-size is small)
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
Added by David Rutten at 12:20pm on November 23, 2009
google's data (please correct if I'm wrong):
"SRTM1 data is sampled at one arcsecond (about 30 meters) and SRTM3 data is sampled at three arcseconds (about 90 meters). The higher resolution SRTM1 data is available for most of the US and the lower res SRTM3 data is available for most of the world."
The 3x3 stitching definition above is done in Rhino 4 but it doesn't actually "stitch together" or merge the surfaces into one. I had to do it manually in Rhino with the merge surfaces command. Which I think does a better job than grasshopper.
Also I think the calculations within it (distance of one degree change in lat/lng) won't be accurate enough (or high enough in resolution) even though they are correct so I cannot guarantee the 3x3 pieces are perfectly neighbouring sets of data (they might contain very very tiny strips of overlapped/missed topography data). However this error is really insignificant next to the limited resolution of the generated topography so it is neglectable if you're not a perfectionist like me.
Edit: For bigger areas Elk is much easier, but for smaller areas where you want to specify the area size Xiaoming's component is more convenient I think.…
s set up. All the goals in Kangaroo have indices identifying which of the points in the system they act on.
Assigning these indices automatically and still allowing inputs to change during simulation requires some tricks to work around the acyclic directed nature of Grasshopper.
In remeshing the indexing and even number of points changes which greatly complicates things if you want to also have goals assigned to certain edges/points.
Last time I spent serious time on this though was before the K2 library, so maybe time to revisit soon. I think it would probably over complicate things trying to accommodate this remeshing directly within the main Kangaroo solver component, but there could be a dedicated membranes tool (though I know you also want me to prioritize documenting the existing tools!).
Stepping back for a moment though - it is usually possible to separate the remeshing and relaxation into separate steps. Membrane relaxation generally needs well shaped triangles (no angles over 90), and remeshing can give you this. Of course the triangles change shape during relaxation, but if the unrelaxed geometry is not too dramatically different from the end result, and you use tangential smoothing to keep vertices from drifting, they can stay well shaped throughout. For bigger changes in geometry you could also remesh-relax-remesh-relax.…
Added by Daniel Piker at 10:29am on January 13, 2016