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
nds except only using CreateHBSrfs which can be unstable for me with some geometry (GH crashes).
If you want proof of the rotation not taking place using MSH2RAD, please look in the Daysim*.rad file that gets created when performing a Daysim simulation.
See example below. The same polygon is processed via the CreateHBSrs component and via the MSH2RAD component. The polygon gets rotated 90 degrees using CreateHBSrs but unfortunately not with MSH2RAD:
_______________
##GENERATED BY HONEYBEE
OPAQUE polygon b69a317a402d42c1994f410463cd_00 0 12 -15.824400 -5.615800 0.000000 -15.824400 -44.175400 0.000000 -15.824400 -44.175400 28.363100 -15.824400 -5.615800 28.363100
# SOURCE FILE: c:\ladybug\000000_TEST\SURR\MSH2RADFiles\SURR.rad
## c:\radiance\bin\\obj2rad -f c:\ladybug\000000_TEST\SURR\MSH2RADFiles\SURR.obj## OBJ file written by TurtlePyMesh
OPAQUE polygon object_1.10 0 12 44.175400 -15.824400 28.363100 5.615820 -15.824400 28.363100 5.615820 -15.824400 0.000000 44.175400 -15.824400 0.000000
_______________
All the best
-M…
what i want.
My intention is that the Randomly selected brick be rotated 90 degrees so that header face is proud of the actual wall face rather than stretcher face.
I can easily rotate the selected bricks and then protrude them in the desired direction. However, if i rotate the brick a gap is created on either side of rotated brick (refer sketch 1). I want to set a parameter that CLOSES THAT GAP, so that the wall remains watertight (refer sketch 2).
Brick size used 230mm (L) x 76mm(W) x 70mm(H).
Attached are
1) 1-Sketch: Explaining my conundrum
2) 2-Sketch: Explaining what i want to achieve
3) 3-Perspective: Baked Geometry of what i have achieved so far
Please feel free to ask for my GH definition if required.
I'm an absolute dummy in VB scripting.
So insight to solve my conundrum will be highly appreciated.
Cheers
…
if i select one by one and it shows
and also, select different amount of curves shows different angles[same curve]but the most important thing is all of them are wrong angles,
if i draw some 90 degree curve, the answer is right.
thank guys…
whole design intent, but this is what Inventor is good at. The way it packages bits of 'scripted' components into 'little models' that can be stored and re-assembled is central to MCAD working.
The Inventor model shown is almost 5 years old. We don't model like that any more, however it does offer a good idea of general MCAD modeling approaches.
iParts is useful in certain situations, it could've been useful in the above model, its usefulness is often in function of the quantity of variants/configurations.
So much is scripted in GH, maybe it should also be possible to script/define/constrain/assist the placement/gluing of the results?
...
Starting point: I think we are talking across purposes. AFAIK, the solving sequence of GH's scripted components is fixed. It won't do circular dependencies... without a fight. The inter-component dependencies not 'managed' like constraints solvers do for MCAD apps.
Components and assemblies are individual files in MCAD.
Placement of these within assemblies in MCAD is a product of matrix transforms and persistent constraints. There is no bi-directional link, the link is unidirectional (downflow only), because of the use of proxies.
Consequently, scripting the placement of components is irrelevant in GH, unless you decide that each component needs to be contained in its own separate file.
This also brings up the point that generating components and assemblies in MCAD is not as straightforward. In iParts and iAssemblies, each configuration needs to be generated as a "child" (the individual file needs to be created for each child) before those children can be used elsewhere.
You notice the dilemma, if you generate 100 parts, and then you realize you only need 20, you've created 80 extra parts which you have no need for, thus generating wasteful data that may cause file management issues later on.
GH remains in a transient world, and when you decide to bake geometry (if you need to at all), you can do that in one Rhino file, and save it as the state of the design at that given moment. Very convenient for design, though unacceptable for most non-digital manufacturing methods, which greatly limits Rhino's use for manufacturing unless you combine it with an MCAD app.
One of the reasons why the distributed file approach makes perfect sense in MCAD, is that in industry you deal with a finite set of objects. Generative tools are usually not a requirement. Most mechanical engineers, product engineers and machinists would never have any use for that.
The other thing that MCAD apps like Inventor have, is the 'structured' interface that offers up all that setting out information like the coordinate systems, work planes, parameters etc in a concise fashion in the 'history tree'. This will translate into user speed. GH's canvas is a bit more freeform. I suppose the info is all there and linked, so a bit of re-jigging is easy. Also, see how T-Flex can even embed sliders and other parameter input boxes into the model itself. Pretty handy/fast to understand, which also means more speed.
True. As long as you keep the browser pane/specification tree organized and easy to query.
:)
Would love to understand what you did by sketching.
I'll start by showing what was done years ago in the Inventor model, and then share with you what I did in GH, but in another post.
Let's use one of the beams as an example:
We can isolate this component for clarity.
Notice that I've highlighted the sectional sketch with dimensions, and the point of reference, which is in relation to the CL of the column which the beam bears on. The orientation and location of the beam is already set by underlying geometry.
Here's a perspective view of the same:
The extent of the beam was also driven by reference geometry, 2 planes offset from the beam's XY plane, driven by parameters from another underlying file which serves as a parameter container:
Reference axes and points are present for all other components, here are some of them:
It starts getting cluttered if you see the reference planes as well:
Is I mentioned earlier, over time we've found better ways to define and associate geometry, parameters, manage design change, improving the efficiency of parametric models. But this model is a fair representation of a basic modeling approach, and since an Inventor-GH comparison is like comparing apples and oranges anyways, this model can be used to understand the differences and similarities, for those interested.
I haven't even gotten to your latest post yet, I will eventually.…
Added by Santiago Diaz at 10:36am on February 26, 2011
he picture (4).
Previously, I had a problem with generating intersections between the two directions of the beams, but a colleague helped me by extending beams, so there was no problem with lines of intersection. But this solution has generated curl (5) at the highest vertex geometry, which I ignored in order to repair it before printing, perhaps this mean my problem with my beam spread properly. Only when the beams is 19, does not jump no problem, but I still can not distribute them properly.
(1)
(2)
(3)
(4)
(5)
I tried to show as simply as possible by removing or signing my code in GHX file.
Thank you in advance for your help
…
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.
…
f my list.I don't understand why, but I guess I must be too young user ^^In the original list, i have a path {0;0;0;4} with two index and after the random node, {0;0;0;4} has 88 index.Items are not correct?I would have a comparable structure has the right list on my jpg (photomontage...)How I can do that?Thank you in advance
…
he concept, moving on to decision making and continuing with digital and generative design tools TO GET THE BEST SOLUTION for each problem.
WHY? The world is complex and ever-changing and we need to be able to handle the volume of information we receive and, of course, to find and choose the best solution. Therefore, we direct our ATTENTION TO THE CAUSE, and not only on the effects/solutions.
We will learn from NATURE, the only “company” that has not gone bankrupt in over 4000M years, and it’s GENERATIVE SOLUTIONS.
> OBJECTIVES <
The participants will work in multidisciplinary groups (ex. architect + designer + business manager + constructor + communication specialist etc.) applying knowledge management tools, different approaches and nature-based optimization methods.
Listed objectives:
1. Improving the generative way of TURNING AN IDEA INTO A PROJECT through problem-solving thinking
2. Discovering nature’s ways of shaping evolutionary solutions
3. Getting out from our comfort zone and working together with other professionals in groups in order to achieve better solutions: Multidisciplinary Design Optimization
4. Learning to use technology to manage information in the decision making process
& surviving the whole week
> ATTENDANCE & COSTS <
> Early bird – until 17th March 2013
Lecture – 15 euro (includes presentations, food& drinks)
Workshop – 100 euro (includes lecture, food& drinks)
> Late bird – until 6th April 2013
Lecture – 25 euro (includes presentations, food& drinks)
Workshop – 120 euro (includes lecture, food& drinks)
…