rst option is the type of Point Grasshopper will display in the Rhino Viewport.
Dot
Point
Cross
Dot is a small dot of single colour.
Point is a slightly larger dot with a white center.
Cross an X-shaped cross. (Default)
Preview Plane Size
The option to change the size of the Plane appears as a fly out menu where an input box allows you to enter a value in Rhino Document Units to set the size of the Plane. (You must press Enter to accept the change)
Preview Mesh Edges
The option to hide/show mesh edges catches a few users out, thinking that the Meshing of the Object has failed.
And without...
There is a handy Shortcut of Ctrl+M to toggle between the two options.
Gumballs
As of version 0.9.0064, Grasshopper allows the user to move individual points that are Persistent[3a] by means of a Gumball in the Rhino Document. Volatile[3b] points can be made persistent by way of the Internalising feature found on the Context Menu of Components and Parameters
[3] Glossary:
Volatile - "liable to change rapidly and unpredictably". Referenced objects in Rhino are considered volatile.
Persistent - "continuing to exist or endure over a prolonged period". Internalised objects are considered persistent.
…
.com/forum/topics/use-pythoneditor-to-run?commentId=2985220%3AComment%3A138538
For now I am considering a simple test case in which a set of sliders are added together into a GH_number component called "output":
I am finding that from the Rhino Python Editor it is definitely possible to change the slider values and retrieve results in a loop. Below I copied the code that runs from the Rhino Python Editor, where I simply change the slider value of the slider with Nickname "Number Slider1" from 0 to 2. (note that grasshopper and the testfile are already open in this example)
This script prints out the following results as expected:
Slider value: 0.0Result value: 1.154Slider value: 1.0Result value: 2.154Slider value: 2.0Result value: 3.154
However using the exact same code in a GHPython component within Grasshopper the Grasshopper Python Script Editor's console reads:
Slider value: 2.0Result value: 3.154Slider value: 2.0Result value: 3.154Slider value: 2.0Result value: 3.154
It seems that the solver doesn't recompute during each iteration but just retrieves the final state of my script.
So basically I have been trying to trigger a 'runsolver' command inside my loop. I tried using the methods available trough the RhinoScript interface, as David describes here.
http://www.grasshopper3d.com/forum/topics/open-a-gh-automatically
I could create a loop looking like this:
But running this in the Grasshopper Component crashes Rhino. I have also tried this by Disabling the solver first using the DisableSolver() method. This does disable the solver but still Rhino crashes. Also I used the ExpireSolution(True) method on the slider object like:
However in this case I don't get any different results.
So I guess my question is simple:
Is there a way to recompute the solver after a slider change inside a GHPython script component during a loop?
Any suggestions, or references would be greatly appreciated!
(FYI: I am using Rhino5x64 and Grasshopper Version 0.9.0014, attached is the script I used both in the Rhino Python Editor and the GHPython component and the grasshopper file)…
rmation?" I know that this can already be accomplished using the brilliant Kangaroo plugin, but I wanted a simpler and faster (yet still accurate) single component that could replicate this unique curve using a variety of inputs: the length of the rod/wire, the width/distance between the endpoints, the height of the bend, and the tangent angle at the start. I also wanted make the unknowns (such as height if only length and width are known) easily accessible for plugging into additional components.
The resulting script, being an all-in-one solution, is somewhat unwieldy, but it could easily be broken down into smaller components (custom .gha's which I don't have the ability to code). If someone wants to tackle this, please do! I'm not an expert coder by any means, and as this was only my second time diving into Grasshopper scripting, if the script seems somewhat strange, that's probably why. I did try to comment the code pretty well though. Here's the full description:
--------------------------------------------------
DESCRIPTION: This beast creates the so-called 'elastica curve', the shape a long, thin rod or wire makes when it is bent elastically (i.e. not permanently). In this case, force is assumed to only be applied horizontally (which would be in line with the rod at rest) and both ends are assumed to be pinned or hinged meaning they are free to rotate (as opposed to clamped, when the end tangent angle is fixed, usually horizontally). An interesting finding is that it doesn't matter what the material or cross-sectional area is, as long as they're uniform along the entire length. Everything makes the same shape when bent as long as it doesn't cross the threshold from elastic to plastic (permanent) deformation (I don't bother to find that limit here, but can be found if the yield stress for a material is known).
Key to the formulas used in this script are elliptic integrals, specifically K(m), the complete elliptic integral of the first kind, and E(m), the complete elliptic integral of the second kind. There was a lot of confusion over the 'm' and 'k' parameters for these functions, as some people use them interchangeably, but they are not the same. m = k^2 (thus k = Sqrt(m)). I try to use the 'm' parameter exclusively to avoid this confusion. Note that there is a unique 'm' parameter for every configuration/shape of the elastica curve.
This script tries to find that unique 'm' parameter based on the inputs. The algorithm starts with a test version of m, evaluates an expression, say 2*E(m)/K(m)-1, then compares the result to what it should be (in this case, a known width/length ratio). Iterate until the correct m is found. Once we have m, we can then calculate all of the other unknowns, then find points that lie on that curve, then interpolate those points for the actual curve. You can also use Wolfram|Alpha as I did to find the m parameter based on the equations in this script (example here: http://tiny.cc/t4tpbx for when say width=45.2 and length=67.1).
Other notes:
* This script works with negative values for width, which will creat a self-intersecting curve (as it should). The curvature of the elastica starts to break down around m=0.95 (~154°), but this script will continue to work until M_MAX, m=0.993 (~169°). If you wish to ignore self-intersecting curves, set ignoreSelfIntersecting to True
* When the only known values are length and height, it is actually possible for certain ratios of height to length to have two valid m values (thus 2 possible widths and angles). This script will return them both.
* Only the first two valid parameters (of the required ones) will be used, meaning if all four are connected (length, width or a PtB, height, and angle), this script will only use length and width (or a PtB).
* Depending on the magnitude of your inputs (say if they're really small, like if length < 10), you might have to increase the constant ROUNDTO at the bottom
REFERENCES: {1} "The elastic rod" by M.E. Pacheco Q. & E. Pina, http://www.scielo.org.mx/pdf/rmfe/v53n2/v53n2a8.pdf {2} "An experiment in nonlinear beam theory" by A. Valiente, http://www.deepdyve.com/lp/doc/I3lwnxdfGz {3} "Snap buckling, writhing and Loop formation In twisted rods" by V.G.A. GOSS, http://myweb.lsbu.ac.uk/~gossga/thesisFinal.pdf {4} "Theory of Elastic Stability" by Stephen Timoshenko, http://www.scribd.com/doc/50402462/Timoshenko-Theory-of-Elastic-Stability (start on p. 76)
INPUT: PtA - First anchor point (required) PtB - Second anchor point (optional, though 2 out of the 4--length, width, height, angle--need to be specified) [note that PtB can be the same as PtA (meaning width would be zero)] [also note that if a different width is additionally specified that's not equal to the distance between PtA and PtB, then the end point will not equal PtB anymore] Pln - Plane of the bent rod/wire, which bends up in the +y direction. The line between PtA and PtB (if specified) must be parallel to the x-axis of this plane
** 2 of the following 4 need to be specified ** Len - Length of the rod/wire, which needs to be > 0 Wid - Width between the endpoints of the curve [note: if PtB is specified in addition, and distance between PtA and PtB <> width, the end point will be relocated Ht - Height of the bent rod/wire (when negative, curve will bend downward, relative to the input plane, instead) Ang - Inner departure angle or tangent angle (in radians) at the ends of the bent rod/wire. Set up so as width approaches length (thus height approaches zero), angle approaches zero
* Following variables only needed for optional calculating of bending force, not for shape of curve. E - Young's modulus (modulus of elasticity) in GPa (=N/m^2) (material-specific. for example, 7075 aluminum is roughly 71.7 GPa) I - Second moment of area (or area moment of inertia) in m^4 (cross-section-specific. for example, a hollow rod would have I = pi * (outer_diameter^4 - inner_diameter^4) / 32 Note: E*I is also known as flexural rigidity or bending stiffness
OUTPUT: out - only for debugging messages Pts - the list of points that approximate the shape of the elastica Crv - the 3rd-degree curve interpolated from those points (with accurate start & end tangents) L - the length of the rod/wire W - the distance (width) between the endpoints of the rod/wire H - the height of the bent rod/wire A - the tangent angle at the (start) end of the rod/wire F - the force needed to hold the rod/wire in a specific shape (based on the material properties & cross-section) **be sure your units for 'I' match your units for the rest of your inputs (length, width, etc.). Also note that the critical buckling load (force) that makes the rod/wire start to bend can be found at height=0
THANKS TO: Mårten Nettelbladt (thegeometryofbending.blogspot.com) Daniel Piker (Kangaroo plugin) David Rutten (Grasshopper guru) Euler & Bernoulli (the O.G.'s)
--------------------------------------------------
Edit: More on the math behind this here.
Cheers,
Will
…
Added by Will McElwain at 4:08pm on February 26, 2014
east make all our algorithms thread-safe, so they can all be called from multiple threads, this is the first step towards multi-threading.
But multi-threading is not just something you switch on or off, it's an approach. Let's take the meshing of Breps for example. Let's assume that at some point one or more breps are added to the document. The wireframes of these breps can be drawn immediately, but the shading meshes need to be calculated first. How do we go about doing this? Allow me to enumerate some obvious solutions:
We put everything on hold and compute all meshes, one at a time. Then, when we're done we'll yield control back to the Rhino window so that key presses and mouse events can once again be processed. This is the simplest of all solutions and also the worst from the users point of view.
We allow the views to be redrawn, mouse events and key presses to be handled, but we perform the meshing in a background thread. I.e. whatever processor cycles are left over from regular use are now put to work on computing meshes. Once we're done computing these meshes we can start drawing the shaded breps. This is a lot better as it doesn't block the UI, but it also means that for a while (potentially a very long time) our breps will not be shaded in the viewport. This approach is already a lot harder from a programming perspective because you now have multiple threads all with access to the same Breps in memory and you need to make sure that they don't start to perform conflicting operations. Rhino already does this (and has been doing for a long time) on a lot of commands, otherwise you wouldn't be able to abort meshing/intersections/booleans etc. with an Escape press.
So we can compute the meshes on the UI-thread or on a background thread. How about using our multiple cores to speed up the process? Again, there are several ways in which this can be achieved:
Say we have a quad-core machine, i.e. four processors at our disposal. We could choose to assign the meshing of the first brep to the first processor, the second brep to the second processor, the third brep to the third processor and so on. Once a processor is done with the meshing of a specific brep, we'll give it the next brep to mesh until we're done meshing all the breps. This is a good solution when multiple breps need to be meshed at once, but it doesn't help at all if we only need to compute the mesh for a single brep, which is of course a very common case in Rhino.
To go a level deeper, we need to start adding multi-threading to the mesher itself. Let's say that the mesher is set up in such a way that it will assign each face of the brep to a new core, then -once all faces have been meshed- it will stitch together the partial meshes into a single large mesh. Now we've sped up the meshing of breps with multiple faces, but not individual surfaces.
We can of course go deeper still. Perhaps there is some operation that is repeated over and over during the meshing of a single face. We could also choose to multi-thread this operation, thus speeding up the meshing of all surfaces and breps.
All of the above approaches are possible, some are very difficult, some are actually not possible if we're not allowed to break the SDK. A further problem is that there's overhead involved with multi-threading. Very few operations will actually become 4 times faster if you distribute the work across 4 cores. Often one core will simply take longer than the other 3, often the partial results need to be aggregated which takes additional cycles and/or memory. What this means is that if you were to apply all of the above methods (multi-thread the meshing of individual faces, multi-thread the meshing of breps with multiple faces and multi-thread the meshing of multiple breps) you're probably worse off than you were before.
--
David Rutten
david@mcneel.com
Poprad, Slovakia
* an example would be the z-sorting of objects in viewport prior to repainting, which is a step performed on every redraw as far as I know.…
e current data should be turned to be original data, is that right?there are 3 cases.
what do this components effect the performance after if i turn the component to be flatten and graft and to connect to other component?
{, is that0}
{0;0}
{0;0;0}
{0;0;0;0}
{0;0;0;0;0}
{0;0;0;0;0;0}…
with this machine.
As Jason says, Rhino and Grasshopper are mainly single-threaded, so I prioritized single core speed and got an i7 4790k, which comfortably overclocks to 4.7GHz (with a decent air cooler, but no fancy liquid cooling).
The Kangaroo2 solver is actually multi-threaded now, but the difference this makes is not great as you might imagine. Using 4 cores is certainly nowhere near 4 times faster, because although parts of the calculation are easily parallelized, everything still needs to be recombined at each iteration, and this is usually the bottleneck. I think there is still room for some improvement in how it is multi-threaded, but I wouldn't hold your breath for any massive changes on this front soon.
I'd be interested to know how the performance scales with the Xeon chips (more cores, significantly more expensive, but relatively low clock speeds). At the time I made the guess that they weren't worth it, but it would be good to really test this out.
RAM is relatively cheap these days, so I went with 32GB of it at 2133MHz. It does seem that the speed of the RAM matters, as enabling XMP in the BIOS (to make it run above the default 1333) seemed to make a noticeable difference.
Graphics-wise my personal feeling is that the gaming oriented GTX cards offer better value than the much more expensive 'professional' Quadro range - and have read that the hardware between the 2 has historically been very similar or even identical despite the Quadros being several times the price, with the difference being mainly in the drivers. There are some threads on discourse.mcneel.com about this, and it seems that recent GTX cards like the 970 do very well in Holomark (the Rhino performance benchmarking tool).
I got a GTX 770 (this was just before the 900 series came out), which is probably way overkill just for Rhino/Grasshopper, as they don't use the GPU for more than display (Though some of the render plugins do, and I think for those more CUDA cores is what matters, so there GTX is probably still better value.)
Probably swapping this for a much cheaper card wouldn't make much difference to Rhino/GH performance anyway (though if you want to use the PC for other stuff like gaming or virtual reality it does).
I don't have much experience with AMD cards, so can't comment on how they compare to Nvidia.
Eventually I do hope to make Kangaroo run the physics on the GPU, and potentially this does have a big speed impact. Nvidia recently released some impressive demos of their FLEX engine, which really fly with a decent graphics card. That is very much game-physics, and not suitable for most of the things Kangaroo is used for, but theoretically Kangaroo could also be adapted to use CUDA (or OpenCL), though it involves a lot of big changes, and I don't have a timeline for this yet.
In the much shorter term there are some things in the pipeline that should speed up Kangaroo for certain things like collisions between large numbers of objects, just by using some different algorithms.
Altogether my machine was still well under €2K, and I've been really happy with it. That said, the difference in performance between this and my 4 year old €700 i5 laptop is actually not that huge in day-to-day Grasshopper usage. It does seem that there is a strong case of diminishing returns with buying a PC - I'd hazard a guess that even spending 3 times this amount (as another thread on this forum was discussing recently) you'd be hard pushed to get anything that made a really significant difference to the experience of using it, and if you really want to spend more money, you would be better off just upgrading more frequently (and getting a nice monitor(s)).
Anyway, a long ramble, I hope some of it is useful. As I said, I'm no hardware expert, and would be interested to hear different opinions.
I also think it will be nice to make a simple benchmarking tool for Kangaroo and have people run it on their various machines and report back results (as with Holomark), to help others make informed decisions on these things. I'll try and put something together for this soon.
…
onents (radiation, sunlight-hours and view analysis) which let you study the effect of the orientation of your building and the analysis result. When you come to a question similar to "what is the orientation that the building receives the most/least amount of radiation?" is probably the right time to use this component.
HOW?
I'll try to explain the steps using a simple example. Here is my design geometries. The building in the center is the building to be designed and the rest of the buildings are context. I want to see the effect of orientation on the amount of the radiation on the test building surfaces from the start of Oct. to the end of Feb. for Chicago.
First I need to set up the normal radiation analysis and run it for the building as it is right now. [I'm not going to explain how you can set up this since you can find it in the sample file (Download the sample file from here)]
Now I need to set up the parameters for orientation study using orientationStudyPar component. You can find it under the Extra tab:
At minimum I need to input the divisionAngle, and the totalAngle and set runTheStudy to True. In this case I put 45 for divisionAngle and 180 for the totalAngle which means I want the study to be run for angles 0, 45, 90, 135 and 180.
[Note1: The divisionAngle should be divisible by totalAngle.]
[Note 2: If you don't provide any point for the basePoint, the component will use the center of the geometry as the center of the rotation.]
[Note 3: You can also rotate the context with the geometry! Normally you don't have the chance to change the context to make your design work but if you got lucky the rotateContext input is for you! Set it to True. The default is set to False.]
You're all set for the orientation study, just connect the orientationStudyPar output to OrientationStudyP input in the component and wait for the result!
The component will run the study for all the orientations and preview the latest geometry. To see the result just grab a quick graph and connect it to totalRadiation. As you can see in the graph 135 is the orientation that I receive the maximum radiation. Dang!
If you want to see all the result geometries set bakeIt to True, and the result will be baked under LadyBug> RadaitionStudy>[projectname]> . The layer name starts with a number which is the totalRadiation.
Mostapha…
doing this with the current tools or a bit of scripting since the Flickr API allows you to make requests in a REST format, but utilizing the Flickr.net API library makes it much simpler.
First and foremost, you need a Flickr API key...do you have one of those?
A great way to get to know the Flickr API is with the API Explorer. Here is a link to the page for the flickr.photos.search method explorer: http://www.flickr.com/services/api/explore/flickr.photos.search
The cool thing about this page is that it generates the REST Http call towards the bottom. So, here is what I did:
1. Grab the coordinates of the bounding box per Flickr API request:
bbox (Optional)
A comma-delimited list of 4 values defining the Bounding Box of the area that will be searched. The 4 values represent the bottom-left corner of the box and the top-right corner, minimum_longitude, minimum_latitude, maximum_longitude, maximum_latitude. Longitude has a range of -180 to 180 , latitude of -90 to 90. Defaults to -180, -90, 180, 90 if not specified. Unlike standard photo queries, geo (or bounding box) queries will only return 250 results per page. Geo queries require some sort of limiting agent in order to prevent the database from crying. This is basically like the check against "parameterless searches" for queries without a geo component. A tag, for instance, is considered a limiting agent as are user defined min_date_taken and min_date_upload parameters — If no limiting factor is passed we return only photos added in the last 12 hours (though we may extend the limit in the future).
So, I went to Google Earth, picked a city (London, UK) and dropped two pins:
This gave me two locations, which I can put into the Explorer Page next to the bbox option. Here is what I put for these two points: -0.155941,51.496768,-0.116783,51.511431
2. Check has_geo
3. In extras, type in geo
4. Make the call!
You will see a list of responses in an XML format, these responses will be from the first page. Geolocated photos are limited to 250 / page, so you will have to grab them page by page.
If you want to add more options (minimum upload date, maximum upload date, etc) you can do this as well)
The best is at the bottom, you get the full http call for this: http://api.flickr.com/services/rest/?method=flickr.photos.search&api_key=ffd44f601393a46e86aa3a5f8a013360&bbox=-0.155941%2C51.496768%2C-0.116783%2C51.511431&has_geo=&extras=geo&format=rest&api_sig=b42330e5d1523bd5fe60c2ad43acde99
Notice this call has some other api key, you should eventually replace this with your own.
You could copy and paste this into a browser and you will get the results with the latitude and longitude:
So this is really what you need to know to do this through GH. Since gHowl has an XML parser component that can access files on the web, you should be able to use the same http call into this component.
Eventually, we get a response, and we need to grab the lat and lon data. With gHowl we can map these to xyz coordinates, and generate the heatmap...this is just a linear mapping:
Attached are both the Rhino file and the Grasshopper file, as well as the image underlay.
I am working on a series of components that makes this more straightforward, but for now, this should get you started.
…
n be obtained for curved NURBS surfaces as well as unconventional window configurations".
And I also noticed the following information form the optional input in the runEnergySimulation component.
"meshSettings_: Optional mesh settings for your geometry from any one of the native Grasshopper mesh setting components. These will be used to change the meshing of curved surfaces before they are run through EnergyPlus (note that meshing of curved surfaces is done since Energyplus is not able to calculate heat flow through non-planar surfaces). Default Grasshopper meshing is used if nothing is input here but you may want to decrease your calculation time by changing it to Coarse or increase your curvature definition (and calculation time) by making it finer".
1) My case is an one-story, rectangular-plan large hall (40m*70m*25m) with a curved roof. The roof surface is a part of a standard sphere and the walls and floor are all planar (the each wall has one curved edge as showed in the image).
For testing, I threw the original curved roof surface into daylight and energy simulations without making customized meshings, because I assumed that it might be automatically converted to meshs by Honeybee - Am I right? As showed in the image, how can I reduce the number of meshs in a proper way? Must two connected surfaces (i.e. wall and roof) be STRICTLY/SEAMLESSLY connected or not (considering different divisions of meshs in the respective surface)? - Is a connection tolerance allowed?
2) But, when I run the annual daylight simulation for this case, it gave me a lot of warnings "oconv: warning - zero area for polygon".- is that normal? and how to avoid this? Does the daylight simulation allow "curved NURBS surfaces"?
3) Moreover, when I run an energy simulation for this case, it costed extremely long time. It was just so long that I did not even have results out of one simulation. - I guessed it might be the problem caused by the curved roof surface (or automatic meshing?), but I don't have experience of converting a curved NURBS/spheral surface into correct meshs that can be recognized by Honeybee simulations (Daylight and Energy) in a proper way.
4) The large window on the wall was generated by the "_glzRatio". But the automatically generated wall meshs around this window are just too "fine", which might largely increase simulation time. Is there a proper way to get rid of it? (Considering that the size, shape and position of the window will have large influence on the daylight distribution in the building, it is worthy to keep the size, shape and position of the window as it should be in reality).
In sum, considering all above, could your please provide me some suggestions/tutorials/links that might be helpful for dealing with "curved NURBS surfaces" in Honeybee simulations.
Thank you all in advance!
Best,
Ding
…