and export the geometry out to VVVV to render it LIVE! RawRRRR. In this case, a digital audio workstation Ableton Live, a leading industrial standard in contemporary music production.
the good news is that VVVV and ableton live lite is both free.
https://www.ableton.com/en/products/live-lite/
i am not trying to use ipad as a controller for grasshoppper. I wanted to work with a timeline (similar to MAYA or Ableton or any other DAW(digital audio workstation)) inside grasshopper in an intuitive way. Currently there is no way of SEQUENCING your definition the way you want to see that i know of.
no more combersome export import workflows... i dont need hyperrealistic renderings most of the time. so much time invested in googling the right way to import, export ... mesh settings...this workflow works for some, for some not ...that workflow works if ... and still you cannot render it live nor change sequence of instruction WHILE THE VIDEO is played. and I think no one wants to present rhinoceros viewport. BUT vvvv veiwport is different. it is used for VJing and many custom audio visual installation for events, done professionally. you can see an example of how sound and visuals come together from this post, using only VVVV and ableton. http://vvvv.org/documentation/meso-amstel-pulse
I propose a NEW method. make a definition, wire it to ableton, draw in some midi notes, and see it thru VVVV LIVE while you sequence the animation the WAY YOU WANT TO BE SEEN DURING YOUR PRESENTATION FROM THE BEGINNING, make a whole set of sequences in ableton, go back change some notes in ableton and the whole sequence will change RIGHT INFRONT of you. yes, you can just add some sound anywhere in the process. or take the sound waves (sqaure, saw, whateve) or take the audio and influence geometric parameters using custom patches via vvvv. I cannot even begin to tell you how sophisticated digital audio sound design technology got last ten year.. this is just one example which isn't even that advanced in todays standard in sound design ( and the famous producers would say its not about the tools at all.) http://www.youtube.com/watch?v=Iwz32bEgV8o
I just want to point out that grasshopper shares the same interface with VVVV (1998) and maxforlive, a plug in inside ableton. audio mulch is yet another one that shares this interface of plugging components to each other and allows users to create their own sound instruments. vvvv is built based on vb, i believe.
so current wish list is ...
1) grasshopper recieves a sequence of commands from ableton DONE
thanks to sebastian's OSCglue vvvv patch and this one http://vvvv.org/contribution/vvvv-and-grasshopper-demo-with-ghowl-udp
after this is done, its a matter of trimming and splitting the incoming string.
2) translate numeric oscillation from ableton to change GH values
video below shows what the controll interface of both values (numbers) and the midi notes look like.
https://vimeo.com/19743303
3) midi note in = toggle GH component (this one could be tricky)
for this... i am thinking it would be great if ...it is possible to make "midi learn" function in grasshopper where one can DROP IN A COMPONENT LIKE GALAPAGOS OR TIMER and assign the component to a signal in, in this case a midi note. there are total 128 midi notes (http://www.midimountain.com/midi/midi_note_numbers.html) and this is only for one channel. there are infinite channels in ableton. I usually use 16.
I have already figured out a way to send string into grasshopper from ableton live. but problem is, how for grasshopper to listen, not just take it in, and interpret midi and cc value changes ( usually runs from 0 to 128) and perform certain actions.
Basically what I am trying to achieve is this : some time passes then a parameter is set to change from value 0 to 50, for example. then some time passes again, then another parameter becomes "previewed", then baked. I have seen some examples of hoopsnake but I couldn't tell that you can really control the values in a clear x and y graph where x is time and y is the value. but this woud be considered a basic feature of modulation and automation in music production. NVM, its been DONE by Mr Heumann. https://vimeo.com/39730831
4) send points, lines, surfaces and meshes back out to VVVV
5) render it using VVVV and play with enormous collection of components in VVVV..its been around since 1998 for the sake of awesomeness.
this kind of a digital operation-hardware connection is usually whats done in digital music production solutions. I did look into midi controller - grasshopper work, and I know its been done, but that has obvious limitations of not being precise. and it only takes 0 o 128. I am thinking that midi can be useful for this because then I can program very precise and complex sequence with ease from music production software like ableton live.
This is an ongoing design research for a performative exhibition due in Bochum, Germany, this January. I will post definition if I get somewhere. A good place to start for me is the nesting sliders by Monique . http://www.grasshopper3d.com/forum/topics/nesting-sliders
…
ers can be applied from the right click Context Menu of either a component's input or output parameters. With the exception of <Principal> and <Degrees> they work exactly like their corresponding Grasshopper Component. When a I/O Modifier is applied to a parameter a visual Tag (icon) is displayed. If you hover over a Tag a tool tip will be displayed showing what it is and what it does.
The full list of these Tags:
1) Principal
An input with the Principal Icon is designated the principal input of a component for the purposes of path assignment.
For example:
2) Reverse
The Reverse I/O Modifier will reverse the order of a list (or lists in a multiple path structure)
3) Flatten
The Flatten I/O Modifier will reduce a multi-path tree down to a single list on the {0} path
4) Graft
The Graft I/O Modifier will create a new branch for each individual item in a list (or lists)
5) Simplify
The Simplify I/O Modifier will remove the overlap shared amongst all branches. [Note that a single branch does not share any overlap with anything else.]
6) Degrees
The Degrees Input Modifier indicates that the numbers received are actually measured in Degrees rather than Radians. Think of it more like a preference setting for each angle input on a Grasshopper Component that state you prefer to work in Degrees. There is no Output option as this is only available on Angle Inputs.
7) Expression
The Expression I/O Modifier allows you change the input value by evaluating an expression such as -x/2 which will have the input and make it negative. If you hover over the Tag a tool tip will be displayed with the expression. Since the release of GH version 0.9.0068 all I/O Expression Modifiers use "x" instead of the nickname of the parameter.
8) Reparameterize
The Reparameterize I/O Modifier will only work on lines, curves and surfaces forcing the domains of all geometry to the [0.0 to 1.0] range.
9) Invert
The Invert Input Modifier works in a similar way to a Not Gate in Boolean Logic negating the input. A good example of when to use this is on [Cull Pattern] where you wish to invert the logic to get the opposite results. There is no Output option as this is only available on Boolean Inputs.
…
ing the maps to the broader community.
At the moment, there are just a few known issues left that I have to fix for complex geometric cases but they should run smoothly for most energy models that you generate with Honeybee. Within the next month, I will be clearing up these last issues and, by the end of the month, there will be an updated youtube tutorial playlist on the comfort tools and how to use them.
In the meantime, there's an updated example file (http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Indoor_Microclimate_Map) and I wanted to get you all excited with some images and animations coming out of the design part of my thesis. I also wanted to post some documentation of all of the previous research that has made these climate maps possible and give out some much deserved thanks. To begin, this image gives you a sense of how the thermal maps are made by integrating several streams of data for EnergyPlus:
(https://drive.google.com/file/d/0Bz2PwDvkjovJaTMtWDRHMExvLUk/view?usp=sharing)
To get you excited, this youtube playlist has a whole bunch of time-lapse thermal animations that a lot of you should enjoy:
https://www.youtube.com/playlist?list=PLruLh1AdY-Sj3ehUTSfKa1IHPSiuJU52A
To give a brief summary of what you are looking at in the playlist, there are two proposed designs for completely passive co-habitation spaces in New York and Los Angeles.
These diagrams explain the Los Angeles design:
(https://drive.google.com/file/d/0Bz2PwDvkjovJM0JkM0tLZ1kxUmc/view?usp=sharing)
And this video gives you and idea of how it thermally performs:
These diagrams explain the New York design:
(https://drive.google.com/file/d/0Bz2PwDvkjovJS1BZVVZiTWF4MXM/view?usp=sharing)
And this video shows you the thermal performance:
Now to credit all of the awesome people that have made the creation of these thermal maps possible:
1) As any HB user knows, the open source engines and libraries under the hood of HB are EnergyPlus and OpenStudio and the incredible thermal richness of these maps would not have been possible without these DoE teams creating such a robust modeler so a big credit is definitely due to them.
2) Many of the initial ideas for these thermal maps come from an MIT Masters thesis that was completed a few years ago by Amanda Webb called "cMap". Even though these cMaps were only taking into account surface temperature from E+, it was the viewing of her radiant temperature maps that initially touched-off the series of events that led to my thesis so a great credit is due to her. You can find her thesis here (http://dspace.mit.edu/handle/1721.1/72870).
3) Since the thesis of A. Webb, there were two key developments that made the high resolution of the current maps believable as a good approximation of the actual thermal environment of a building. The first is a PhD thesis by Alejandra Menchaca (also conducted here at MIT) that developed a computationally fast way of estimating sub-zone air temperature stratification. The method, which works simply by weighing the heat gain in a room against the incoming airflow was validated by many CFD simulations over the course of Alejandra's thesis. You can find here final thesis document here (http://dspace.mit.edu/handle/1721.1/74907).
4) The other main development since the A. Webb thesis that made the radiant map much more accurate is a fast means of estimating the radiant temperature increase felt by an occupant sitting in the sun. This method was developed by some awesome scientists at the UC Berkeley Center for the Built Environment (CBE) Including Tyler Hoyt, who has been particularly helpful to me by supporting the CBE's Github page. The original paper on this fast means of estimating the solar temperature delta can be found here (http://escholarship.org/uc/item/89m1h2dg) although they should have an official publication in a journal soon.
5) The ASHRAE comfort models under the hood of LB+HB all are derived from the javascript of the CBE comfort tool (http://smap.cbe.berkeley.edu/comforttool). A huge chunk of credit definitely goes to this group and I encourage any other researchers who are getting deep into comfort to check the code resources on their github page (https://github.com/CenterForTheBuiltEnvironment/comfort_tool).
6) And, last but not least, a huge share of credit is due to Mostapha and all members of the LB+HB community. It is because of resources and help that Mostapha initially gave me that I learned how to code in the first place and the knowledge of a community that would use the things that I developed was, by fa,r the biggest motivation throughout this thesis and all of my LB efforts.
Thank you all and stay awesome,
-Chris…
main attention is set on easy to handle interface , which should be used at a early stage of conceptual design to respond to external and internal influences in a intelligent and sustainable way.
Participants will use the software Grasshopper as a parametric modeling plug-in for Rhino. The usage of this graphical algorithm editor tightly integrated with Rhino’s 3-D modeling tools open up the possibility to construct highly parametrical complex models. To generate this complexity we will use live linkages to several programs listed below:
• Autodesk Ecotect Analysis and Radiance via GECO
• Processing, Excel or Open Office via gHowl
• FEA software GSA via SSI
In this 3 intense days, the participants should learn the workflow of the plug-ins with the help of examples and get an overview of the different software’s, there possibilities for evaluating the performance of a design or the usage of additional tools to be not chained to a single system .
(e.g. parametrical accentuation, parametrical formation, parametrical reaction)
TIME AND LOCATION
27th – 29th September 2010Leopold-Franzens university innsbruck/austria
Technik Campus | ICT - building
Technikerstraße 21a
A - 6020 Innsbruck | Austria
47°15’50.71”N 11°20’43.45”E
detailed program as pdf-version
FOR WHOM
All levels are welcome (students & professionals)
The only requirement is knowledge of Rhino and Basic Grasshopper.
You will need a level which corresponds to the Grasshopper Primer course outline.
FEES
21 hours
professionals: 395€
students (bachelor/master): 250€.
REGISTRATION
please send a email to to.from.uto@gmail.com attached with following information :
Last Name
First Name
Date of Birth
Nationality
Email Address
Current Address
Profession or proof of student status
After submitting you will receive an email with a PayPal link to complete registration.…
mbre de 9:00 am a 8:00 pm Este taller está dirigido principalmente a arquitectos y diseñadores interesados en el aprendizaje del diseño paramétrico y generativo aplicados a la generación y racionalización de geometrías complejas para su implementación en diferentes procesos de diseño. En el curso se abordarán los conceptos básicos y metodología para hacer frente a diversas problemáticas del diseño mediante el desarrollo de herramientas algorítmicas a través de un lenguaje de programación visual y el desarrollo de esquemas de fabricación digital. No se requieren conocimientos previos de Rhinoceros 3D ni de programación, conocimientos previos de CAD deseables. Estudiantes: 2,500 MXN Profesionales: 3,000 MXN
CONCURSO DE RENDERS - BECA DEL 100% - Parametric & Generative Architecture & Design Grasshopper Workshop.
- Publica tu render en www.facebook.com/3dmetrica - El render con más likes será el ganador. - Fecha límite de votaciones 15 de septiembre del 2012.
Informes e Inscripciones: workshop@3dmetrica.com 04455 28790084 www.3dmetrica.com www.facebook.com/3dmetrica
…
hops, design sessions & symposia across 5 cities in India. We encourage all architecture & design students and professionals to join us in this novel experimentation event and aid in 'Filling The Void'; Void in Architecture, Void in our Cities, Void in Education. REGISTRATIONS ARE OPEN NOW.
rat[LAB] Computational Design Tour - INDIA
Agenda // Filling The Void
1 country // 5 cities // 1 agenda // 100+ students // 25+ professionals // 5 exhibitions // 1 publication
Void is typically defined as null, invalid, empty or redundant and has a psychological perception of a ‘negative’. Through years of development in India, there has been an organic urban growth and inorganic architectural growth which has led to formation of voids in a physical and a metaphorical sense. There also exist voids as gaps between architecture, cities, education and technology. ‘Filling The Void’ looks at void as an opportunity, potential and a driver of change for architecture & design education in India.
// Cities & Dates*
Mumbai – 22nd June to 24th June 2015 (Monday to Wednesday)
Chennai - 29th June to 1st July 2015 (Monday to Wednesday)
Bengaluru – 3rd July to 5th July 2015 (Friday to Sunday)
Chandigarh - 16th July to 18th July 2015 (Thursday to Saturday)
New Delhi – 6th August to 8th August 2015 (Thursday to Saturday)
*Venue details are published on rat[LAB] website.
// Registration Dates
// Early-bird Registrations Open: 08 May 2015
// EXTENDED Early-bird registrations End: 05 June 2015
// General Registrations End: 15 June 2015 (Or till seats last)
…
ively and creatively solve today’s product development challenges.
Our Rhino3D Foundations for Industrial Design class provides an in-depth look at 2D and 3D tools and methods with Rhino3D, a NURBs surface modeling software. In this class, we will systematically work through Rhino3D’s core features, using them to model the various components of a consumer product. Over the course of 3 days, we’ll cover some foundational topics, including Rhino interface and navigation, Rhino3D object types and properties, creating and editing 2D and 3D geometry, procedural modeling, automation, transforming geometry, Rhino modeling best practices, freeform vs. precision modeling, and exporting geometry.
You’ll take away the following:
Navigate the Rhino modeling environment
Create, edit, and modify curves, surfaces, and solids
Precision model using coordinate input and object snaps
Use transformation and universal deformation tools
Apply best practices for layer management and model annotation
Download the course one-pager. Need more information? Connect with us.
This class is ideal for:
Industrial designers who are new to Rhino3D and want to learn its concepts and technical features in an instructor-led environment.
For groups of 10 or more, contact Mode Lab at hello@modelab.is
Interested in additional training options?
https://www.modelab.is/upcoming-computational-design-events…
e think. Also, its easier to catch an error because the malicious component simply turns red/orange (in most cases). However, if you are adept at scripting, you are probably very used to recursive looping & conditional evaluation which you miss majorly in GH (it is possible in very limited ways through using series components or comparer components). So an adept scriptor may soon end up switching back to Rhinoscript unless they find the shift from VBscript to VB.net really fast & smooth (which is rare).
GH ofcourse has the advantage of keeping it all 'alive' and changing things with sliders/graphs/image painting, compared to Rhinoscript which is a run-once operation -- so that's where one makes a choice between recursive looping (in RS) & live interactivity (in GH). I'd say RS mostly wins the battle because interactivity is fancy, but recursion can be a necessity.
Now to VB.net. The one barrier I have hit most often with GH is speed. If you were working on a fairly large data set, or doing a number of surface/polysurface/brep operations, you hit the performance ceiling real fast, which is when the interactivity becomes almost useless -- because its nowhere close to real time anymore even if you had 12gb ram. Thus steps in VB.net (A bit of clever scripting can make a really significant difference).
Working a series of geometric operations in a code component is much faster than doing it through native GH components due to the fact that each native component comes with tonnes off error trapping code, preview generation (I think even if you turn it off, its still being computed, only not displayed), etc. while with VB, you can circumvent a lot of that.
If GH were to handle geometry even remotely comparable to what GC/Catia* can do, it would have a long way to go -- I am not sure if that is even the objective. For instance, I am currently working on a tower where all geometry is only meshes and polylines - no degree 3 curves, no surfaces/polysurfaces. This is because if the entire tower is to stay 'alive', Meshes are the lightest option with the amount of geometry being generated. And most of it is through code... there's only the sliders and a couple of other components that are GH native -- and its still in GH due to the interactivity. (I think there's a vast potential with Meshes that GH/Rhino are really not tapping into. There are all the building blocks, but no significant implementation. Giulio's weaverbird plugin is just a small example).
*GC/Catia cost significantly more than Rhino itself, and GH is a free plugin to Rhino. Morever, these softwares were written to be parametric modelling softwares from day1, unlike GH which is an add-on over the RhinoSDK, which was never developed from such a perspective. So a very very unfair comparison there, but GH is becoming so significant that its got a forum of its own -- gaining an almost 'independent software' status. I just hope the McNeel marketing people are not listening :)…
Angeles, which has 12% of the year made comfortable, and Shiraz, Iran, which also has 12% comfortable (assuming default parameters).
Jerusalem also makes sense to me. There is only a maximum possible 9% of the year that is inside the polygon (you'll see this if you set the timeConstant to a very high number). The default strategyPar makes 6% of these hours comfortable and 3% without cool enough temperatures in the previous hours. This seems reasonable to me.
I could be convinced to change the default time constant to 12 hours (instead of 8) as I know that 12 is the default of climate consultant but that seemed really idealized in my opinion. You'll need really high exposed mass and insulation without much internal heat gain to make conditions stable for more than 8 hours in my opinion.
As for the solarHeatCapacity, I get changes when I drop it down to 10 W/m2 or boost it up to 100 W/m2. It's definitely a parameter that operates on an "order of magnitude" scale and little tweaks to it won't change it too much. You can think of this number as representative of a lot of other physical properties: most notably the depth of the space being passively heated and the thermal mass of that space's materials that participate in heat exchange over the time constant. Climate consultant uses a default assumption of 30 W/m2 but, from my calculations, this is likely assuming a space that has a facade to floor area ratio that is greater than 1. If we say that we need to raise the temperature of 10 cm of an exposed concrete floor for passive heating purposes, and we have a facade-to-floor area ratio of 1:
Required solar flux = ((1 facade-to-floor ratio) x (0.1 m3 of concrete) x (2400 kg/m3 concrete density) x (880 J/kg-K concrete specific heat capacity)) / 3600 seconds/hour
This lands you with a required solar flux of 58 W, which is almost twice the 30 W climate consultant default. While me might say that not all 10 cm of concrete participates over the course of a default 8-hour time constant (most of the action is probably within the first 5 cm), we also have to account for things like transmittance of solar though the window, which, for triple pane, is probably only half of the incident solar. So 50 W seemed to be a more reasonable rule of thumb from my perspective, essentially assuming a facade-to-floor ratio of roughly 1 with 5 cm of concrete participating in an 8 hour heat exchange and a little more than half of solar heat getting through a fully glazed window.
Let me know if that makes sense or if you have any suggestions,
-Chris…
e display pipeline @ xx:xx:xx(xxxms)
iThe DrawViewportWires only when loaded!
The DrawViewportMeshes always when the viewport is refreshed!
Any Idea?
Public Overrides Sub DrawViewportWires(ByVal args As Grasshopper.Kernel.IGH_PreviewArgs) ' MyBase.DrawViewportWires(args)-> Disabled because nothing to Display If (Hidden) Then Return
For Each item As Rhino.Geometry.Circle In Circle args.Display.DrawCircle(item, GC, 3) Next
For Each item As Rhino.Display.Text3d In txt
args.Display.Draw3dText(item, GC) Next
End Sub
Public Overrides Sub DrawViewportMeshes(ByVal args As Grasshopper.Kernel.IGH_PreviewArgs) ' MyBase.DrawViewportMeshes(args) -> Disabled because nothing to Display If (Hidden) Then Return
Dim Brep As Rhino.Geometry.Brep Dim M As Rhino.Display.DisplayMaterial
For i As Integer = 0 To Circle.Count Brep = Rhino.Geometry.Brep.CreatePlanarBreps(Circle.Item(i).ToNurbsCurve())(0) M = New Rhino.Display.DisplayMaterial(VC.Item(Math.Min(i, VC.Count - 1))) args.Display.DrawBrepShaded(Brep, M) Next
End Sub
…