o express my gratitude. I've been experimenting with your definitions (and still am), but let me extend my question.
Actually what I'm trying to achieve, is to recreate another project by Andrew Kudless, the spore lamp (I mentioned the Chrysalis at the beginning just because of the animation, which wasn't included in the Spore Lamp presentation).
Basically the spore lamp seems to me to be something like a preliminary study to the Chrysalis III project (I think it's a similar approach).
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 which then has been planarized, 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)
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 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-released?g...
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: Keep the cells planar in order to be able to loft them later and obtain those pyramidal forms, and assemble easily
Any ideas? Or maybe there's a completely different approach to that?…
les automatically at the right angle to form the cap of an icosahedron.
To complete the full icosahedron, we consider just the six points we already know, the five pentagon vertices and the raised pyramid tip and reorient one of the vertices using three-point transformation so it obtains the exact same relationship between vertices only one more stage beyond our little cap pyramid, and we do a five-fold polar array:
I used a password-protected cluster I ran into one the forum somewhere to reproduce Rhino's 3-point orient command:
A final 3-point orientation transforms in space the original pyramid tip down to the bottom:
Now we can create a convex hull which gives an icosahedron mesh:
So that's how you build an icosahedron in Rhino from scratch, only using rather long winded Grasshopper.
Now we use the Weaverbird plug-in to subdivide the faces and then project the vertices out onto a sphere via finding the closest points to a sphere and then recreating a convex hull to make a geodesic dome mesh:
Subdividing two times works fine but 3 times blows up convex hull, so I'll just have due with the the subdivision step and leave out projecting back to a sphere, since the algorithm already gives a nice spherical result that you can see inside this disaster:
Now you know what a standard geodescic dome is, just an icosahedron with faces divided into smaller triangles, projected out to a sphere.
Actually, the mere subdivision is just a bit blobby instead of a sphere, damn it, so I'll have to topologically recreate the mesh after projecting the points indeed back onto our sphere.
Using a subdivision plug-in may be slightly throwing the perfect result off, so manually creating subdivision points on each mesh face may be in order, doing them flat against each icosahedron face:
You can also start with the two other triangulated Platonic solids but those give less regular triangles:
…
ree..
First-End List Component cannot manage branches inside every dimensions..
"Smart T8" Component is developed for managing the multi dimensional data tree with first-end algorithm.
It works with path index location..
"-1" or negative numbers mean the location of item..
"0" means the location of the last path index..
positive numbers mean the location from the back..
----
Now look at this example.. a simple 3-dimensional boxes..
In the data tree.. of {0;0;i;j} (k)
"k" is the item index.. Y direction..
"j" is the last path.. X direction..
and "i" is the level.. Z direction..
----
When index < 0 (i.e. "-1" or negative)
"Smart T8" performs like the First-End Item Component..
It selects first items in each list and puts them out to "F"..
and in this example.. they are boxes with same Y coordinate(=0)..
In the below image..
F(Red) M(Transparent Green) E(Blue) are classified by Y coordinates..
----
When index = 0
"Smart T8" focuses on the last path index..
It selects first list of every {0; 0; i; *} set of lists.. (i.e. every levels)
In this example.. they are boxes with same X coordinate(=0)..
because the last path means X grid..
In the below image..
F(Red) M(Transparent Green) E(Blue) are classified by X coordinates..
----
When index = 1
"Smart T8" focuses on the third path index.. (i.e. 1 step from the back)
It selects first list of every {0; 0; *; j} set of lists..
Actually in this case.. they are first levels of every YZ planes..
In this example.. they are boxes with same Z coordinate(=0)..
because "Smart T8" manages levels now (index=1)..
In the below image..
F(Red) M(Transparent Green) E(Blue) are classified by levels..
----
When index > 1.. (if it is meaningless index or out of range..)
It performs First-End List Component..
It selects only the first and end list of all lists..
----
The "Smart T8" component works with 3 or more dimensional data tree well..
Please control the focusing index and enjoy it.. :)
…
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.
…
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
…
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…
r." I'm sorry to hear that, I take the interface and ease-of-use rather seriously so this sounds like a fundamental failure on my part. On the other hand, Grasshopper isn't supposed to be on a par with most other 3D programs. It is emphatically not meant for manual/direct modelling. If you would normally tackle a problem by drawing geometry by hand, Grasshopper is not (and should never be advertised as) a good alternative."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."Grasshopper ships with about 1000 components (rounded to the nearest power of ten). I'm adding more all the time, either because new functionality has been exposed in the Rhino SDK or because a certain component makes a lot of sense to a lot of people. Adding pre-canned components that do the same as '8 or 10 components strung together' for the heck of it will balloon the total number of components everyone has to deal with. If you find yourself using the same 8 to 10 components together all the time, then please mention it on this forum. A lot of the currently existing components have been added because someone asked for it."[...] has a far cleaner and more intuitive interface. So does SolidWorks, Inventor, CATIA, NX, and a bunch of others."Again, GH was not designed to be an alternative to these sort of modellers. I don't like referring to GH as 'parameteric' as that term has been co-opted by relational modellers. I prefer to use 'algorithmic' instead. The idea behind parameteric seems to be that one models by hand, but every click exists within a context, and when the context changes the software figures out where to move the click to. The idea behind algorithmic is that you don't model by hand.This is not to say there is no value in the parametric approach. Obviously it is a winning strategy and many people love to use it. We have considered adding some features to GH that would make manual modelling less of a chore and we would still very much like to do so. However this is such a large chunk of work that we have to be very careful about investing the time. Before I start down this road I want to make sure that the choice I'm making is not 'lame-ass algorithmic modeller with some lame-ass parametrics tacked on' vs. 'kick-ass algorithmic modeller with no parametrics tacked on'.
Visual Programming.I'm not exactly sure I understand your grievance here, but I suspect I agree. The visual part is front and centre at the moment and it should remain there. However we need to improve upon it and at the same time give programmers more tools to achieve what they want.
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."Unfortunately it's not as simple as that. Whether or not a conversion between two data types makes sense is often dependent on the actual values. If you plug a list of curves into a Line component, none of them may be convertible. Should I therefore not allow this connection to be made? What if there is a single curve that could be converted to a line? What if you want to make the connection now, but only later plan to add some convertible curves to the data? What you made the connection back when it was valid, but now it's no longer valid, wouldn't it be weird if there was a connection you couldn't make again?I've started work on GH2 and one of the first things I'm writing now is the new data-conversion logic. The goal this time around is to not just try and convert type A into type B, but include information about what sort of conversion was needed (straightforward, exotic, far-fetched. etc.) and information regarding why that type was assigned.You are right that under some conditions, we can be sure that a conversion will always fail. For example connecting a Boolean output with a Curve input. But even there my preferred solution is to tell people why that doesn't make sense rather than not allowing it in the first place.
Sliders."I think they should be optional."They are optional."The “N” should turn into the number if set."What if you assign more than one integer? I think I'd rather see a component with inputs 'N', 'P' and 'X' rather than '5', '8' and '35.7', but I concede that is a personal preference."But if I plug it into something that'll only accept a 1, a 2, or a 3, that slider should self set accordingly."Agreed.
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."I was thinking of just zooming in on a component would eventually provide easier ways to access settings and data."Could some of these items disappear if they are contextually inappropriate or gray out if they're unlikely?"It's almost impossible for me to know whether these things are 'unlikely' in any given situation. There are probably some cases where a suggestion along the lines of "Hey, this component is about to run 40,524 times. It seems like it would make sense to Graft the 'P' input." would be useful.
Integration."Why isn't it just live geometry?"This is an unfortunate side-effect of the way the Rhino SDK was designed. Pumping all my geometry through the Rhino document would severely impact performance and memory usage. It also complicates the matter to an almost impossible degree as any command and plugin running in Rhino now has access to 'my' geometry."Maybe add more Rhino functionality to GH. GH has no 3D offset."That's the plan moving forward. A lot of algorithms in Rhino (Make2D, FilletEdge, Shelling, BlendSrf, the list goes on) are not available as part of the public SDK. The Rhino development team is going to try and rectify this for Rhino6 and beyond. As soon as these functions become available I'll start adding them to GH (provided they make sense of course).On the whole I agree that integration needs a lot of work, and it's work that has to happen on both sides of the isle.
Documentation.Absolutely. Development for GH1 has slowed because I'm now working on GH2. We decided that GH1 is 'feature complete', basically to avoid feature creep. GH2 is a ground-up rewrite so it will take a long time until something is ready for testing. During this time, minor additions and of course bug fixes will be available for GH1, but on a much lower frequency.Documentation is woefully inadequate at present. The primer is being updated (and the new version looks great), but for GH2 we're planning a completely new help system. People have been hired to provide the content. With a bit of luck and a lot of work this will be one of the main selling points of GH2.
2D-ness."I know you'll disagree completely, but I'm sticking to this. How else could an omission like offsetsurf happen?"I don't fully disagree. A lot of geometry is either flat or happens inside surfaces. The reason there's no shelling (I'm assuming that's what you meant, there are two Offset Surface components in GH) is because (a) it's a very new feature in Rhino and doesn't work too well yet and (b) as a result of that isn't available to plugins.
Organisation.Agreed. We need to come up with better ways to organise, document, version, share and simplify GH files. GH1 UI is ok for small projects (<100 components) but can't handle more complexity.
Don't get me wrong, I appreciate the feedback, I really do, but I want to be honest and open about my own plans and where they might conflict with your wishes. Grasshopper is being used far beyond the boundaries of what we expected and it's clear that there are major shortcomings that must be addressed before too long. We didn't get it right with the first version, I don't expect we'll get it completely right with the second version but if we can improve upon the -say- five biggest drawbacks (performance, documentation, organisation, plugin management and no mac version) I'll be a happy puppy.
--
David Rutten
david@mcneel.com…