variable. It's a short enough script for normal users, along with Stackoverflow and Google English language searches to debug in the future. Just try isolating the problem in a copy of the script, paring it down to a few lines that still fail the same way, then ask around, since then you'll likely only have a basic Python issue to figure out.
import Rhinoimport subprocess# TO MAKE THIS WORK, RIGHT CLICK RHINO.EXE AND OPENFLIPPER.EXE TO ACCESS THE PROPERTIES>COMPATIBILITY TAB AND CHECK "RUN THIS PROGRAM AS ADMINISTRATOR."# ALSO MAKE SURE TO EDIT THE OPENFLIPPER CORRECT VERSION NUMBER AND INSTALLATION PATH THAT I HAVE HARD-WIRED TO VERSION 3.1, BELOW.# Write an ASCII format STL file for the input mesh, for OpenFlipper to operate on:stl_file = open("C:/NIKS_OPENFLIPPER_PARSER_TEMP.stl","w")stl_file.write("solid OBJECT\n")Input_Mesh = Mesh # Let's not use the Rhino term Mesh in the script itself.Input_Mesh.Normals.ComputeNormals() # NITM ("Not In The Manual") but this is needed first.verts = Input_Mesh.Vertices # Get all vertices of the mesh from Rhino.for i,face in enumerate (Input_Mesh.Faces): # Rhino gives faces by vertex index number.stl_file.write(" facet normal %s\n" % str(Input_Mesh.FaceNormals[i]).replace(",", " ")) # Rhino gives normals!stl_file.write(" outer loop\n")stl_file.write(" vertex %s\n" % str(verts[face.A]).replace(",", " ")) # Rhino has ABCD properties for face vertex index numbers.stl_file.write(" vertex %s\n" % str(verts[face.B]).replace(",", " "))stl_file.write(" vertex %s\n" % str(verts[face.C]).replace(",", " "))stl_file.write(" endloop\n")stl_file.write(" endfacet\n")stl_file.write("endsolid OBJECT\n")stl_file.close()# Generate an OpenFlipper script on the fly in order to alter settings not accepted on its command line:openflipper_script = open("C:/NIKS_OPENFLIPPER_PARSER_TEMP.ofs", "w")openflipper_script.write("core.loadObject(\"C:\\\\NIKS_OPENFLIPPER_PARSER_TEMP.stl\")\n")openflipper_script.write("id = core.getObjectId(\"NIKS_OPENFLIPPER_PARSER_TEMP.stl\")\n")openflipper_script.write("remesher.uniformRemeshing(id,%s,%s,%s,true)\n" % (TargetEdgeLength, Iterations, AreaInterations))openflipper_script.write("core.saveObject(core.getObjectId(\"NIKS_OPENFLIPPER_PARSER_TEMP.stl\"),\"C:\\\\Out.stl\")\n")openflipper_script.write("core.exitApplication()\n")openflipper_script.close()# Windows command line execution of OpenFlipper with argument to run our script:OFS = "C:/NIKS_OPENFLIPPER_PARSER_TEMP.ofs"subprocess.call(['C:\Program Files\OpenFlipper 3.1\OpenFlipper.exe',OFS]);# Read in the OpenFlipper output STL file back into Grasshopper:mesh = Rhino.Geometry.Mesh() # Initialize "mesh" variable as a blank mesh object to hold each face.MESH = Rhino.Geometry.Mesh() # Initialize "MESH" variable as a blank mesh object to accumulate faces.with open("C:/Out.stl") as f: for line in f: if "vertex" in line: q = line.replace("vertex ", "") q = q.replace("\n", "") q = [float(x) for x in q.split()] mesh.Vertices.Add(q[0],q[1],q[2]) # Fill mesh with three vertex lines in a row. if "endloop" in line: # File itself tells us we are done with three vertices for one face. mesh.Faces.AddFace(0,1,2) # Create a single face mesh. MESH.Append(mesh) # Magically build a real multi-face mesh while removing redundant vertices. mesh = Rhino.Geometry.Mesh() # Reinitialize empty mesh object for each mesh face.MESH.Normals.ComputeNormals() # Gives nice mesh and preview but makes the script take longer.…
Added by Nik Willmore at 4:32pm on October 9, 2017
, one is office and the other one is hotel for example.
- a list will control the points height
- to each of this point I am attaching a plane
- this plane will intersect the skin of the tower
- from this intersection I am try to take out the floor plate (as Curve) and the area ( as Data)
I think I've got most of the script. but I have some error that I can't figure it out.
Please if you have time can you look to this code?
thank you very much
Private Sub RunScript(ByVal skin As Brep, ByVal f1 As Integer, ByVal DELTAh1 As Double, ByVal Lobby1h As Double, ByVal f2 As Object, ByVal DELTAh2 As Object, ByVal Lobby2h As Object, ByRef A As Object, ByRef C As Object) 'Declare the list of Point on which attach the planes for intersections Dim p As New List(Of Point3d) 'first sector office Dim q As New List(Of Point3d) ' second sector hotel Dim floorPlate As New List(Of Curve) 'Declare a list for storing the curve
'for loop condition statement Dim i As Integer ' for the office Dim j As Integer ' for the hotel For i = Lobby1h To f1 + Lobby1h For j = f1 + Lobby1h + Lobby2h To f2 + (f1 + Lobby1h + Lobby2h)
p.Add(New Point3d(0, 0, i * DELTAh1)) ' points
Dim pl As New Plane(New Point3d(0, 0, i * DELTAh1), Vector3d.ZAxis) 'Planes Dim iCurves As curve() 'temporary store the curves Dim not_used_pt As Point3d() 'points needed only for the Intersect function
Intersect.Intersection.BrepPlane(skin, pl, 0.1d, iCurves, not_used_pt) floorPlate.Add(iCurves(0)) 'if you assume only once curve for each intersection
Next Next
Dim Areas As New list (Of Double) 'I will try to have a summ of all te areas 'Dim Areatot As Double
Dim k As Integer ' for loop to iterate the floorplates For K = 0 To floorPlate.Count - 1 Areas = AreaMassProperties.Compute(floorPlate)
Next
A = Areas.Area C = floorPlate
End Sub …
a and we'll stop adding new stuff. At this point the Grasshopper version will be rolled to 1.0 Beta 1 and we'll keep on fixing serious bugs, resulting in Grasshopper 1.0 Beta 2 etc. etc. until the product is stable enough to be treated as a commercially viable product.
This does not mean Grasshopper will no longer be free. Robert McNeel & Associates (who develop and own the copyrights to Grasshopper) haven't decided yet whether or not to sell Grasshopper or whether to keep it as a free plug-in for Rhino customers.
As soon as Grasshopper 1.0 goes into beta, all development (apart from the odd bug-fix) stops and we start typing on Grasshopper 2.0. It will probably be a few months until the first 2.0 WIP version is released but basically the whole process starts over.
What are we looking to accomplish for 1.0 and which things are planned for 2.0 and beyond? The only major feature still missing in 1.0 is the Remote Control Panel. This feature was removed at some point and has been partially rewritten since then. Once it's finished, we consider the 1.0 feature set to be complete.
To be honest we've made very few concrete plans yet concerning 2.0, however it's clear that some things need to be at least seriously considered and researched. Here follows a list in no particular order:
Documentation System. This is one of the things we know we're going to do as we've already started. The Grasshopper help system will need to be rewritten and a lot of help topics need to be typed up. We have a pretty good idea what it is we want to accomplish with the new help and how we're going to go about it.
Vocabulary. Along with new documentation we'll critically analyse the current terminology and vocabulary of Grasshopper. We'll probably come up with glossaries and style sheets. We want to use words that are —at best— self documenting and —at worst— non ambiguous.
SDK and core library cleanup/improvement. Grasshopper was the first large scale product I ever developed and a lot of mistakes were made in the SDK design. A lot of functions and classes have been marked obsolete over time and many operations are not properly bottlenecked. I also want to add a lot more events so it's easier for code to keep close tabs on what's going on at any given moment.
GUI platform. At the moment Grasshopper is pure .NET winforms using GDI+ for all the interface drawing. There are certain performance issues with using large GDI+ surfaces and certain limitations on what we can and cannot draw. We will be investigating other graphics pipelines such as WPF, OpenGL, DirectX, OpenTK and whatever else seems promising.
Multi-threading. It is clear that some components are embarrassingly parallel, and since almost every single laptop and desktop has at least 4 cores these days it would be a shame not to use them. We will investigate what it takes to implement multi-threading as a standard feature.
Large file support. Grasshopper becomes awkward to use when a document contains more than a hundred or so components. We need to both improve the interface to provide methods for layering or grouping sub-algorithms and also add ways to reduce memory and computational overhead.
--
David Rutten
david@mcneel.com
Poprad, Slovakia…
doing this with the current tools or a bit of scripting since the Flickr API allows you to make requests in a REST format, but utilizing the Flickr.net API library makes it much simpler.
First and foremost, you need a Flickr API key...do you have one of those?
A great way to get to know the Flickr API is with the API Explorer. Here is a link to the page for the flickr.photos.search method explorer: http://www.flickr.com/services/api/explore/flickr.photos.search
The cool thing about this page is that it generates the REST Http call towards the bottom. So, here is what I did:
1. Grab the coordinates of the bounding box per Flickr API request:
bbox (Optional)
A comma-delimited list of 4 values defining the Bounding Box of the area that will be searched. The 4 values represent the bottom-left corner of the box and the top-right corner, minimum_longitude, minimum_latitude, maximum_longitude, maximum_latitude. Longitude has a range of -180 to 180 , latitude of -90 to 90. Defaults to -180, -90, 180, 90 if not specified. Unlike standard photo queries, geo (or bounding box) queries will only return 250 results per page. Geo queries require some sort of limiting agent in order to prevent the database from crying. This is basically like the check against "parameterless searches" for queries without a geo component. A tag, for instance, is considered a limiting agent as are user defined min_date_taken and min_date_upload parameters — If no limiting factor is passed we return only photos added in the last 12 hours (though we may extend the limit in the future).
So, I went to Google Earth, picked a city (London, UK) and dropped two pins:
This gave me two locations, which I can put into the Explorer Page next to the bbox option. Here is what I put for these two points: -0.155941,51.496768,-0.116783,51.511431
2. Check has_geo
3. In extras, type in geo
4. Make the call!
You will see a list of responses in an XML format, these responses will be from the first page. Geolocated photos are limited to 250 / page, so you will have to grab them page by page.
If you want to add more options (minimum upload date, maximum upload date, etc) you can do this as well)
The best is at the bottom, you get the full http call for this: http://api.flickr.com/services/rest/?method=flickr.photos.search&api_key=ffd44f601393a46e86aa3a5f8a013360&bbox=-0.155941%2C51.496768%2C-0.116783%2C51.511431&has_geo=&extras=geo&format=rest&api_sig=b42330e5d1523bd5fe60c2ad43acde99
Notice this call has some other api key, you should eventually replace this with your own.
You could copy and paste this into a browser and you will get the results with the latitude and longitude:
So this is really what you need to know to do this through GH. Since gHowl has an XML parser component that can access files on the web, you should be able to use the same http call into this component.
Eventually, we get a response, and we need to grab the lat and lon data. With gHowl we can map these to xyz coordinates, and generate the heatmap...this is just a linear mapping:
Attached are both the Rhino file and the Grasshopper file, as well as the image underlay.
I am working on a series of components that makes this more straightforward, but for now, this should get you started.
…
peuvent se diviser une surface avec ne importe quel motif imaginable. 3. Ici, je fournir un moyen de le faire via Lunchbox ... cela fonctionne mais il est fixe et donc nous avons besoin de jouer avec des arbres de données afin de créer le motif approprié par cas. 4. L'autre composante est un joint C # qui fait beaucoup de choses autres que de diviser ne importe quelle collection de points avec de nombreux modèles (voir le modèle ANDRE que je ai fait pour vous). 5. Vous devez décomposer une polysurface en morceaux afin de travailler sur les subdivisions. 6. Je donne une autre définition ainsi que pourrait agir comme un tutoriel sur la façon de traiter des ensembles de points via des composants de GH standards et des méthodes classiques.
Avertissez si tous ceux-ci apparaissent floue pour vous: Si oui, je pourrais écrire une définition utilisant des composants de GH classiques - mais vous perdrez les variations de motifs de division.
mieux, Peter
…
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…