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…
H are automated by using them as an ActiveX, the C# script object fails on the simplest tasks. That is, when initiating Rhino and GH externally (as by the following C# code):
Rhino5Application rhino_app = new Rhino5Application();
dynamic grasshopper = newRhino.rhino_app.GetPlugInObject("b45a29b1-4343-4035-989e-044e8580d9cf", "00000000-0000-0000-0000-000000000000") as dynamic;
The following very simple C# script component fails because it cant cast its input:
The c# code at the component is only:
Line 89 is simply casting of the input. Clearly, this makes the usage of C# component, under automation, impossible which is a major loss.
As said, when initiating Rhino and GH manually , all works well as in the following:
Any ideas why it misbehaves under automation (as an Active X ) ?
I added the gh file of this example.…
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.
…
robablemente las uniones son forzadas/rotadas levemente para que calcen.
Probablemente se puede variar el angulo de 90° entre cada pieza a un angulo que permita crear el octagono perfecto, pero habría dos posibilidades de giro entre cada pieza.
Tal vez el problema hay que repensarlo desde el octagono/poliedro que forman los triangulos en el modelo y luego generar los triangulos.
Bueno aca mi definicion y algunos comentarios:
- Hoopsnake pide una condicion inicial que solo la utiliza en la primera iteracion (input S).
- Luego hay que definir el algoritmo reiterativo/recursivo que es toda la parte de abajo. Como input se utiliza el output S de hoopsnake (en la primera iteracion es la misma informacion que ingresaste en S).
El resultado de este algoritmo/proceso vuelve a ingresar a hoopsnake en el input D para una nueva iteración.
- El output H es el historial de toda la geometria/datos procesados en las iteraciones.
Ahora te explico el algoritmo:
- Se toma el triangulo y se sacan los puntos en las esquinas.
- Se revisa si los puntos estan contenidos en otro triangulo existente y hago cull para dejar los libres (ocupo el output H del hoopsnake para ver los triangulos de las iteraciones anteriores). En la primera iteracion hago un bypass para dejar todos los puntos iniciales libres (ya que no hay historial en el hoopsnake).
- La parte de abajo es para elegir una de las dos opciones max disponibles (tu comentaste arriba que habia tres opciones... en realidad son tres opciones en la inicial, luego son solo dos opciones. No se que va a pasar si se se completa el octagono, teoricamente habría solo 1 opcion disponible, pero no pude reproducirlo por el problema geometrico).
A modo de ejemplo, en la imagen le deje todas las opciones disponibles y conecte directamente (dos para el triangulo) para tratar de generar los octagonos.
- La parte final es simple, desde el centro del triangulo se genera una linea hacia las opciones disponibles para generar un plano perpendicular para la simetria y luego se rota en 90° (que creo debería ser otro angulo). Puedes mover el slider del plano perpendicular para generar la interseccion deseada en los triangulos (0.5 para interseccion completa).
Como ya te indicaron, yo tampoco hice el tema de las areas.. pero deberia ser simple en mi definición: Calculas el area del output H (triangulos), aplicas flatten, mass addition y si el numero resultante es mayor al area de la placa que quieres, debería generar un valor falso que va en el input B de hoopsnake.
Sorry que no haya ocupado tu definicion, pero ocupe un grasshopper antiguo y ademas ya había solucionado un problema similar con un alumno el semestre pasado, asi que realicé lo que me acordaba :D
Saludos y suerte!
…
Salimzadeh
Assistant: Saeede Kalantari a Fabrication Project for “Structural Systems” BA Course;
Participants: Maryam Ahmadi, Amir Ansaripour, Kimia Bagheri, Mohammad Hassan Habibi, Mohammad Mehdi Zamani, Sam Sabzevari, Zeynab Seyed Zehtab, Mohammad Mehdi Shahroudi, Niloofar Taheri, Masoumeh Abedini, Pedram Feyzi, Asma Karamouz, Kimia Karbalayi, Hamed Kamalzadeh, Fateme Kianinejhad, Maryam Mohammaddoust, Faeze Motamedian, Romina Mehrbod, Sara Naderi, Yasaman Nejati, Kimia Nourinejhad, Morteza Vaziri, Mehragin Baghi, Sana Motallem, Helpers: Milad Amiri, Soroush Raesi, Mahla Behrouz, Alireza Sheykhlar, Shadi Khaleghi, Mohaddese Taheri, Alireza Mohammadi, Mehrnoush Kia
Photography: Sara Ahmadi, Hasan Habibi
Video production: Shayan Khalilbeigi
Special Thanks To Dr. K. Taghizadeh, Dr. H. Mazaherian, Dr. Y. Eslami and Mr.Aliari
With Support Of: Center Of Excellency In Architecture Technology – CEAT - , Collage of Fine Arts University of #Tehran, ‘Art And 4th Dimension’ Symposium, Iran #Fablab and #Fologram
Rhino/Grasshopper and C# Definitions of form-Finding and Member-generation :
http://bit.ly/2RUKc5i…