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…
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
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…
N, O}. In this case it's very obvious what needs to happen. You want to create lines combining the following points {AK, BL, CM, DN, EO}.
If the second set however only contains 3 points {K, L, M}, it is no longer obvious. The default behaviour for Components is to keep on matching points until both sets are depleted. This is called Longest List Matching. It will give you 5 lines, that connect the following points: {AK, BL, CM, DM, EM}. As you can see, the last point in the second list (M) has been 'recycled' three times.
You can also change the default data matching behaviour. For example if you change it to Shortest List, then the component will stop working as soon as the smallest set is depleted: {AK, BL, CM}. In this case the points D and E are completely ignored because no 'sibling' could be found for them in the second set.
A third option is Cross Reference matching, which will create all possible combinations: {AK, AL, AM, BK, BL, BM, CK, CL, CM, DK, DL, DM, EK, EL, EM}.
However the best solution in this particular case is not to muck about with the data matching, but instead Graft your data. Grafting means that all the items in a set are moved into their own little set. Thus, if you graft {A, B, C, D, E}, you actually end up with 5 sets, each containing a single item {A}, {B}, {C}, {D} & {E}. When you combine this new data layout with your second set {K, L, M}, each grafted item will be matched with all the items in the second set, this is after all how Longest List works. So you end up with a data layout that looks like this: {AK, AL, AM}, {BK, BL, BM}, {CK, CL, CM}, {DK, DL, DM} & {EK, EL, EM}, which is very similar to the Cross Reference matching, but retains more of the original layout. I.e., it's not just a huge list of all the lines, they are still five groups of three items each, which is a far more informative layout than Cross Reference would generate.
I'm afraid at this time of night this is the best I can explain it.
--
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…
user to understand. RhinoScript is a generally more straightforward and easy to use. You can think of it as a translation of RhinoCommon so that you don't have to write all the technical stuff.
In your first line you've said "import rhinoscriptsyntax as rs". To see the methods you can call from this library you can go to the help menu and choose 'Help for Rhinoscript'. It will show you a searchable window of all the the options you have. This is much easier for new users to learn than looking at the RhinoCommon SDK.
If you search the help file for 'BoundingBox' you'll get the screen capture below:
At the bottom you can see an example of how to use it. In your case you would replace the following lines:
2/ boxA=brepA.GetBoundingBox((0,0,0,)) --> boxA = rs.BoundingBox(brepA)
3/ boxB=brepB.GetBoundingBox((0,0,0,)) --> boxB = rs.BoundingBox(brepB)
The script you have written uses elements of both RhinoScript and RhinoCommonSDK. I would suggest you might start just using RhinoScript. See below, I have re-written the first 8 lines of your script using just RhinoScript:
import rhinoscriptsyntax as rs
#Get BoundingBox from breps.BoundingBoxA = rs.BoundingBox(brepA) #Returns list of eight corner points.BoundingBoxB = rs.BoundingBox(brepB)
#Get centre point of RhinoScript BoundingBox (which is a list of eight points).boxA = rs.AddBox(BoundingBoxA) #Generate box from corner pointsptA = rs.SurfaceVolumeCentroid(boxA) #Get Volumetric Centroid of boxboxB = rs.AddBox(BoundingBoxB) ptB = rs.SurfaceVolumeCentroid(boxB)
For reference the following will achieve the same thing using RhinoCommon, fewer lines, but more technical. There are a few other quirks as well, for example you have to explictly tell the python component what kind of object 'brepA' is. See below for example of same script in RhinoCommon:
import Rhino as rh
centerPtA = brepA.GetBoundingBox(rh.Geometry.Plane.WorldXY).CentercenterPtB = brepB.GetBoundingBox(rh.Geometry.Plane.WorldXY).Center
I'm not sure what you are trying to achieve overall and your loop doesn't make a lot of sense to me but I hope that clarifies some of the differences between the two libraries you can use.
Regards,
M…
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
…