a problem with SSL. Any Ideas? I am using the following code:
import json,httplib connection = httplib.HTTPSConnection('api.parse.com', 443) connection.connect() connection.request('GET', '/1/classes/MY-CLASS', '', { "X-Parse-Application-Id": "MY-APP-ID", "X-Parse-REST-API-Key": "MY-REST-API-KEY" }) result = json.loads(connection.getresponse().read()) print result
I Get the Following Messages:
Runtime error (IOException): Authentication failed because the remote party has closed the transport stream. Traceback: line 280, in do_handshake, "C:\Program Files\Rhinoceros 5.0 (64-bit)\Plug-ins\IronPython\Lib\ssl.py" line 120, in __init__, "C:\Program Files\Rhinoceros 5.0 (64-bit)\Plug-ins\IronPython\Lib\ssl.py" line 336, in wrap_socket, "C:\Program Files\Rhinoceros 5.0 (64-bit)\Plug-ins\IronPython\Lib\ssl.py" line 1156, in connect, "C:\Program Files\Rhinoceros 5.0 (64-bit)\Plug-ins\IronPython\Lib\httplib.py" line 3, in script Any help would be greatly appreciated! Thanks in advance! -Zach…
t defined from the discussion of radiation exchange between urban surfaces and the sky in urban heat island research (See Oke's literature list below). It will be affected by the proportion of sky visible from a given calculation point on a surface (vertical or horizontal) as a result of the obstruction of urban geometry, but it is not entirely associated with the solid angle subtended by the visible sky patch/patches.
So, I think using "geometry way" to approximate Sky View Factor is not correct. Sky View Factor calculation shall be based on the first principle defining the concept: radiation exchange between urban surface and sky hemisphere:
(image extracted from Johnson, G. T., & Watson, 1984)
Therefore, I always refer to the following "theoretical" Sky View Factors calculated at the centre of an infinitely long street canyon with different Height-to-width ratios in Oke's original paper (1981) as the ultimate benchmark to validate different methods to calculate SVF:
So, I agree with Compagnon (2004) on the method he used to calculate SVF: a simple radiation (or illuminance) simulation using a uniform sky.
The following images are the results of the workflow I built in the procedural modeling software Houdini (using its python library) according to this principle by calling Radiance to do the simulation and calculation, and the SVF values calculated for different canyon H/W ratios (shown at the bottom of each image) are very close to the values shown in Oke's paper.
H/W=0.25, SVF=0.895
H/W=1, SVF=0.447
H/W=2, SVF=0.246
It seems that the Sky View Factor calculated from the viewAnalysis component in Ladybug is not aligned with Oke's result for a given H/W ration: (GH file attached)
According to the definition shown in this component, I assume the value calculated is the percentage of visible sky which is a geometric calculation (shooting evenly distributed rays from sensor point to the sky and calculate the ratio of rays not blocked by urban geometry?), i.e solid angle subtended by visible sky patches, and it is not aligned with the original radiation exchange definition of Sky View Factor.
I'd suggest to call this geometrically calculated ratio of visible sky "Sky Exposure Factor" which is "true" to its definition and way of calculation (see the paper on Sky Exposure Factor below) so as to avoid confusion with "The Sky View Factor based on radiation exchange" as discussed in urban climate literature.
Appreciate your comments and advice!
References:
SVF: definition based on first principle
Oke, T. R. (1981). Canyon geometry and the nocturnal urban heat island: comparison of scale model and field observations. Journal of Climatology, 1(3), 237-254.
Oke, T. R. (1987). Boundary layer climates (2nd ed.). London ; New York: Methuen.
Johnson, G. T., & Watson, I. D. (1984). The Determination of View-Factors in Urban Canyons. Journal of American Meteorological Society, 23, 329-335.
Watson, I. D., & Johnson, G. T. (1987). Graphical estimation of sky view-factors in urban environments. INTERNATIONAL JOURNAL OF CLIMATOLOGY, 7(2), 193-197. doi: 10.1002/joc.3370070210
Papers on SVF calculation:
Brown, M. J., Grimmond, S., & Ratti, C. (2001). Comparison of Methodologies for Computing Sky View Factor in Urban Environments. Los Alamos, New Mexico, USA: Los Alamos National Laboratory.
SVF calculation based on first principle:
Compagnon, R. (2004). Solar and daylight availability in the urban fabric. Energy and Buildings, 36(4), 321-328.
paper on Sky Exposure Factor:
Zhang, J., Heng, C. K., Malone-Lee, L. C., Hii, D. J. C., Janssen, P., Leung, K. S., & Tan, B. K. (2012). Evaluating environmental implications of density: A comparative case study on the relationship between density, urban block typology and sky exposure. Automation in Construction, 22, 90-101. doi: 10.1016/j.autcon.2011.06.011
…
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.
…
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
…
n be obtained for curved NURBS surfaces as well as unconventional window configurations".
And I also noticed the following information form the optional input in the runEnergySimulation component.
"meshSettings_: Optional mesh settings for your geometry from any one of the native Grasshopper mesh setting components. These will be used to change the meshing of curved surfaces before they are run through EnergyPlus (note that meshing of curved surfaces is done since Energyplus is not able to calculate heat flow through non-planar surfaces). Default Grasshopper meshing is used if nothing is input here but you may want to decrease your calculation time by changing it to Coarse or increase your curvature definition (and calculation time) by making it finer".
1) My case is an one-story, rectangular-plan large hall (40m*70m*25m) with a curved roof. The roof surface is a part of a standard sphere and the walls and floor are all planar (the each wall has one curved edge as showed in the image).
For testing, I threw the original curved roof surface into daylight and energy simulations without making customized meshings, because I assumed that it might be automatically converted to meshs by Honeybee - Am I right? As showed in the image, how can I reduce the number of meshs in a proper way? Must two connected surfaces (i.e. wall and roof) be STRICTLY/SEAMLESSLY connected or not (considering different divisions of meshs in the respective surface)? - Is a connection tolerance allowed?
2) But, when I run the annual daylight simulation for this case, it gave me a lot of warnings "oconv: warning - zero area for polygon".- is that normal? and how to avoid this? Does the daylight simulation allow "curved NURBS surfaces"?
3) Moreover, when I run an energy simulation for this case, it costed extremely long time. It was just so long that I did not even have results out of one simulation. - I guessed it might be the problem caused by the curved roof surface (or automatic meshing?), but I don't have experience of converting a curved NURBS/spheral surface into correct meshs that can be recognized by Honeybee simulations (Daylight and Energy) in a proper way.
4) The large window on the wall was generated by the "_glzRatio". But the automatically generated wall meshs around this window are just too "fine", which might largely increase simulation time. Is there a proper way to get rid of it? (Considering that the size, shape and position of the window will have large influence on the daylight distribution in the building, it is worthy to keep the size, shape and position of the window as it should be in reality).
In sum, considering all above, could your please provide me some suggestions/tutorials/links that might be helpful for dealing with "curved NURBS surfaces" in Honeybee simulations.
Thank you all in advance!
Best,
Ding
…
j
1
c
e
h
k
2
f
-------------------------------------------------------------------------------------------------
To these...
0;0
0;1
0
a
i
------------------------------------------------------------
0;0
0;1
0;2
0
b
g
j
1
c
h
k
------------------------------------------------------------
0;0
0
d
1
e
2
f
------------------------------------------------------------
Thanx……
erning how to do that on a sphere.
So I know already all the different approches of how to get a relaxed voronoi pattern on a free-form open surface, but still don't know how to obtain the same elegant effect on a sphere (or an ellipsoid closed surface, whatever), or how to relax the facet dome cells.
Andrew stated on his site that he used kangaroo for this project, so the Spore Lamp consists in my opinion either of a relaxed voronoi 3d diagram (b-rep, b-rep intersection) on a sphere the cells of which have been planarized later on, or more likely it is a sort of relaxed facet dome.
The trick is to:
1. obtain a nicely-balanced voronoish diagram (or facet dome cells) on a sphere
2. keep each cell/polyline planar (or force them with kangaroo to be planar) in order to move scale and loft them later on.
Here is what I have by now.(files: matsys spore lamp attempt)
That's the closest appearance that I got so far (simple move scale and loft of facet dome cells with the amount of transformations being proportional to the power of the initial cell area: bigger cell = bigger opening etc.) - with no relaxation of the diagram. But it's obviously not the same thing as the matsys design.
Here are some of my attempts of facet dome relaxation, but well, it's certainly still not the right approach, and most importantly I don't know how to keep or force the cells to be planar after the relaxation.
1. pulling vertices to a sphere - no anchor points. That obviously doesn't make sense at all, but the relaxation without anchor points gives at the beginning a pattern that is closer to what I am looking for. (files: relaxation 01)
2. pulling vertices to a sphere - two faces of the initial facet dome anchored (files: relaxation 02)
3. pulling vertices to the initial geometry (facet dome) no anchor points (files: relaxation 03)
The cell pattern of the lamp kinda looks like this:
You can find it here: http://www.grasshopper3d.com/forum/topics/kangaroo-0-095-releasedgroupUrl=kangaroo&x=1&groupId=2985220%3AGroup%3A120977&id=2985220%3ATopic%3A972434&page=2#comments
Done with Plankton (of course without the "gradient increase" appearance), but in fact not, I took a look at Daniel Parker's Plankton example files, and it's not quite the same thing. Also the cells aren't planar...
The last problem is that during the relaxation attempts that I did, the biggest initial cells became enormous, and it's not like that in the elegant project by Andrew Kudless, that I'd like to achieve.
So to sum up:
Goal no 1: Obtain an elegant voronoi /facet dome cell pattern on a sphere (or an ellipsoid surface, whatever).
Goal no 2: How to keep the cells planar in order to be able to loft them later, obtain those pyramidal forms, and assemble easily
Have you got any ideas? Or maybe there's a completely different approach to that?
Cheers, and thanks in advance…
currently within a fake euphoria framework - blame China/UAE) and a potential decision about doing/developing this or doing that … well …anyway … read and enjoy.
AEC matters: The good, the bad and the ugly.
The bad news: Rhino is NOT suitable for the job (although some use it … but only in the sense that people use Modo for the so called “hard modeling”). By job I mean things up to shop drawing level + specs + you and me (we call it Final level) – nothing to do with sketches and outlines of some abstract “schematic” topology.
The ugly news: The so called Design-Construct approach gains exponentially momentum especially in countries the likes of China/UAE/BRICS (95% of the whole AEC activity worldwide happens there). DeCo means: AEC engineers deliver some kind of study in a preliminary level and the main contractor splits (outsourcers) the job and assigns the study completion AND the construction to various sup-constructors. That thing appeared first – in a large scale - in Dubai 15 years ago. This means that the era of Sergio Pininfarina is over and out: welcome anonymous Toyota designer. In plain English: days of construction corporations fast replacing practices. Dead men walking.
The good news: All AEC related apps (Revit, AECOsim, Allplan and the likes) are in a lethargic state as regards the brave new world (based on the archaic level driven organization schemas etc etc). Of course they all claim the exact opposite and point that support BIM (nobody mention PLM) better than the other guy. But the 21st century – helped by 2 forthcoming unavoidable crisis (a) about shortage of water (b) about transition from carbon to hydrogen economy – isn’t about bureaucracy: think cost/resources optimization and “fitness” rather than China/UAE type of liquid trend. Days of euphoria fast approaching the Wall.
Top to bottom and visa versa.
Old days Titans (Oscar, Mies, Walter, Pierre Luigi, Frank, Eero, blah blah) outlined things (mostly using crayons) and the rest were struggling to translate these in reality in an one way vector like process : Top to bottom that is. These days the inverse gains momentum : when in the whole consider the part … validate … redo … validate … redo. This means bottom to top geared with top-to-bottom. In plain English : child imposes rules to parent and parent imposes rules to child. This means classic MCAD feature/history modeling (CATIA/NX/MS). This is something that Rhino can’t do (not to mention that Rhino is a surface modeler – a rather critical fact).
The parts that are bigger than the whole.
Go there ( http://www.behance.net/gallery/2885057/a-myriad-of-cables) are inspect the whole thing: it’s a parametric nightmare made with the other guy (Generative Components – slower than a Skoda + bugs + why bother?). But the whole (masts and membranes and the likes) means nothing here: focus to the details that are critical for connecting this with that. Complex feature driven solids that are made with internal (on a per se basis) parameters (like fillets required for casting or radius for cable anchoring) whilst they comply with external rules/parameters (cable angles, topology clash issues etc etc). So the whole outlines possibilities … and the part either can follow…or the part must change…or the whole must change. Can you do that with GH/Rhino? And if not what’s missing? (lot’s of things to be honest).
Some other "similar" things:
The narrow picture.
I agree with what others already said and with pretty much all Ola’s points – especially the visual drag-and-drop path mapper (i.e. a visual data manipulator so to speak) and the enable/disable components in groups capability.
Some other suggestions:
A multi canvas capability. As things are right now…it’s like working in Rhino in one view (rather unsuitable I guess). In fact …since overlapping views they don’t work in Rhino…well…you know, he he.
A working auto profile arrangement capability (non twisted Loft/Sweep and the likes). Worth 1Bn dollars that one.
Ability to locate components that caused this or that in the Rhino view: meaning a 2 way communication approach : GH makes things happen in Rhino and things can indicate their cause in the GH canvas.
A robust collection of components that bake stuff in nested blocks (emulating some primitive assembly/component way of thinking). Why may you ask? Well … the whole objective is to talk to CATIA (via STEP) don’t you agree? CATIA makes things happen in real-life not Rhino.
A robust collection of components that can create real-life parametric tensile membrane solutions (get some inspiration from FormFinder: useless because it’s academic but good to point the way). Membranes (and geodesics) are the future.
I could continue at infinitum but IMHO the big picture is worth 12345,67 “focused” GH improvements.
May the Force (the dark option) be with us all.
…
ch has a vertex in each of the vertices of the polyline. But, when I try to create the mesh using the Mesh Brep component, I get a simplified mesh, where the extra vertices in the edges of the polyline have disappeared. I think it is easier to understand what I am trying to say with the following screenshots:
Polyline:
Mesh created with the rhino command:
Mesh created using grasshopper:
The last mesh has less faces, as the Mesh Brep component gets rid of the extra vertices that define the polyline.
Any suggestions?
Thanks,
Diego…