is Radius = (size+40)/(2*Pi), where "size" is the value to give, it's usually used in countries like Spain, Italy, Netherlands, Switzerland... The next release will have 6 ways (5 regional system + diameter) to give it the size in different regional systems with just two clicks, in fact, the rings of the next release are already developed, but will have to wait...
Knowing that:
ISO (International Organization for Standardization). mm of internal circunference. Austria, France, Germany, Belgium, Scandinavia...
radii = Size / (2 * Math.PI)
European Size. Spain, Italy, Netherlands, Switzerland...radii = (Size + 40) / (2 * Math.PI)
British Size. United Kingdom, Ireland, Australia, New Zealand, South Africa...radii = ((Size * 0.4) + 11.5) / 2
American Size. United States, Canada, Mexico...radii = ((Size * 0.83) + 11.54) / 2
Japanese Size. Japan, China, India, South America...radii = ((Size / 3) + 12.67) / 2
Diameter Size. Many goldsmiths anywhere.
radii = Size / 2
Source: http://www.18carat.co.uk/ringsizes.html
and since this release are UserObject componentes, you can remplace if you want the Size component with one new. For example, right clicking size_param, going to Expresion and setting x*pi-40, the size input will be the diameter of the resulting circle, if you give it a value of 14, the circle will have a radius of 7. Then save the userobject (File>Create User Object) and remove the other.
Or create a new one, since this component is just a rotated circle and a cylinder.
Hope this helps.…
.Besides these two output, it calculates the solar position (elevation angle and azimut) considering the atmospheric refraction.I saw the difference between solInitOutput (based on Radiance) and the script that I wrote (based on NOAA). Some formulas are the same, while others are different. for example "Julian day", "solar altitude"..Anyway, they are two different models.At the moment the imputs are:1) location2) analysis period3) yearand the outputs are:1) civil twilight2) official sunrise/sunset3) solar elevation angle4) solar azimutThis is an example where I used data of a real place.
and these are two photos that I took in this place.
SUNRISE (Civil Twilight) 06:44 AM
SUNRISE (Official) 07:14 AMNote that in the first photo the street lights are on, while in the second are off because of the good level of luminous energy.I hope that it could be useful.
BestsAntonello…
he sunPath component works. For example if you want to simulate the hours from 8 to 16 it means you want 8 hours from 8 to 9, from 9 to 10,.... from 15 to 16 (8 hours duration period) so you get from the sunPath component (using default timeStep 1) the 9 sun position/vectors 8 9 10 11 12 13 14 15 16 (in the image the yellow suns). The things is that if you ask for a smaller timeStep for example 3 = 20 mins then the additional sun position (in the image the orange suns) are added also after the time limit of h16 so probably when you don't want/need. I understand that when you input a time period there is the ambiguity if the hours are the just 9 (the 9 inputs) or the 8 hours included between pairs of hours, but I would make in a way that it is possible to chose if the extra timeStep after the last hour are added or not. Thank you for your comments.
…
e forces which are used with Kangaroo. I would like a model which is build according to it's geometrical relations. I started to make the base pattern, this worked out. The base pattern is constructed with the rectangular square in the middle, these points stay on the same position. Than 4 points (Points 1,7,8 and 14 in the GH-file) are created by taking a point on a circle with the corner points from the rectangle as center and the lines of the rectangle as normal. The remaining 4 points are created with knowledge of the distance of those points to it's connected points. Each point has a known distance between itself and 3 other points. So the intersection point with the correct angle (because the line has to be a mountain-fold) is taken. This makes the base pattern. But now I'm struggling to make this base pattern into a larger tessellation. The goal is to create a parametric model which can controlled over the following parameters:
- Size- Number of tessellations
- Controlling the folding angles of degrees of freedom of the model
Attached to this post I have the Grasshopper file of the base pattern which is described in this post and a pictures of the tessellation (first the base pattern and a 2x2 pattern).
Has anybody a suggestion how to model a folding pattern like this with the Kangaroo plug-in?…
ocessed once Grasshopper is done with whatever it's doing now.
3) Grasshopper tells the Slider object that the mouse moved and the slider works out the new value as implied by the new cursor position.
4) The slider then expires itself and its dependencies ([VB Step 1] in this case, but there can be any number of dependent objects).
5) When [VB Step 1] is expired by the slider, it will in turn expire its dependencies (VB Step 2), and so on, recursively until all indirect dependencies of the slider have been expired.
6) When the expiration shockwave has subsided, runtime control is returned to the slider object, which tells the parent document that stuff has changed and that a new solution is much sought after.
7) The Document class then iterates over all its objects (they are stored in View order, not from left to right), solving each one in turn. (Assuming the object needs solving, but since in your example ALL objects will be expired by a slider change, I shall assume that here).
8) It's hard to tell which object will get triggered first. You'd have to superimpose them in order to see which one is visually the bottom-most object, but let's assume for purposes of completeness that it's the [VB Step 1] object which is solved first.
9) [VB Step 1] is triggered by the document, which causes it to collect all the input data.
10) The input parameter [x] is asked to collect all its data, which in turn will trigger the Slider to solve itself (it got expired in step 4 remember?). This is not a tricky operation, it merely copies the slider value into the slider data structure and shouts "DONE!".
11) [x] then collects the number, stores it into its own data structure and returns priority to the [VB Step 1] object.
12) [VB Step 1] now has sufficient data to get started, so it will trigger the script inside of it. When the script completes, the component is all ready and it will tell the parent document it can move on to the next object (the iteration loop from step 7).
13) Let us assume that the slider object is next on the list, but since it has already been solved (it was solved because [VB Step 1] needed the value) it can be skipped right away, which leaves us with the last object in the document which is still unsolved.
14) [VB Step 2] will be triggered by the document in very much the same way as [VB Step 1] was triggered in step 9. It will also start by collecting all input data.
15) Since all the input data for [VB Step 2] is either defined locally or provided by an object which has already been solved, this process is now swift and simple.
16) Upon collecting all data and running the user script, the component will surrender priority and the document becomes active again.
17) The document triggers a redraw of the Grasshopper Canvas and the Rhino viewports and then surrenders priority again and so on and so forth all the way up the hierarchy until Grasshopper becomes idle again.
[end boring]
Pretty involved for a small 3-component setup, but there you have it.
To answer somewhat more directly your questions:
- The order in which objects are solved is the same as the order in which they are drawn. This is only the case at present, this behaviour may change in the future.
- Adding a delay will not solve anything, since the execution of all components is serial, not parallel. Adding a delay simply means putting everything on hold for N milliseconds.
- [VB Step 1] MUST be solved prior to [VB Step 2] because otherwise there'd be no data to travel from [GO] to [Activate]. The only tricky part here is that sometimes [VB Step 1] will be solved as part of the process of [VB Step 2], while at other times it may be solved purely on its own merits. This should not make a difference to you as it does not affect the order in which your scripts are called.
--
The Man from Scene 24…
Added by David Rutten at 4:43pm on December 10, 2009
rametriche all’interno del processo progettuale, approfondendo l’utilizzo di Grasshopper in sinergia con plug-in, software di analisi ambientale e simulazione fisica. Obiettivo fondamentale è la generazione della forma come risultato di tecniche di form-finding e di input ambientali (solari, termici e acustici). Verranno acquisiti nuovi strumenti operativi e di simulazione al fine di costruire modelli parametrici ottimizzati in grado di adattarsi a diverse condizioni di contesto.
tutors: Arturo Tedeschi + Maurizio Degni
Arturo Tedeschi_autore del primo libro su Grasshopper "Architettura Parametrica"__Authorized Rhino Trainer__co-director della AA Rome Visiting School - Architectural Association School (London).
info + prenotazioni: http://www.arturotedeschi.com/wordpress/?project=ecologic-patterns_...…
comerciales. Rhino permite comunicar ideas en el desarrollo, investigación, manufactura, marketing y proceso de construcción de un producto o espacio, antes de ser construido y genera documentos constructivos para la elaboración de los mismos. Permite exportar los archivos a las extensiones comerciales más utilizadas en la industria como DXF, DWG, Illustrator y 3ds entre muchos otros. La gran cantidad de extensiones suplen las necesidades especificas para arquitectura, diseño de producto, calzado, joyería, ingeniería, manufactura y visualización fotorealista.
Grasshopper es una extensión de Rhino que permite el modelado paramétrico sin tener conocimientos de programación o matemáticas avanzadas, facilitando el desarrollo de modelos de alta complejidad a partir de formas simples o complejas.
En este taller se cubren los principios de parametrización, analisis, panelización, Corte CNC.
Sesiones: 15 de 3 hrs
Duración: 45 horas
Días: lunes, miércoles y viernes
Horario: de 19:00 hrs a 22:00 hrs
Costo:
Pago único: $4,000 (antes del inicio del taller)
Pago fraccionado: $4,500
Primer pago: $2,000 para reservar tu lugar.
Segundo pago: $1,250 - 26 de septiembre
Tercer pago: $1,250 - 3 de octubre
…
e técnicas avanzadas de modelación 3d y su fabricación digital (corte láser e impresión 3d). Se utilizara Rhinoceros y Grasshopper, no es necesario tener conocimiento previo de los programas, únicamente manipular algún programa CAD.
Fechas:
Miercoles 13: 18:30 a 22:30Jueves 14: 18:30 a 22:30Viernes 15: 18:30 a 22:30Sábado 16: 11:00 a 14:30 y de 15:30 a 21:00Domingo 15: 11:00 a 14:30 y de 15:30 a 21:00
Fecha límite de Pago: lunes 11 de Junio del 2012Estudiantes: $160.000Profesionales: $220.00
Descuento para integrantes de Makerspace del 40% (5 cupos únicamente)
Importante:
Todos los niveles de experiencia son bienvenidos el único requisito es tener un entendimiento básico de los programas CAD y una actitud positiva hacia el aprendizaje de dichas herramientas. Necesitas llevar una laptop, nosotros te instalamos los programas de prueba.
Si planeas venir de fuera de la ciudad avísanos y te pondremos en contacto con otras personas que también vayan a hacerlo para en caso de desearlo puedan compartir su lugar de estancia.
Al participar en el workshop obtienes el 50 % de descuento en la licencia educacional Rhinoceros por medio de Rhino Chile.
Proceso de Inscripción:
El participante deberá pagar la matrícula haciendo un depósito bancario a la cuenta que aparece a continuación.
Banco: Estado
Nombre: Luis de la Parra Galván
No. Cuenta: 00169946655
Para obtener los datos restantes para hacer una transferencia o depósito mandar un mail a info@chidostudio.com
El depósito mínimo para reservar la matrícula es del 50% el resto deberá ser cubierto el día del evento.
Una vez que el depósito se haya llevado a cabo el participante deberá enviar a este correo info@chidostudio.com los siguientes datos:
Nombre completo
Email
Teléfono
Institución educativa u Oficina
Archivo adjunto del recibo del depósito bancario
En cuanto recibamos la información immediatamente nos pondremos en contacto para especificar los pasos a seguir.
Contacto Santiago [Sede]
Luis de la Parra
Cel: 714-660-33
info@chidostudio.com
http://www.facebook.com/Chidostudio
Todos los mails se responden en un máximo de 24 horas.
Muchas gracias por tu interés saludos…
s will learn to use these extensions in order to integrate numerous tools for analysis and simulation in the architectural process.
This course aims to develop a link between the virtual and the real context model through structural or environmental simulations, using other software or plug-ins dedicated. Through this link the virtual model receives physical properties that can further modify and adapt the initial model. This creates feedback loops that can optimize the design to provide an object responsive to environmental conditions.
Curriculum
Mesh subdivision with Weaverbird, continuous surfaces without NURBS
Genetic optimization with Galapagos, optimal search
Physical environment feedback with Diva and Geco, solar and day lighting analysis
Adding physical properties with Kangaroo Physics, interactive form-finding
Linking the parametric model with structural analysis using Karamba, structural performance simulation
Extracting data with Firefly and Kinect, 3D scanning and human movement tracking
Exchange of information between Grasshopper and other applications with Ghowl links to internet feeds or Excel files.
Schedule:
Module Grasshopper intermediate & advanced (24 h)
1 Nov – 15 Nov 2014
Sat:
9 - 13
14 - 18
Language: Romanian
Trainers:
Ionuț Anton, idz arhitectura (ART-Authorised Rhino Trainer)
Dana Tănase, idz arhitectura (ART-Authorised Rhino Trainer)
https://www.facebook.com/cursurigrasshopperrhinoceros
https://www.facebook.com/idzarhitectura
http://www.idz.ro/training/…
Added by Dana Tanase at 2:23am on February 2, 2014
component I just used different components and GH tools to do the same - and this become part of my short paper submission for SimAUD 2016). My solution compares the height of the same points of different solar envelope and then chose the lowest one. I read about the improvement you are working on and it is good but I think it is not yet what I need (or how the solar envelope tool could be more complete).
What I need is a solar envelope that would guarantee on different facades with different orientations (the example I sent you) a certain amount of direct sunlight, say 4h per day in a given period for example all the month of June at 60°N. So to guarantee the south facing facade I should chose the vectors from 10 to 14. But these are not ok for all the other facades because in this timeframe the East and West facing facades get only 2 hours and the North get 0 hours.
So the fist step would be have the possibility to chose different sun vectors for different facades. For the example I did (the 4 hours in June at 60°N) the south facing facade would need from 10 to 14, the East facing for example from 8 to 12, the West facing facade from 12 to 16 and the North facing facade from 6 to 8 and from 18 to 20.
If I would chose a single longer time frame that could get all these hours, from 8 to 20 then the resulting solar envelope would result probably smaller than the sum of the four solar envelopes.
But this is not complete yet. I mean the use of different sun vectors on different facades. The reason is that for example when I chose the sun vectors from 8 to 12 for the four hours on the East facing facade how do I know that the sun hit on the facade in that time frame or maybe it is obstructed by surrounding buildings? Since the sun at 60°N (where I live) in June rise at around 3.15 then maybe for that specific facade the sun hit from 4 to 8 and not from 8 to 12.
I did an extreme case talking about 60°N and that maybe the sun hit on a facade at 4 instead than 12, but it is just to make understand the logic. My suggestion for a more advanced solar envelope it should be integrated with the Sunlight Hours tool of ladybug. So the input should not be the sun vectors because I don't know when the sun hit on the facade but the input should be just the desired number of hours and the possibility to specify different number of hours for each facade. Then this last component that sum different solar envelope (I didn't use it yet but I understood what it does) should be integrated yes so the result would be one single solar envelope more likely using the lowest points (the highest I don't understand what for).
Let me know what you think!
…