noceros 3D, en caso de aprobar satisfactoriamente el examen, se les otorga un reconocimiento avalado por el CMJ y la Secretaría del Trabajo. Este workshop va dirigido principalmente a estudiantes de arquitectura; sin embargo, ya que la parametrización es una herramienta que abarca diferentes ámbitos del diseño, se pueden integrar estudiantes de diseño industrial, artistas o estudiantes que tengan relación con lo gráfico y lo formal. Al finalizar el curso, los asistentes serán capaces de manejar Rhinoceros y Grasshopper en un nivel medio, con el objetivo de que el alumno pueda continuar aprendiendo con alguno de nuestros workshops subsiguientes o de manera autodidacta.
Las personas inscritas deben tener conocimientos básicos de geometría y de preferencia utilizar algún programa de dibujo en 2D o modelación en 3d. Rhino.GetMe Rigid // Enfocado a construir un objeto de diseño parametrizado a cualquier escala, el workshop se divide en tres módulos: Módulo 1 // Rhinoceros 3D // Una sesión de cinco horas. Módulo 2 //Grasshopper // Una sesión de cinco horas. Módulo 3 // Ejercicios prácticos /Tres sesiones de diez horas c/u. Es necesario traer el equipo necesario para trabajar, se cuenta con equipos en caso de que algún alumno no cuente con laptop pero son limitados, por favor avísanos a la brevedad si lo requieres. Se les recomienda que traigan dispositivos de almacenamiento en caso de que necesitemos compartir información.
El costo del Workshop es de $6500.00 para profesionales y $5000 pesos para estudiantes.
Pre-venta únicamente para estudiantes, hasta el día viernes 29 de junio, con un costo de $3500.00 pesos.
El cupo del evento es limitado puedes apartar tu lugar y terminar de liquidar antes del 29 de junio en pre-venta, antes del 6 de junio en admisión general.
Para hacer tu registro al workshop por favor envía un correo a workshop@transformalab.com incluyendo:
Nombre
Universidad u oficina de procedencia
Teléfono móvil
En el caso de estudiantes por favor incluyan una copia escaneada de su Constancia de Estudios para hacer válido su descuento.
Una vez recibida su información se les enviará un correo con la información necesaria para realizar su pago mediante depósito bancario, y posteriormente un mail de confirmación de su participación en el Workshop.
www.transformalab.com…
eather data so it cannot be easily compared to Archsim. My account of the differences between Honeybee and Archsim will be far from complete but here are the key ones that I am aware of:
1) This difference is a bit of a superficial one but points to a deeper thinking about how the software should be used. Honeybee has many more components than Archsim, which means that Honeybee has a steeper learning curve than Archsim and will take longer to master. Along with this, you may also encounter a general mentality in the Honeybee community that "you should not be running a certain type of simulation unless you know how it works" whereas I know that Archsim is a bit more amenable to making things fast and easy to set up even when you are not sure what is going on under the hood. However, as a result of the large number of components in Honeybee, it is more open-ended, customizable, and includes more freedom in terms of cases that you can run and the parameters of the energy simulation that you can change than Archsim. You will also notice that, while there is a general ethos in the Honeybee community that you should not be running certain simulations unless you know what you are doing, we try to provide you with many resources to educate yourself if you are motivated. For example, we have long component descriptions that we assemble into documentation books like this (https://www.gitbook.com/book/mostapharoudsari/honeybee-primer/details), hours of video tutorial playlist like this one (https://www.youtube.com/playlist?list=PLruLh1AdY-SgW4uDtNSMLeiUmA8YXEHT_), and many GH example files on a github-based file sharing system (https://hydrashare.github.io/hydra/index.html). Not to mention a community of people who would respond to discussions like this one.
2) Archsim as a standalone application will soon be no more and will be instead distributed with the DIVA daylight analysis tool (http://diva4rhino.com/). While I am unclear on the exact trajectory of DIVA, it currently has a price tag attached to it and so I would assume that the future of Archsim will also carry this price tag. On the other hand, Honeybee and any derivative software will forever be free and open source under the GPL licence (https://github.com/mostaphaRoudsari/Honeybee/blob/master/License_Honeybee_GPL.txt).
3) This third point is a bit of a reiteration of the last one but Honeybee is open source, meaning that, if you need a feature of EnergyPlus that is not yet implemented on either interface, you can usually add it in yourself with a few lines of python code in Honeybee. This type of workflow is not possible with Archsim since it is closed source and requires you to use EnergyPlus's text editor interface after Archsim has exported an IDF in order to implement any additional EnerygPlus features.
4) The libraries and templates for Honeybee come from OpenStudio - the open source interface for EnergyPlus (https://www.openstudio.net/), which is supported by the US Department of Energy (just like EnergyPlus). Since Honeybee is open source, it is able to make use of the large database of building type schedules/loads and constructions that have been assembled by the OpenStudio team over the last several years as well as OpenStudio's SDK. I can also say that almost all of the development efforts of the Honeybee team are now focused now on integrating efforts with OpenStudio, including an exporter from Honeybee to OpenStudio that should be fully functional for the next stable release. I am not certain of the current extent of Archsim's libraries but, last I had checked, the creator was pulling them from his own experience and, as such, only had a few libraries to choose from. For all of my knowledge, through, this may be changing with the integration of Archsim with DIVA.
Let me know if this is helpful and, if anyone has more up-to-date knowledge on Archsim than I, please post there.
-Chris…
er). With the command "End Bulge" I noticed that G2 moves perpendicular to G1! But with an increase which is not equal... and is different, every time, depending on the angle between G0 and G1 and G2. How do I predict the position of G2 compared to G1 simulating the "End Bulge" command? Thank you for your professional answers.
^___^
Below you can see an example with a curve crimson ... If I move G1 of 1 unit G2 moves of 0.42 units (perpendicular) .. If I move of 2 units the next step is 0.46 unit... 3 units --> step 0,50 units... etc.
And each time changes depending on the initial conditions (G0/G1/G2 angle).
…
Added by Lucius Santo at 4:21pm on September 20, 2012
or GH with: 1. Animation Timeline 2. Rendering 3. API
Summary:
Animation Timeline: Smooth animation system that plays at the real-world speed; so you know the robot will run just right when you upload the code.
Rendering: Extensive options and outputs; so you can generate amazing videos.
API: Access our functions through Python and C# scripting; so you can manage parameters and actions for complex processes for each target.
More info:
Animation Timeline:
Build an animation from a list of Planes, it's that easy! Get these from points, curves or surfaces. Download the example files with the trial and test it yourself.
The unique Timeline component displays all the important robot warnings and the digital Input/Ouput:
RED – clash detection BLUE - singularities YELLOW – over rotation ORANGE – out of reach Digital Inut/Output: red=off, green=on
Rendering:
IO smoothly interpolates between all the Planes you set. This means you can generate keyframes for positions between Planes too e.g. you have two planes defining a tool path, IO can generate 2000 keyframes. Smooooth!
Rendered in full colour as standard, not GH red :-)
LiveBaking - let's you use Rhino render settings in real-time (can be a bit slow!)
Slider animation - use the native 'Animate' option to export hi-res images and create videos easily. Just set the number of frames you need (hint: divide total time in seconds by the frames-per-second rate)
Bake unlimited meshes as keyframes for export to render-pipelines in 3DS etc.
API
Accessing the IO functions through Python and C# let's you build more powerful definitions. You can assign data to every position the robot reaches, allowing you to control speed, acceleration, wait-times, actions and more. Examples comparing C# with Python are included in the examples files.
You can also use teh API build your own plugins that use the IO timeline to do all the hard work like IK and creating valid code, while you enjoy developing your new process...
Check out the website for more features and videos of the example definitions: www.robots.io
Download the PDF guide: 150314_IO_Primer_v1.pdf.
See www.robots.io for more info and pricing.
Developed by RoboFold Ltd. Used by leading academics, researchers and professionals.
…
Added by Gregory Epps at 10:15am on November 7, 2014
ahams's question about how shades are accounted for in the simulation/thermal map and Theodore's thought that just accounting for shades in the E+ run was sufficient. I think that it may be clearest to explain what is going on with this infographic:
As the graphic shows, the thermal maps are made from 4 key types of inputs. The radiant temperature map is formed through a consideration of both the temperature of the surfaces surrounding the occupants and the direct solar radiation that might fall onto the occupants through un-shaded windows. The first surface temperature effect is easily computable from your Energy simulation results and the HBZone geometry. However, the second is calculated by seeing how sun vectors pass through the windows of the zones and uses the SolarCal method of the CBE team (http://escholarship.org/uc/item/89m1h2dg) to compute an MRT delta resulting from solar radiation. This delta is then added to the initial values computed through surface temperature view factor. When you do not connect up your shading brep geometry, internal furniture breps, or outdoor context geometry that might block sun to the additionalShading input, the thermal map will assume that sun can pass unobstructed through the window or through indoor furniture to fall onto occupants. It is important to stress that the EnergyPlus simulation does not count for blind geometry or internal furniture as actual geometry. Just as numerical abstractions of surface area and material properties. So we need you to plug in the actual geometry of these things when we compute the MRT delta resulting from sun falling directly onto people.
Next, to clear up the definition of window transmissivity. The important thing to clarify here is that, whether it refers to the tranmittance of glass or to the amount of sun coming through a fine screen of blinds, the value is multiplied by the radiation falling on the occupant and thus has a direct correlation to the MRT Delta from sun falling on occupants. So, if you set transmissivity to zero, the sun falling on the occupants will not be considered in the calculation and, if you set the transmissivity to 1, the assumption is that there is no window (or the window glass is 100% clear). So, Abraham, your definition of it as a coefficient is appropriate.
Normally, I would just recommend that you leave this value at the default 0.7, which corresponds to the transmittance of the default glass material in Honeybee. However, there are 4 cases in which you might consider changing it:
1) You are not using the default Honeybee glazing material, in which case, you should change the transmissivity to be equal to this new value.
2) You have a lot of really small blind/shade geometries and you do not want the view factor component to take several minutes to trace sun vectors through the detailed shade geometry and so you are ok with using just a simple abstraction instead of plugging shade breps into the additionaShading. In this case, you might try to estimate the average percentage of radiation coming through the blind geometry (maybe with some simple Ladybug radiation studies or with your intuition about the amount of sun blocked by the shades). You will then multiply this by the tranmissivity of your glass and this will be the value that you input to the component.
3) Your blinds for your Honeybee simulation are dynamic, in which case, plugging shade breps into additionalShading is not going to work because the component will assume that those shades are always there. In this case, you should be plugging a list of 8760 values into the transmissivity that correspond to when the shades are pulled. When the blinds are completely up, the value should be the tranmittance of your window and, when they are down, the value should be the window tranmittance multiplied by the fraction of light coming through the shades.
4) You have shades/blinds but they are transparent or are not completely opaque. The additionalShading_ input assumes that all shade geometry is opaque and so you cannot use it to account for such shades. Accordingly, you will need to account for it through the tranmissivity.
In the future, I may try to pull more information about blinds and glass properties off of the HBzones inside the view factor component but, for now and for the next few months, the above describes how it works.
Theodore, for curved geometry, I think that your safest bet is going to be planarizing the Rhino geometry before you turn it into a HBZone (so you just divide the curved surface into a few vertical planar panes of glass that approximate the curve well enough). This is essentially what the runSimulation component does for you automatically (it meshes the geometry as you see here: https://www.youtube.com/watch?v=nMQ2Pau4q6c&index=12&list=PLruLh1AdY-SgW4uDtNSMLeiUmA8YXEHT_). If I were to figure out a way to incorporate shades in this automatic meshing workflow, your EnergyPlus simulation would take a very long time to run and I am not even sure if the result will be that accurate with the way E+ abstracts shades. So I don't think that it's really worth it over just planarizing the geometry yourself.
Lastly, I won't be able to figure out the problem with your current run Theodore, unless I get the GH file from you. Make sure that you are using all up-to-date components.
-Chris…
l coworking. Il corso prevede la trattazione delle tematiche di base della modellazione generativa, con l'inserimento di lezioni basate sulla filosofia progettuale della modellazione generativa e basi di analisi matematica.
Il corso ha durata di 30 ore con appuntamenti bisettimanali (lunedì e mercoledì) a partire da lunedì 03 ottobre. Per maggiori informazioni contattate il docente del corso e scaricate il programma
____________
Cavallette Generative is the new Grasshopper Level I course offered by Mandarino Blu visual communication LAB. The event is organized by the support of Multiverso, a co-working company. The course includes the discussion of the basic themes of generative modeling, such as design philosophy and mathematical analysis.
The course lasts 30 hours with twice-weekly meetings (Monday and Wednesday) from Monday, October 3. For more information contact the instructor of the course and download the program…
tion) which would amount to -at a rough guess based on your image- about 1000 genes. I'm not sure how well Galapagos will be able to deal with such an amount (ironically the biggest problem will probably be the interface, not the solver algorithm).
The main theoretical problem I see is the fitness function definition for this. It won't be good enough to count intersections and minimize those. Reason being is that the number of intersections is an integer (it doesn't vary smoothly) and as such there's no 'selection pressure' towards better solutions. If you start with a setup like this:
it would have a 'fitness' of 2. We'd like to move these two shapes apart but even if we move them a large distance in the correct direction, we still have a fitness of 2:
It seems like a more useful metric would be the area of the overlap, at least then when leaves move apart, the fitness value will change, which allows the algorithm to make an informed decision.
Computing curve region intersections and areas will be a very intense step, making the whole process even slower than it already is. If I had to do this, I'd first try and tackle this using pixels, as computers are very good at dealing quickly with them. You could draw an image of all the shapes, drawing them each in a transparent black. Then, when two shapes overlap, the resulting pixel will be darker than the fill. If three shapes overlap it will be darker still. Then, once you've created the image, you could all the pixels and compute a value based on how many dark pixels there are.
This can probably be done in a reasonably low resolution, but you'd need to write some code to create and analyse the images.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
ere is often a bit of a misconception about the differences between 'mass-spring' models and FEA. Although the method of solving is different, as I do not form a global stiffness matrix, the elements themselves and the calculation of stresses in them can be effectively the same, and based on standard real material properties and sections.
Using nodes with only 3 degrees of freedom as Kangaroo does currently, axial stresses can be calculated (a spring being a very simple finite element), and bending without torsion (following the approach described in this paper), accounting for Young's modulus and sectional area. I had been focused for a while on more geometrical optimization, but recently have been looking again at clarifying the real world units and numerical values used by Kangaroo for structural purposes.
Several other ways of modelling beam/plate/volume type elements using combinations of springs are commonly used in game/animation physics, and these can indeed be difficult to link to accurate quantitative behaviour, which has perhaps helped form the impression of mass-spring models as non accurate, but it need not be so.
The approach can also be extended to 6dof nodes, in which case it becomes possible to include torsion, anisotropic bending etc, and to base these on more standard engineering formulations for beams and other elements.
In fact I've recently worked on some software together with Gennaro Senatore and Charlie Banthorpe for Expedition Workshed that implements such 6dof elements together with large displacements, realtime interaction, and options to output bending moment/shear/torsion graphically. This is browser based (you can try it here), rather than Grasshopper but I'm currently working on bringing the same approach into Kangaroo.
Maintaining interactive speeds while avoiding numerical instabilities does pose its challenges with these methods, and for many conventional structures where the displacements are small and interaction is less important I think conventional FEA will continue to be more efficient for some time, but I do believe the approaches will eventually converge.
Thinking about it - although they are very useful techniques, continuum mechanics and infinitesimal displacements are both just useful abstractions, and no less 'artificial' than mass-spring models (and I think infinitesimal displacements are particularly counter-intuitive - real things have to move to generate stresses).
Anyway, I'm always very interested in exploring collaborations and sharing of ideas about these approaches, and would love to hear any more thoughts from the Karamba team about this...
best,
Daniel…
out of the practice walls.
Anyway get a hint: Hard top-bottom clustering is used (process is STOPPED to the fist level of clustering for clarity: meaning flat clustering):
Cubes are abstarct (spaces, say: "rooms") centroids:
Then clusters are made; Prox K-Means is used here (other methods also available). Cyans are the abstract representation of the flat clustering (for clarity). The decision upon the number of clusters is quite complex and is based on criteria that are not used here (adjacency matrices et all):
Then this:
And finally that:
Obviously the real thing works recursively (kinda like a fractal algo) on the clusters and stops if the predefined number of nodes is reached (say 2 or 3). Then the "flat" red connector shown connects actually (bottom to top) child to child AND child to parent clusters etc etc.
BTW: GH has a component (called quadTree) that - I guess - works "kinda" like a K-Means clustering algo but the fact that GH is a-cyclic by nature ... means that you should use Anemone - if the above are attempted via the component way (not my way anyway).
more soon
…