(http://www.food4rhino.com/app/quelea-agent-based-design-grasshopper) take like 40 seconds when the toggle activates to go from one end of the ramp to another.
With proximity 3d i'm analyzing each instance the agents are closer than x units. In picture 3 we can see that in 212 instances the agent are closer than those x units.
Finally all the genes that controll the ramps are connected to the G of octopus component and one of the conflicting objectives connected to the O of octopus component is the number of instance quelea agents get close.
So the thing I need is to iterate the ramps controling the genes with octopus but activating the boolean toggle (quelea run) each time the ramps are modified so the agents take 40 seconds to perambulate the environment, analyze the instance they get close and let octopus iterate again searching for a optimized environment.
…
raries by entering %appdata% into the dialog box and browsing to the Grasshopper Libraries folder to find KangarooSolver.dll.)
Oh wow, because of "physics" there is substantial gap between the surface layer of many particles and the inner truss, so we already have some form of boundary adaptive 3D meshing, albeit only in the surface "XY" direction not the normal "Z" direction. There's less full XYZ directional force on the particles at the surface, so they can cluster more there due to the forces from within having to struggle much more against one another from all directions. Something like that.
Differing surface curvature has not much if any affect on particle packing:
The actual physics of electrons along a conductor says they are all on the surface, where they concentrate at sharp features, but here I imagine if they concentrated more at the finger tip, they would then push more interior particles away, which is not very adaptive after all.
Higher falloff exponents than 3 (actually -3) give much more even distances of surface vs. interior, so my color coding by length doesn't even work and there are visibly a lot more interior particles:
I confirm that exponent -2 drives everything to the surface, but also gives a quite odd artifact that they are not minimizing energy by close packing away from each other but are forming squares that seem to align with the UV directions of the container:
Exponent -4 then and even more -5 maximize the interior population, but beyond -5 it it becomes unstable and bounces around like crazy.
The Kangaroo2 custom goal C# script is simple enough:
I'm still confused how to attenuate the effect according to distance to the surface and also curvature of the surface when you are getting close to it since I don't understand if Kangaroo is running the entire Grasshopper script each iteration or not so I could just do calculations via Grasshopper stuff and feed it into the C# script as needed?
…
Added by Nik Willmore at 7:43pm on August 12, 2015
e chosen to dive into Grasshopper. I’m about 6 months in. If some of my comments are completely off, please take that to mean that a feature is too inaccessible to a newish user rather that it’s just missing, as I may have stated.
One of my primary pain points is this. Things that can be done in other programs are invariably easier in other programs. This is a big enough issue that I doubt there’s an easy solution that an armchair qb like myself can offer up.
The interface:
I’ve used a lot of 3D programs. I’ve never encountered one as difficult as grasshopper. What in other programs is a dialog box, is 8 or 10 components strung together in grasshopper. The wisdom for this I often hear among the grasshopper community is that this allows for parametric design. Yet PTC (Parametric Technology Corp.) has been doing parametric design software since 1985 and has a far cleaner and more intuitive interface. So does SolidWorks, Inventor, CATIA, NX, and a bunch of others.
In the early 2000's, when parametric design software was all the rage, McNeel stated quite strongly the Rhino would remain a direct modeler and would not become a parametric modeler. Trends come. Trends go. And the industry has been swinging back to direct modeling. So McNeel’s decision was probably ok. But I have to wonder if part of McNeel’s reluctance to incorporate some of the tried and proven ideas of other parametric packages doesn't have roots in their earlier declaration to not incorporate parametrics.
A Visual Programming Language:
I read a lot about the awesomeness and flexibility of Grasshopper being a visual programming language. Let’s be clear, this is DOS era speak. I believe GH should continue to have the ability to be extended and massaged with code, as most design programs do. But as long as this is front and center, GH will remain out of reach to the average designer.
Context sensitivity:
There is no reason a program in 2014 should allow me to make decisions that will not work. For example, if a component input is in all cases incompatible with another component's output, I shouldn't be able to connect them.
Sliders:
I hate sliders. I understand them, but I hate ‘em. I think they should be optional. Ya, I know I can r-click on the N of a component and set the integer. It’s a pain, and it gives no feedback. The “N” should turn into the number if set. AAAnd, sliders should be context sensitive. I like that the name of a slider changes when I plug it into something. But if I plug it into something that'll only accept a 1, a 2, or a 3, that slider should self set accordingly. I shouldn't be able to plug in a “50” and have everything after turn red.
Components:
Give components a little “+” or a drawer on the bottom or something that by clicking, opens the component into something akin to a dialog box. This should give access to all of the variables in the component. I shouldn't have to r-click on each thing on a component to do all of the settings.
And this item I’m guessing on. I’m not yet good enough at GH to know if this may have adverse effects. Reverse, Flatten, Graft, etc.; could these be context sensitive? Could some of these items disappear if they are contextually inappropriate or gray out if they're unlikely?
Tighter integration with Rhino:
I'm not entirely certain what this would look like. Currently my work flow entails baking, making a few Rhino edits, and reinserting into GH. I question the whole baking thing, btw. Why isn't it just live geometry? That’s how other parametric apps work. Maybe add more Rhino functionality to GH. GH has no 3D offset. I have to bake, offsetserf, and reinsert the geometry. I’m currently looking at the “Geometry Cache” and “Geometry Pipeline” components to see if they help. But I haven't been able to figure it out. Which leads me to:
Update all of the documentation:
I'm guessing this is an in process thing and you're working toward rolling GH from 0.9.00075 to 1.0. GH was being updated nearly weekly earlier this year. Then it suddenly stopped. If we're talking weeks before a full release, so be it. But if we're looking at something longer, a documentation update would help a lot. Geometry Cache and Geometry Pipeline’s help still read “This is the autogenerated help topic for this object. Developers: override the HtmlHelp_Source() function in the base class to provide custom help.” This does not help. And the Grasshopper Primer 2nd Ed. was written for GH 0.60007.
Grasshopper is fundamentally a 2D program:
I know you'll disagree completely, but I'm sticking to this. How else could an omission like offsetsurf happen? Pretty much every 3D program in existence has this. I’m sure I can probably figure out how to deconstruct the breps, join the curves, loft, trim, and so forth. But does writing an algorithm to do what all other 3D programs do with a dialog box seem reasonable? I'm sure if you go command by command you'll find a ton on such things.
If you look at the vast majority of things done in GH, you'll note that they're mostly either flat or a fundamentally 2D pattern on a warped surface.
I've been working on a part that is a 3D voronoi trimmed to a 3D model. I've been trying to turn the trimmed voronoi into legitimate geometry for over a month without success.
http://www.grasshopper3d.com/profiles/blogs/question-voronoi-3d-continued
I’ve researched it enough to have found many others have had the exact same problem and have not solved it. It’s really not that conceptually difficult. But GH lacks the tools.
Make screen organization easier:
I have a touch of OCD, and I like my GH layout to flow neatly. Allow input/output nodes to be re-ordered. This will allow a reduction in crossed wires. Make the wire positions a bit more editable. I sometimes use a geometry component as a wire anchor to clean things up. Being able to grab a wire and pull it out of the way would be kinda nice.
I think GH has some awesome abilities. I also think accessing those abilities could be significantly easier.
~p…
eroberfläche des Grasshopper Programms
Funktionsprinzip eines grafischen Algorithmus-Editors (Datenfluss)
Unterscheidung von Parametern (Datentypen) und Komponenten (Datenverarbeitung)
Erzeugung, Bearbeitung und Analyse von Geometrie-Typen: Punkte, Vektoren, Linien, Kurven, Flächen (surfaces, brep) und Netze (meshes)
Strukturierung der Daten anhand von Listen und Bäumen
unterschiedliche Verknüpfungsmöglichkeiten von Parametern (data matching)
praxisnahe Grundlagen der Geometrie und Vektorrechnung für generatives Design
effizienter Aufbau von parametrischen Modellen anhand Übungsaufgaben
Auszug von Daten aus Modellen für die Fertigung; Daten aus Tabellen (Excel, CSV) importieren, exportieren
Einsatz von benutzerdefinierten Komponenten (custom components)
Vorkenntnisse: Rhinoceros3d Benutzeroberfläche der Software: Englisch Unterrichtssprache: Deutsch
Details und Anmeldung:
www.vhs-sha.de
click: SUCHE
Kurstitel: GRASSHOPPER
(auch: Kurstitel: RHINO)
Trainer: Peter Mehrtens
Kursdauer: 3 Tage / 8 Stunden pro Tag
Donnerstag, 19.07.2012, 08:00-17:00 Uhr Freitag, 20.07.2012, 08:00-17:00 Uhr Samstag, 21.07.2012, 08:00-17:00 Uhr Ort: Volkshochschule Schwäbisch Hall, im Haus der Bildung
Teilnahmegebühr: 299,00 € Teilnehmerzahl: 5-10 Personen
…
0.1 Webinar introduction0.2 Installation of Ladybug for Grasshopper (+Rhino)0.3 Getting started with Ladybug for Grasshopper (+Rhino)0.4 Introduction to Environmental Design Analysis - process and methodology_STEP 1 CLIMATE ANALYSIS (NO MODEL)1.0 Introduction to Climate Analysis1.1 Finding and importing weather data file1.2 Sun Path1.3 Temperature chart1.4 Humidity chart1.5 Wind Rose1.6 Comfort Analysis based on weather data1.7 Psychrometric Chart1.8 Bioclimactic Chart1.9 Customizing Analysis Period and Charts_STEP 2A ANALYSIS OF EXISTING URBAN SPACES (WITH MODEL)2a.0 Introduction to Analysis of existing Urban Spaces2a.1 Import Context models from Rhino2a.2 Radiation Rose2a.3 Solar Fan / Envelope_STEP 2B ANALYSIS OF NEW URBAN SPACES / DEVELOPMENT (WITH MODEL)2b.0 Introduction to Analysis of new Urban Spaces2b.1 Import new Urban Buildings and/or Elements from Rhino2b.2 Parametric Grasshopper models 2b.3 Radiation Rose-------------------DANIEL NIELSENThe Danish architect Daniel Nielsen has a broad experience with Architectural Sustainability and the integration of parametric 3D modeling and simulation tools into the process. He have worked on projects at various scales - from buildings to planning, and have been involved in research and education programs at The Royal Danish Academy of Fine Arts and Technical University of Denmark.…
se presentarán una pieza cortada con láser o CNC.Extracto de TemarioIntroducción Fundamentos Grasshopper Image Sampler V-Ray Interiores Que es es CNCFundamentos Interfase Visualización - Grasshopper V-Ray Exteriores Arboles de datos Corte, Laser e impresión 3dTeoria de Curvas Componentes y parametros Listas de datos V-Ray Materiales Clusters ToleranciasTranspocición Vectores y reticulas -Atractores Series y rangos Teoria de Superficies Conexiones Estrategias de modelado para manufacturaSimetrias Transpocisión parametrica Formulas Panelizacion Teoría de Ensambles Teoría de archivos para corteAtractores Cull Random Información del taller:Fechas: del 8 al 26 de Junio de 2015Sesiones: 8 de 3 hrs y presentación finalDuración: 27 hrs.Días: Lunes,Miércoles y ViernesHorario: de 19:00 a 22:00 hrsPrecio : $4,500 Apartado: $2,000Pago oportuno (antes del 1 de Junio): $3,500PAQUETESTaller y Rhino 5.0 Educativa: $6,500.00 Taller y Rhino 5.0 Comercial: $21,000.00 *Sólo hacemos reembolso en cancelaciones con un mínimo de 15 días previos al taller.info@dimensiontallerdigital.comtel oficina (55) 50160634…
essarily architectural. As you can guess from the tone of my previous response, I finished with school and had a hard time finding a job that focused on the technologies I delt with all through undergrad and grad. During grad school I was working with ASGvis (the makers of V-Ray) so I got exposed to the software side of things both on the support/management side and the development side. Now I'm off on my own doing development projects like RhinoHair, a few others, and some custom plugins for clients. Not necessarily what I thought I'd be doing after grad school, but I'm certainly enjoying it more than the "standard" practice of architecture.
I definitely understand "creating" a program. I did both my undergrad and grad at Catholic U here in DC, and although there was some ground work laid in regards to fabrication, I was one of only two or three students spearheading a lot of the scripting/GH/parametric stuff and some of the topics that go along with them (algorithmic design, adaptive systems, advanced geometry). One thing that was incredibly helpful for me was to pair up with the most advanced and forward thinking professor(s) that you can and take their studios, electives, and/or help out with their research. I was lucky enough to pair with a professor who had been at MIT and really encouraged me to explore my interests and sharpen my technicial skills.
It might also be a good idea to stick your head in some other departments, probably the math and engineering ones, or even biology and economics if there are some forward thinking professors. Talk to some people and get a different perspective on things. When I went to the ACADIA conference in 2008 it really opened my eyes to some of the potential influence from those different arenas.
Fabrication wise, I'd really try to focus more on milling (3 axis is fairly standard, 5 axis if you can get access) than 3d printing. Printing is a lot of fun, but ultimately we're not printing buildings (yet), so some of the milling processes will be much more valuble. If your school doesn't have those kind of facilities on campus (either in the Arch dept or engineering or something), then contact a local fabricator and see if you can work together somehow or someway. You'd be surprised and how many fabricators are interested in talking to architects.…
Added by Damien Alomar at 3:13pm on February 8, 2010
, and it was only devised for triangular faces:
I could track all my edge labels (via the neighboring cell discussion) but from that info (the pesky tree) I needed unique face pairs to output a single crease angle.
Now (with your scripted component) I have the crease angles. All the 3D text is temporary for trouble shooting. This is 3 faces from a dodecaheadron:
So now I have the remaining hurdle as to whether the proper crease angle is the GH angle or the GH reflex angle.
The funny thing with the "pesky tree" is the meaning of the pattern doesn't become apparent until it's more complicated than the simpler excerpt from above.
I think I could make the scripted component a little cleaner if I use some nested loops instead of your search and remove method, but that may take me a while.
But it all the fun comes from this guy:
…
...hmm... points across the facade edges are not included (or may be some) and thus the whole thing is the art of pointless.
2. See the 1a unfinished part ... that defines internal boundaries for that purpose - then you need to create points across the edges, random reduce them and merging the list with the other points...blah blah.
3. That way each facade could yield structural members that touch the edges (where the biggest HEB/columns are expected to be). Obviously nodes are shared between facades with a common edge - the best logical approach for obvious real-life reasons.
4. The whole approach is stupid : here we need some Hoop snake "loop" control (that could take into account the critical connection angle constrain) in order to achieve a "progressive" deployment of the diagonal members in order to satisfy structural requirements and ... hmm...aesthetics. Free espresso for everyone is an added bonus.
5. Bottom to top design mentality is urgently required here: mastermind some 3d conceptual arrangement of nodes keeping in mind ... well...just 345,67 different real-life factors (but you could combine insulation and fireproofing if you use my favorite material: Foamglas - name with with one "s"). That way you can define the critical deployment planes : i.e. diagonal rigidity members, some facade aluminum system and floor main perimeter I-Beams MUST be in different planes.
I'll be back with a more stupid version of that thing.
may the Force ...blah blah
…